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 > > > > >
