[DISCUSSION] Make Back-Office screens dynamic
Locked
12
12
Re: [DISCUSSION] Make Back-Office screens dynamic
 
|
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 <[hidden email]> 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 > > |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
Hello James,
Thanks for the reference we will look into that. Regards, On Fri, Jan 10, 2020 at 03:50:23PM -0000, James Yong wrote: > Hi Gil, > > I wonder if this library helps for a start: > https://github.com/joshualjohnson/jquery.x > > Regards, > James > |
signature.asc (849 bytes)
Re: [DISCUSSION] Make Back-Office screens dynamic
Administrator
|
In reply to this post by James Yong-2
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 <[hidden email]> 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 >> >> |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
Administrator
|
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 <[hidden email]> 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 >>> >>> |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
Administrator
|
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 <[hidden email]> 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 >>>> >>>> |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
Hi Jacques,
Points taken. Thanks, James On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 > >>>> > >>>> > |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
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 <[hidden email]> wrote: > Hi Jacques, > > Points taken. > > Thanks, > James > > On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 > > >>>> > > >>>> > > > |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
Administrator
|
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 <[hidden email]> wrote: >> Hi Jacques, >> >> Points taken. >> >> Thanks, >> James >> >> On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >>>>>>> >>>>>>> |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: > >> Hi Jacques, > >> > >> Points taken. > >> > >> Thanks, > >> James > >> > >> On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 > >>>>>>> > >>>>>>> > |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > >> Hi Jacques, > > >> > > >> Points taken. > > >> > > >> Thanks, > > >> James > > >> > > >> On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 > > >>>>>>> > > >>>>>>> > > > |
Re: [DISCUSSION] Make Back-Office screens dynamic
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > > >> Hi Jacques, > > > >> > > > >> Points taken. > > > >> > > > >> Thanks, > > > >> James > > > >> > > > >> On 2020/01/11 10:46:03, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 > > > >>>>>>> > > > >>>>>>> > > > > > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |