Hi Gil, I wonder if this library helps for a start: https://github.com/joshualjohnson/jquery.x
Regards, James On 2019/12/13 15:52:38, Gil Portenseigne <gil.portensei...@nereide.fr> wrote: > 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 > > > 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. > > 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 > * link being in origin context, the developer knows where he is and > where he wants to go > * Menu oriented management offers a quick vision on how the screen will > works > > * update-area seems to be a too technical name > * we always have to manage area to update manually > * too many areas to update become a headache and not only for the > developer > > 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. > > 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 > >
