Hello devs,
This mail introduce the last Chapter of our story that describe in which context we created some new decorators. First, we want to recall the common-theme effort objectives : The common-theme component is the default theme that define every screens that are available for theme surcharge, without technology information (css/html, vuejs or something like that). Every theme is based onto this common-theme that structure the application. Any theme can empower this structure its way, using it’s one technology. The idea is simple, isolating screen definition from technology syntax, let the technology implementation to the theme. Xml Screen and form definition must only be description of the structure. The “how it is render” is defined by default by the common-theme, and might be overloaded by a chosen theme. From these objectives arise the need to list structural descriptive decorator that exists or are added by our effort : The *FindScreenDecorator* : is the existing search screen decorator in OFBiz, it is composed in three sections : * A menu (party creation for instance : menu-bar) * Search criteria (search-option) * Results (search-results) The new *DetailsScreenDecorator* : is a new decorator to show a sum up of an object and its related data. Composed in five sections : * A menu (menu-bar) * A tab menu : to give access to related data into details section (tab-bar) * A summary that display main data of the object (summary) * An action menu (object modification, duplicate or specific actions : actions) * The detail : area that will display related data (details) This structure, in addition to give the display control to the theme, offer the developer not to think about the area to use when he wants to display more data concerning the object. Moreover, when performing actions, the developer do not need to know about the area to refresh, since the screen-engine has been improved to manage it for him. The new *EmbeddedScreenDecorator* : is a new decorator used to inject in an structure page area a specific screen. Its goal is to define what kind of data the screen will have to render to allow the theme to adapt the technology for data rendering. The sections are : * A menu (menu-bar) * An action menu (search filtering, history display…) * single : display of a single form * content : display a content (Image or document) * list : display a list of data Those can be loaded by functional decorator that take charge of basic data retrieval : As an example : *EmbeddedProductCategoryScreenDecorator* That is a specific decorator that implements the *EmbeddedScreenDecorator* and do the data retrieval of productCategory object : <screen name="EmbeddedProductCategoryScreenDecorator"> <section> <actions> <entity-one entity-name="ProductCategory" value-field="productCategory"/> <set field="productCategory" from-field="productCategory" global="true"/> <property-map resource="ProductUiLabels" map-name="uiLabelMap" global="true"/> <property-map resource="CommonUiLabels" map-name="uiLabelMap" global="true"/> </actions> <widgets> <include-screen name="EmbeddedScreenDecorator" location="component://common/widget/CommonScreens.xml"/> </widgets> </section> </screen> This avoid for every embedded screen using productCategory code duplication in data retrieval. The same logic can be applied to *DetailsScreenDecorator*. To see all that in action we are working into a simple demo, in a classical theme and an simple improved theme, we currently are creating a sum-up presentation with illustration and more details like code/video. I hope we will be able to share it with you soon enough. Best Regards signature.asc (849 bytes) Download Attachment |
Free forum by Nabble | Edit this page |