HI Gil, In your posting your mentioned: In previous thread Can you provide a link to that thread?
Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Fri, May 15, 2020 at 6:08 PM James Yong <jamesy...@apache.org> wrote: > Hi Gil, > > Sorry for the late reply. > I agree that button actions should be decoupled from forms. > Shall we continue with Part 3? > > Regards, > James > > On 2020/01/10 17:58:59, Gil Portenseigne <gil.portensei...@nereide.fr> > wrote: > > Hello ! > > > > In previous thread we focused on the process of how to define a dynamic > > workflow that raises some questions. > > > > Let's go back to our principles: we have to find simple things, limit > > the possibilities (do little but good) and remember that on the > > backoffice it's end-users who are focused on specific tasks. > > > > To make it simple, implement screen dynamism that will generate > > alterations of the dom, to limit side effects, we establish the > > following principles: > > * We can only ask for an update of the area known by the calling > > element. > > > > Knowing that the element of coherence in the screen engine is the > > screen itself, we can refine this rule on the following basis > > * An element triggering a screen update, can only update elements > > present within the screen where it belongs. > > > > Why did we made this choice? We will see it below, but the goal is > > always to make writing easier for the developer by avoiding him to > > wonder what is the value of the area to be refreshed. > > > > If for various reasons we need to update an area outside the screen > > where the call is located, it is better to ask for a global refresh of > > the page. (Always simpler for the developer) > > > > Another point to aim for simplicity, which zone to update? > > We can identify several actions: > > * I'm on an item and I want to see related items data > > * I'm on an item and I want to refresh that item data > > > > The first case is a defined relation, I will refresh this area with > > this screen, area that will be generally determined by the decorator. > > Then, we will talk about the so-called embedded screens: "embedded > > screen". > > > > The second case is about updating oneself following some sort of > > procedure, I have to refresh myself. Nothing is best than "knowing it > > yourself". > > > > It was needed to implement an optimization to facilitate the application > > of these principles. The idea is that in most cases, the developer > > doesn't have to think about which zone he needs to specify to display > > his data. > > > > In order to apply the operation in a homogeneous way, we added new > > structuring decorators in the common-theme with dedicated zone > > identifiers allowing each implementation to exploit the refresh. > > > > For example, for a detail screen of an entity (e.g. product categories), > > we use a "DetailScreenDecorator" decorator. The main refresh area > > "Associated Objects Details" is the main dynamic area of the screen. > > We are going to identify precise areas so that each theme can be used in > > knowledge: > > * breadcrumb: to display how we see the path to an entity > > * summary: to display a quick information on this entity > > * action: different actions available to this entity > > * navigation: links or other element who help user to navigate on > > the entity relation > > * detail: to display a relation > > > > In our searchn once the list of needs is done, we have exploited the > > areas for our theme as follows: > > > > > > +-----------------------------------------------------+ > > | Catalog -> Category (BreadCrumb) | > > | +-------------------------------------------------+ | > > | | +------------+| | > > | | | Quick Menu || | > > | | +------------+| | > > | | | | > > | | Category Summary | | > > | | | | > > | +-------------------------------------------------+ | > > | | > > | +-------------------------------------------------+ | > > | |Tab Menu | menu1 | menu2 | menu3 | | > > | |-------------------------------------------------| | > > | | <div id="detailArea"> | | > > | | | | > > | | Associated Objects Details | | > > | | | | > > | | | | > > | | | | > > | | | | > > | +-------------------------------------------------+ | > > +-----------------------------------------------------+ > > > > > > The decorator will set a variable "detailArea" in the context of this > > screen, which contains the id of the div to refresh to present a new > > screen (products of the category for example). > > > > The positioning of this type of variable facilitates the constraint on > > the developer to refresh an area of the screen, if he wants to code the > > Tab menu in a simplified way. > > > > Also we are speaking about technical decorator, because we think that it > > is necessary to add business decorators implementing those, facilitating > > the recovery of information from the main object that is processed. > > > > But we will discuss this in another mail Chapter 3 : promoting decorator > > usage > > > > Best Regards, > > > > Leila, Nicolas and Gil > > > > > > >
