Hello Taher,
The proposition you saw with your first glance is about :
* Intent : describing into a link/menu definition, the way that the
dynamically rendered form will refresh the screen upon submission
success
* Implementation : adding a tag that will generate a refreshment event
on submission within the screen that is inserted into the DOM by the
augmented link (like a success callback).
That is one step of the proposal, but yes i think you got it well.
We have to make clear that our intent is not to add lot of new widget
augmentations to get dynamic screens. This new tag that should have been
named "callback-update-area", would complete the already existing
"<on-event-update-area" form feature. Giving more control to the origin
screen.
For my personal point of view, your point come at the good timing to get
considered before going too far. But in fact in our attempts, i feel
like we did not go that far to get something working nicely as a first
step.
So thanks for your feedback, since i am not familiar enough with Single
Page Application aka SPA frameworks (in France SPA is the main french
Animal Protection Association :-) ) we had a discussion with Samuel and
Mathieu to build you a better answer to your question (i.e. if SPA will
fit in our effort).
Our research is about **screen definition** for back office application,
so we are not talking about technology but about screen structure
definition concepts.
In my opinion SPA (based on screen definitions) is a technical
implementation, so it is not part of our prime target.
Those structure definition concepts must be well thought enough to be
compliant with any technical implementation in theme (based on
common-theme).
In that vision implementing a theme for SPA application should be
possible, but in our opinion a gigantic task to support the screen
engine. We think that for back office application, we should stay with
the classic way to implement screens, and improve it to get more
efficient.
For front office, and high expectation back office application, if SPA
is to be used, implementing it with a custom theme and freemarker is the
simpler way to be efficient.
PS: i did signed Néréide Team in my precedent email, but it is not a
company initiative, this should have been signed Leila, Nicolas and Gil.
Sorry for that.
Thanks
Gil
Le 19:51 - samedi 14 déc., Taher Alkhateeb a écrit :
> Hello Gil,
>
> Great research on the subject, thank you for sharing.
>
> I could be wrong here, but at a first glance it seems you want to
> essentially create a tag "<update-area ..." which essentially renders
> another screen dynamically upon clicking / activating the URL. If my
> understanding is correct, then most likely they way you want to
> implement this is probably some web request to the backend which
> renders back a partial screen that you insert into the DOM right?
>
> If what I describe above is close to your idea, then I think the
> implementation might be relying on the server to do the work of
> painting instead of relying on the browser to do the heavy lifting.
> This also only works with one widget, which is the URL widget as
> opposed to having a general purpose dynamic behavior in the system
> (assuming this is desired).
>
> However, having a general purpose dynamic behavior means we need a
> method to bind variables to values at the front end without consulting
> the back-end. This reduces the load on the server and provides a
> faster / richer experience to the user. But it would be too painful to
> rely on plain javascript or jQuery to achieve such a result which is
> the reason why frameworks like React, Vue, and others emerged as
> modern SPA frameworks. Adopting an SPA framework would provide dynamic
> behavior (everywhere) instead of certain widgets, and it can be
> expanded to even include page navigation and whatnot. Of course this
> is more work than what you're suggesting here. but if we continue with
> such small improvements, you might end up having lots of javascript
> (maybe that's already the case) which might increase the difficulty of
> adopting an SPA framework in the future.
>
> So it comes down to this question (which I don't necessarily have an answer
> to):
>
> Do you want an SPA framework now or in the future, or do you want to
> continue with status quo into the future? If you want an SPA
> framework, then we should minimize the usage of custom javascript
> everywhere and adopt a framework that completely replaces all the
> javascript that currently exists for all the widgets. If not, then we
> can proceed with your proposition and any others in the future knowing
> that an overhaul is not needed.
>
> Cheers,
>
> Taher Alkhateeb
>
> On Fri, Dec 13, 2019 at 6:52 PM Gil Portenseigne
> <gil.portensei...@nereide.fr> wrote:
> >
> > Chapter One: How to manage the updating area
> >
> > Hello,
> >
> > After different discussions already listed by Taher [1-9], Leila,
> > Nicolas and me tried another approach.
> > Instead of analyzing how to implement different functionalities offered
> > by modern js framework, we did analyzed how end user use, in general,
> > OFBiz and where we, as an integrator, waste more time to create a
> > screen.
> >
> > To help on this huge task, we set some basic rules :
> > * Work only on screens supported by the theme, defined mainly in xml
> > * This concerns only screens used for back-office applications,
> > oriented to manage data
> > * A developer does not have to know all of js language (or other)
> > but can concentrate on the process/view with the end user to
> > manage a data
> >
> >
> > After a first brainstorm, we have identified three major cases :
> > 1. Navigation and data display
> > 2. View event result (data modification, calculation service, ...)
> > 3. Update an area to refresh data (after data modification)
> >
> > Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
> > will be simple to add), we concentrate our attention on case 3.
> >
> > To update an area, we follow this pattern
> >
> > 1. We start from a context that display different information
> >
> > 2. That context display a submit form, use a link or another
> > mechanism to call an OFBiz event
> >
> > 3. After receiving the event return, we refresh the desired area
> > with parameters that can come from origin context or from event
> > return.
> >
> >
> > Currently with the screen widget, we can use within a form the element
> > `<on-event-update-area event-type="submit" area-id="" area-target=""/>`.
> >
> > The problem with this use, is that your form needs to know the origin
> > context, to identify what are the areas to update and what are the
> > target to use for the refresh.
> >
> > So your form needs to know where it comes from, what information need to
> > be updated in OFBiz and what will be updated after.
> >
> > This increases complexity for the developer in the way that current form
> > implementation manages :
> > * the data and target to communicate with the server
> > * the behaviour (refreshment) to apply when receiving server response.
> >
> > Example :
> > <form name="EditPartyRoleCustomScreen" type="single"
> > target="createPartyRole">
> > <field name="partyId"><hidden/></field>
> > <field name="roleTypeId">...
> > <on-event-update-area event-type="submit" area-id="PartyRoles_area"
> > area-target="PartyRolesCustom">
> > <parameter param-name="partyId"
> > from-field="parameters.partyId"/>
> > </on-event-update-area>
> > </form>
> >
> > If you want to reuse the same form, you need to create another screen
> > with a new form to redefine the on-event-update-area (for instance
> > create a PartyRole).
> >
> > We change the thinking, because since it is the starting context that
> > better knows itself, it's the starting context that will realize the
> > updating operation. The starting context is the screen/menu that call
> > this form.
> >
> > In general a form is contained in a screen (classic) that is called
> > through a link. So we move the idea on this link :
> >
> > <link target="CreatePartyRole" link-type="layered-modal">
> > <parameter param-name="partyId"
> > from-field="customerParty.partyId"/>
> > <update-area area-target="ResumeInfoCustomer" area-id="xxx">
> > <parameter param-name="partyId"
> > from-field="customerParty.partyId"/>
> > </update-area>
> > </link>
> >
> > And the form :
> >
> > <form name="EditPartyRole" type="single"
> > target="createPartyRole">
> > <field name="partyId"><hidden/></field>
> > <field name="roleTypeId">...
> > </form>
> >
> > With this logic you can define a new usage of createPartyRole
> > without redefining a form just :
> >
> > <link target="CreatePartyRole" link-type="layered-modal">
> > <parameter param-name="partyId"
> > from-field="partyRelationship.partyIdTo"/>
> > <update-area area-target="MyRelationAndDetail"
> > area-id="xxx">
> > <parameter param-name="partyId"
> > from-field="partyRelationship.partyIdTo"/>
> > <parameter param-name="partyRelationTypeId"
> > value="IRL_LIKE"/>
> > </update-area>
> > </link>
> >
> > After some use we identified as pro and con feedback :
> > * updating form is reusable and contains only code related to the
> > form action
> > * link being in origin context, the developer knows where he is and
> > where he wants to go
> > * Menu oriented management offers a quick vision on how the screen will
> > works
> >
> > * update-area seems to be a too technical name
> > * we always have to manage area to update manually
> > * too many areas to update become a headache and not only for the
> > developer
> >
> > We did not explain how we have done it, to try to focus the discussion
> > on the principles.
> >
> > It would be a pleasure to have some criticism of this approach, and we
> > would try, in a second chapter to introduce other concepts that appeared
> > after the screens were made more dynamic and others to lowers the
> > identified cons.
> >
> > Thanks,
> >
> > The Néréide Team
> >
> > [1] https://s.apache.org/rf94
> > [2] https://s.apache.org/g5zr
> > [3] https://s.apache.org/XpBO
> > [4] https://s.apache.org/YIL1
> > [5] https://s.apache.org/836D
> > [6] https://s.apache.org/DhyB
> > [7] https://s.apache.org/Lv9E
> > [8] https://s.apache.org/zKIo
> > [9] https://s.apache.org/D6jx
> >
