Hi Jacques, Found another JQuery friendly MVVM framework to consider: https://knockoutjs.com/. Support data-binding and computed properties etc.
Regards, James On 2020/01/11 12:56:24, James Yong <jamesy...@apache.org> wrote: > 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 > > >>>> > > >>>> > > >
