Hello Gil, (and Néréide Team) Thank you for sharing research and formal process to be concentrated on concept first.
just short remarks inline Le 13/12/2019 à 16:52, Gil Portenseigne a écrit : > Chapter One: How to manage the updating area > > Hello, > > After different discussions already listed by Taher [1-9], Leila, > Nicolas and me tried another approach. > Instead of analyzing how to implement different functionalities offered > by modern js framework, we did analyzed how end user use, in general, > OFBiz and where we, as an integrator, waste more time to create a > screen. > > To help on this huge task, we set some basic rules : > * Work only on screens supported by the theme, defined mainly in xml > * This concerns only screens used for back-office applications, > oriented to manage data > * A developer does not have to know all of js language (or other) > but can concentrate on the process/view with the end user to > manage a data ++1 > > > After a first brainstorm, we have identified three major cases : > 1. Navigation and data display > 2. View event result (data modification, calculation service, ...) > 3. Update an area to refresh data (after data modification) > > Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff > will be simple to add), we concentrate our attention on case 3. there are still some point to study for 1 and 2, but one point by one point is a good approach > > To update an area, we follow this pattern > > 1. We start from a context that display different information > > 2. That context display a submit form, use a link or another > mechanism to call an OFBiz event > > 3. After receiving the event return, we refresh the desired area > with parameters that can come from origin context or from event > return. > > > Currently with the screen widget, we can use within a form the element > `<on-event-update-area event-type="submit" area-id="" area-target=""/>`. > > The problem with this use, is that your form needs to know the origin > context, to identify what are the areas to update and what are the > target to use for the refresh. > > So your form needs to know where it comes from, what information need to > be updated in OFBiz and what will be updated after. > > This increases complexity for the developer in the way that current form > implementation manages : > * the data and target to communicate with the server > * the behaviour (refreshment) to apply when receiving server response. > > Example : > <form name="EditPartyRoleCustomScreen" type="single" > target="createPartyRole"> > <field name="partyId"><hidden/></field> > <field name="roleTypeId">... > <on-event-update-area event-type="submit" area-id="PartyRoles_area" > area-target="PartyRolesCustom"> > <parameter param-name="partyId" from-field="parameters.partyId"/> > </on-event-update-area> > </form> > > If you want to reuse the same form, you need to create another screen > with a new form to redefine the on-event-update-area (for instance > create a PartyRole). > > We change the thinking, because since it is the starting context that > better knows itself, it's the starting context that will realize the > updating operation. The starting context is the screen/menu that call > this form. > > In general a form is contained in a screen (classic) that is called > through a link. So we move the idea on this link : > > <link target="CreatePartyRole" link-type="layered-modal"> > <parameter param-name="partyId" > from-field="customerParty.partyId"/> > <update-area area-target="ResumeInfoCustomer" area-id="xxx"> > <parameter param-name="partyId" > from-field="customerParty.partyId"/> > </update-area> > </link> > > And the form : > > <form name="EditPartyRole" type="single" target="createPartyRole"> > <field name="partyId"><hidden/></field> > <field name="roleTypeId">... > </form> > > With this logic you can define a new usage of createPartyRole > without redefining a form just : > > <link target="CreatePartyRole" link-type="layered-modal"> > <parameter param-name="partyId" > from-field="partyRelationship.partyIdTo"/> > <update-area area-target="MyRelationAndDetail" area-id="xxx"> > <parameter param-name="partyId" > from-field="partyRelationship.partyIdTo"/> > <parameter param-name="partyRelationTypeId" > value="IRL_LIKE"/> > </update-area> > </link> > > After some use we identified as pro and con feedback : > * updating form is reusable and contains only code related to the > form action +1 > * link being in origin context, the developer knows where he is and > where he wants to go +1 > * Menu oriented management offers a quick vision on how the screen will > works +1 > > * update-area seems to be a too technical name 0 because name seem clear > * we always have to manage area to update manually +1 UI is area management and their content Other case is sometime area area watching event to update themself > * too many areas to update become a headache and not only for the > developer +1 > > We did not explain how we have done it, to try to focus the discussion > on the principles. > > It would be a pleasure to have some criticism of this approach, and we > would try, in a second chapter to introduce other concepts that appeared > after the screens were made more dynamic and others to lowers the > identified cons. In the POC-Vuejs we have started working on similar idea (using logical field name for area and field value send by the caller) but not at this concept level and your approach is very clear (and good) to be able to be implemented after the and of the discussion. It will be simple to implement it when it it will be time. Thank you. > > Thanks, > > The Néréide Team > > [1] https://s.apache.org/rf94 > [2] https://s.apache.org/g5zr > [3] https://s.apache.org/XpBO > [4] https://s.apache.org/YIL1 > [5] https://s.apache.org/836D > [6] https://s.apache.org/DhyB > [7] https://s.apache.org/Lv9E > [8] https://s.apache.org/zKIo > [9] https://s.apache.org/D6jx >
