Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PMF/design"
(→Presentation model) |
(→Static design) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
UI structure and appearance doesn't change in the whole life circle. It mainly focus on a UI structure and presentation organization. It is in fact a simplest case. In a real application, this case is very rare. But this step set up the foundation of dynamic UI design. | UI structure and appearance doesn't change in the whole life circle. It mainly focus on a UI structure and presentation organization. It is in fact a simplest case. In a real application, this case is very rare. But this step set up the foundation of dynamic UI design. | ||
| − | === Control | + | === Control Scenario === |
| − | Control | + | Control Scenario deals with the dynamic aspect of UI page content. For example, in a payment page of purchase order, the mode of payment UI depends on the type of credit card. When you select one mode, the corresponding UI should be displayed in the same page. |
== Page flow design == | == Page flow design == | ||
| Line 20: | Line 20: | ||
The services could be: | The services could be: | ||
* Metamodel services | * Metamodel services | ||
| + | * Validation services | ||
* Transaction services | * Transaction services | ||
All modifications on data in one page or between page could be transactional. | All modifications on data in one page or between page could be transactional. | ||
| Line 25: | Line 26: | ||
== Presentation model == | == Presentation model == | ||
=== Static design === | === Static design === | ||
| − | + | This module handles the static UI structure of a presentation for a given data type. All UI elements together to display a date is named as a Presentation. A presentation must be characteristed by the following features: | |
* Reusable | * Reusable | ||
One presentation can be used in mutiple location. | One presentation can be used in mutiple location. | ||
* Embeddable | * Embeddable | ||
One presentation can contain other presentations. And it-self can be contained by others. The embeddibility is not a containment relationhip. | One presentation can contain other presentations. And it-self can be contained by others. The embeddibility is not a containment relationhip. | ||
| + | |||
| + | === Control scenario design === | ||
| + | |||
| + | |||
| + | === Page flow design === | ||
== Code generation == | == Code generation == | ||
Latest revision as of 20:44, 30 October 2009
Contents
Development process
Based on UI structure, a UI Presentation can be divided in two categories:
- Page/Window content design
- Page flow design
Page/Window content design
This part deals with the content of a presentation unit. It can be a page, frame or a window. In the context of PMF, a page is already associated with a data to present.
Static content
UI structure and appearance doesn't change in the whole life circle. It mainly focus on a UI structure and presentation organization. It is in fact a simplest case. In a real application, this case is very rare. But this step set up the foundation of dynamic UI design.
Control Scenario
Control Scenario deals with the dynamic aspect of UI page content. For example, in a payment page of purchase order, the mode of payment UI depends on the type of credit card. When you select one mode, the corresponding UI should be displayed in the same page.
Page flow design
System design
Data services
Data services encapsultes the nature of all business data model such as Java, EMF, UML, ...
The services could be:
- Metamodel services
- Validation services
- Transaction services
All modifications on data in one page or between page could be transactional.
Presentation model
Static design
This module handles the static UI structure of a presentation for a given data type. All UI elements together to display a date is named as a Presentation. A presentation must be characteristed by the following features:
- Reusable
One presentation can be used in mutiple location.
- Embeddable
One presentation can contain other presentations. And it-self can be contained by others. The embeddibility is not a containment relationhip.