You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by James Yong <ja...@apache.org> on 2020/02/23 14:58:55 UTC
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 <ja...@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 <ja...@apache.org> wrote:
> >> Hi Jacques,
> >>
> >> Points taken.
> >>
> >> Thanks,
> >> James
> >>
> >> On 2020/01/11 10:46:03, Jacques Le Roux <ja...@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 <gi...@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
> >>>>>>>
> >>>>>>>
>
Re: [DISCUSSION] Make Back-Office screens dynamic
Posted by James Yong <ja...@apache.org>.
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 <ja...@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 <ja...@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 <ja...@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 <ja...@apache.org> wrote:
> > > >> Hi Jacques,
> > > >>
> > > >> Points taken.
> > > >>
> > > >> Thanks,
> > > >> James
> > > >>
> > > >> On 2020/01/11 10:46:03, Jacques Le Roux <ja...@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 <gi...@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
> > > >>>>>>>
> > > >>>>>>>
> > >
> >
>
Re: [DISCUSSION] Make Back-Office screens dynamic
Posted by James Yong <ja...@apache.org>.
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 <ja...@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 <ja...@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 <ja...@apache.org> wrote:
> > >> Hi Jacques,
> > >>
> > >> Points taken.
> > >>
> > >> Thanks,
> > >> James
> > >>
> > >> On 2020/01/11 10:46:03, Jacques Le Roux <ja...@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 <gi...@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
> > >>>>>>>
> > >>>>>>>
> >
>