Hi, After gil remarks and test with the POC-Vue.js
We are now working with two new "action" usable by link - hyperlink * set-area * set-watcher and in container, we have added attribute watcher-name, and using auto-update-target as target set-area is used to update a containerId, and, most of the time, uses only for included containerId set-watcher put some "parameters" in a watcher-name when whatcher-name change, all containerId which watch it, use their auto-update-target as target and watcher-name content as parameters to update the container content. Hoping that this solution responds correctly to the problem raised Le 15/05/2020 à 18:08, James Yong a écrit : > 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 >> >> >>
