Hi Gil

I used a type=groovy service to resolve the form location eg.
/*
*@paramater formLocaction (where the form resides in the system)
*@parameter formName (passed as request parameter)
* returns an Ofbiz form entity with all the normal functionalties
associated with ModelForm
* this is returned to the http request as a JSON objecct
*/
ModelForm form = FormFactory.getFormFromLocation(formLocation, formName,
entityModelReader, dispatchContext);

Angular handles the response through a formField service which reads each
Ofbiz formfields (JSON object) and creates a Angular reactive form from
there. The Angualr formFields Service mirrors the Ofbiz field types etc.

Regards

Gavin







On Tue, Dec 17, 2019 at 4:21 PM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello Gavin,
>
> Thanks for four feedback, that's very interesting !
>
> Could you elaborate about the OFBiz forms usage you did in your angular
> implementation ?
> You just used view-map with simple screen/form ?
>
> Cheers !
>
> Gil
>
> Le 12:26 - mardi 17 déc., Gavin Mabie a écrit :
> > Hi Taher
> >
> > I've been using Angular for custom apps over the past year.  This is my
> > approach:
> >
> > 1. Ofbiz deployed as an AppServer:
> > 1.1 Ofbiz controller resolves API request calls;
> > 1.2 Ofbiz Service Engine executes Services;
> > 1.3 Entity Engine for persistence;
> > 1.4 Returns JSON object - including Ofbiz context;;
> > 1.5 Ofbiz Forms used for additional business logic, fields etc;
> > 1.6 Ofbiz Screens not used at all.
> >
> > 2. Angular (On Apache HTTPD or Ionic/Cordova/JQueryMobile or even
> > JAVAFX(haven't tried this, but it's possible)):
> > 2.1 Typescripting types for Ofbiz entities used;
> > 2.2 Angular services for API calls corresponding to controller
> > request-mappings;
> > 2.3 Dynamic Angular Forms - based on Ofbiz Form defs;
> > 2.4 Other static content;
> >
> > 3. Authentication
> > 3.1 With JWT;
> > 3.2 Sessionless & no cookies;
> > 3.3 Ofbiz LoginWorker & Permission Engine for authorization;
> >
> > The big takeaway here is that Ofbiz Screens aren't used at all.  Ofbiz
> > Forms are used to set fields, execute services and deal with issues like
> > locale etc.
> >
> > Cheers
> >
> > gavin
> >
> >
> >
> >
> > On Sat, Dec 14, 2019 at 6:52 PM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> > wrote:
> >
> > > 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
> > > >
> > >
>

Reply via email to