Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "PMF/design"
(→Control flow) |
(→Static design) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
== Page/Window content design == | == Page/Window content design == | ||
| − | This part deals with the content of a presentation unit. It can be a page, frame or a window | + | 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 === | === Static content === | ||
| − | UI structure and appearance doesn't change in | + | 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 == | ||
= System design = | = System design = | ||
| − | == Data | + | == 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 == | == 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. | ||
| + | |||
| + | === 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.