Hi Jacques, Points taken.
Thanks, James On 2020/01/11 10:46:03, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Also jquery.x is not much maintained, last changes are from June 2015... > > Le 11/01/2020 à 11:44, Jacques Le Roux a écrit : > > Just noticed it needs Bower to install and at the moment Bowers says > > > > "...psst! While Bower is maintained, we recommend using Yarn > > <https://yarnpkg.com> and Webpack <https://webpack.js.org/> or Parcel > > <https://parceljs.org/> for front-end projects read how to migrate > > <https://bower.io/blog/2017/how-to-migrate-away-from-bower/>! " > > > > And npm warns about it > > > > Jacques > > > > > > Le 11/01/2020 à 10:32, Jacques Le Roux a écrit : > >> I remember having read about MVVM years ago, quite interesting, thanks > >> James! > >> > >> Jacques > >> > >> Le 10/01/2020 à 16:50, James Yong a écrit : > >>> 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 > >>>> > >>>> >
