Hello Community, After Nicolas remarks (thanks to the team for sharing their experiences and thoughts)
I propose to discuss about GUI best practice in OFBiz, which one are the most priority for the future. I have already described my point of view and approach 3 years ago in a mail [1] and I continue on same ideas ;-) Maybe, the priorities are not the same for the front-end and the back-end, I propose to start discussion by the back-end. 1. homogeneous in each component and between components 2. modularity : * having "micro-service" on a GUI point of view ** having a level (screen / portlet / screenlet /...) which are able to be use in a multiple context without technical modification ** menu and screen are decoupled, it's possible to change one without modifications in the second ** one function, with maybe some parameters available on installation/personalisation at the server level. 3. be able to have in the OFBiz technical architecture, a layer dedicated to functional/business consultant (some files or in SGBD) I give only the first 3 to help discussion focus on main priorities. When there will be a consensus for the first 3, it will be time to discuss for the next 3 ;-) My wording are maybe/certainly not correct and often bad wording create confusion, so correct me on idea and/or wording. Olivier [1] https://ofbiz.markmail.org/thread/s7pf246hk3uc2mlq or [1] https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui Le 05/12/2019 à 16:44, Nicolas Malin a écrit : > Hello, > I tend to agree with Mathieu to concentrate the effort on json to > integrate Vue.js or some other js framework. > On 31/10/2019 17:03, Olivier Heintz wrote: >> Hi Community, >> >> As explained in a previous mail, we (me and others co-worker in a company I >> am working for) are working on a POC for using Vue.js as GUI generated >> from the current screens/forms/menu xml ofbiz files. >> The customer goals is to be able to migrate a lot of existing Portal / >> portlet developed with ofbiz R13.07 on trunk and on a modern GUI. >> >> The main customer specification / requirement are, for the first step of >> migration >> 1. minimum of modifications on xml file, to have the easier and quicker >> migration >> 2. same GUI rules, to facilitate user acceptance >> 3. new GUI for a component should be working with classic GUI for other >> components >> Enhancement can be possible but will be applied in a second step with >> productOwner check and validation. [...] > After the rollback of all the work done at Nereide usingportal page to > manage screen, we came to the conclusion that to create user friendly > interfaces, based on customer feedback, the following constraintsare a > good goal to achieve: > > * simple to use : user keep his concentration on his current work > * simple to develop : "make it simple" concept, limit the code but all > can be read from screen source. > * naturally extensible : respect the common theme system. > > Our conclusion(Gil, Leila and me)is that the solution isn't about the > technology but toidentify what we really need. > > Finally we determine some basics rules and concept to generate strong > screens. We are also currently workingon a POC and some first try with > few code are reallyencouraging. I will detailour work onanother thread > as soon as it will be presentable. > > So allto say, if you also wantto improve application's screen on > trunk,you maywant to see what we have experimented and may want to > benefit from our experience on this part. > > Cheers, > Nicolas >
