Tools / Patterns / Components | patterns.library |
This page gives a breif feature overview of the available component patterns. The following pages
are also available which explain how to use some of the patterns in more detail.
|
Finder Pattern | patterns.library.object_finder* |
The finder pattern will generate a Criteria Screen and Results Screen, with all the underlying component, TX, DTOs and form and action beans necessary for operation. With the Finder Patterns Criteria screen you can create editboxs for data capture with associated lookups and dropdowns or use checkboxes. You can also use the breakup attribute to allow both static and dynamic population of values. You also have the control to specify function guards for a particular inputs on the screen. It is also possible to specifiy an alternative domain object as part of the input criteria. You may also allow the user the control to render the screen into an embedded Excel document or XML or HTML format. The results screen contains a Usergrid that displays the values you wish to define as result fields. You can source chain to have results in some of the columns from related entities, also can then specify a primary key that will be display on the popup or can be passed to 4 related types of screens components. A Creator screen, A Viewer screen, An Updator screen, and a Deletor screen.
|
Viewer Pattern | patterns.library.object_viewer* |
The viewer pattern allows data to be presented in read only text widget format on the screen. You can specify a set of input criteria fields that will be populated into the component controller. It allows for source chaining of results as well as Usergrids of data being presented as related objects if desired.
|
Maintenance Pattern | patterns.library.object_maintenance* |
This is essentially an information gathering screen that allows the user to build a screen for data entry to a table. It comprises of the usual input widget types but also allows the user to use one of three special cases. By using the ForeignKey code blocks you can build up complex validation and table cross referencing logic. The keys for these objects can be technical , primary and candidate. For example you could have a value that exists on one table as a primary key but it exists on your current table as a technical key but you dont want to have the user have to enter the TK value. You can make the field on your screen the technical key and hidden, but he unique and user friendly field on the related table can be used and exposed to the user as the candidate key, or perhaps you can have the unique field on your table, validated against another table. Lookups can be associated to all screens.
|
Lookup Pattern | patterns.library.object_lookup_* |
A lookup pattern is almost identical to a finder pattern, except that the generated code passes back a value to a calling screen, and the criteria screen can be bypassed on calling. Refer here for an example for how to add a lookup pattern
|
Skeleton Pattern | patterns.library.skeleton_component_* |
This is a basic screen creator, it doenst have any immediate purpose associated with it like the other patterns, but it does allow the user to define and link a set of screens. You can define any widget, or indeed a grid or usergrid with sub widgets. You then associated the next screen is associated to. All the getters and setters component controllers and global forwards will be created for you leaving.
|