Hello, inline,
On 13/12/2019 12:47, Olivier Heintz wrote:
Hello Community,
[...]
1. homogeneous in each component and between components
This is the way started with the common-theme creation. Move all
structural and technical concept on the theming, promoting decorator
usage for screen structure
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
Yes reusability is a nice way to ease custom plugin development,
with KISS in mind for the developer. What do you refer as technical
modification ?
** menu and screen are decoupled, it's possible to change one without
modifications in the second
Isn't that already the case ? Not sure I understand what you mean ?
** one function, with maybe some parameters available on
installation/personalisation at the server level.
There I don't understand for sure, can you elaborate ?
Modularity is a concept where we store what we need to show.
We prefertolimit the modularity concept tothe simple expression,
"how to reuse or extend standard code".
Or to support this concept, we need to ensure each component work on
they cover :
controller: ensure to identify each in/out
screen: point to generate coherent rendering
3. be able to have in the OFBiz technical architecture, a layer dedicated to
functional/business consultant (some files or in SGBD)
Is really a finality for ourcommunity ?
For a software editor itcan be a good purpose but for us, is ouradded
value to create huge quantity of screen with massive parameter based on
business suggest ?
Step by step, we have currently some difficulty to convert ftl screen to
xml (1. homogenize).
We can take a true story to illustrate this : a screen createdfor
managingall partyrelationships.
First you create an isolatedscreen with a search on partyRelationship
entity with load from 'site parameters' to instantiate some potential filter
Who look the relation (to/from), manage history (Y/N), filter relation
type, role and some other
This first step is a big task to arrive on satisfactory outcome.
After sharing with end user, you load and configure the screen with
desiredinformation on global page
The end user return you that it's not what he want, he just want only a
specific relationType 'A', easy change site parameters
But heforgot the case of relationType B when roleTo is 'C' ... damned
you can't use your generic screen as it and need to override all the
search part
Who said override a part said override all the screen.
In final try to make a generic screen based on supposition make 2
to 3 days,
Search it on library, test, configure, valid based on business
discussion easly 1 to 2 days,
Create screen from scratch with business condition:3 hours
We don't talk about the problematic to cover a support on production
site based on generic screen, between screen variable, database variable
crossed on user/global screen/context and huge problem when screen a
created form database information: impossible to release. When you are
on continuous integration, impossible to ensure a stable state because
all isn't code.
Like previous message, it seems to us that a layer dedicated to
functional/business consultant it's a dream, and we win to concentrate
effort on create easily coherent and homogenize screens, and that should
be the first step in my opinion.
In our past experience we tried to implement such configuration layer,
the experiment was a failure :
- Lost of confidence of the customer (and ourselves) where the
configuration was updated with no control into production (not through a
VCS, with code review etc.)
- Lost of efficiency for the developer to implement the
configuration layer for complex cases (such as partyRelationship)
Adjusting existing Screens using xml should not be that complex, and
accessible to a functional/business consultant. If not we should analyze
what do we need to improve in that way.
Nicolas
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
