Hi all, Done some refactoring for OFBIZ-11409: POC for Dynamic Screen Using MVVM to allow multiple view models working together. Will prepare a PR if there is community interest.
Regards, James On 2020/03/15 01:01:43, James Yong <jamesy...@apache.org> wrote: > Hi all, > > Updated the patch for OFBIZ-11409: POC for Dynamic Screen Using MVVM. > I think is worth checking out. > > Regards, > James > > On 2020/02/23 14:58:55, James Yong <jamesy...@apache.org> wrote: > > Hi all, > > > > I have created a JIRA issue for it > > i.e. OFBIZ-11409: POC for Dynamic Screen Using MVVM. > > > > Chose KnockoutJs because it uses only the data-bind attribute, instead of > > special attributes. > > > > Regards, > > James > > > > On 2020/01/15 10:52:14, Jacques Le Roux <jacques.le.r...@les7arts.com> > > wrote: > > > Hi James, > > > > > > I did not look into all details, but this one looks good indeed. > > > > > > Thanks > > > > > > Jacques > > > > > > Le 14/01/2020 à 16:49, James Yong a écrit : > > > > 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 > > > >>>>>>> > > > >>>>>>> > > > > > >
