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 > > >
