[POC Vue.Js] first presentation / summary

[holivier]

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.

Current POC status is : done with example for some screen / field /menu, waiting user testing feed back before starting partymgr migration.

Our demo platform is https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin / ofbiz

the chosen architecture is,
1. a new ScreenViewHandler which
- use new renderer for screen / form /menu
- to return a json with 2 map
* ViewScreen with detail about presentation (similar to xml tag and properies)
* ViewEntity with data to populate ui generated (extract from screen/forms data)
2. a vue.js app with one component per "ofbiz xml tag" (similar to macro ftl)
3. using the event-update-area to do the extra action (ex: update a watcher, and so portlet which have subscribed to this watcher is updated)

It's a POC, so it's a support to discuss about technical or GUI point. All current choices can be challenged to find the correct or strong solution
and quickly see the result.

We work on a agile mode, so most of the parts are prototype which should be reviewed and maybe finalized.

Documentation has begun
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_frontjs_portal

if you want to test it in your environment, the 3 plugins
* vusjsportal : all vuejs components and new handler and new renderers and all common files for all fjs components
* examplefjs : specifics files for the ofbiz example component using vue.js
* flatgreyfjs : dedicated theme for vue.js with vuetify
are available on https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins.

I don't detail more, it's better to answer questions or remarks than a too long mail !

Next step seems to be to migrate all party portlets to
1. check if current component are enough for all common screens / fields / menus
2. have more real use case to test

[Victor Hernadez]

Hi Olivier,

Terrific contribution, IMO seems like a serious option for
frontend modernization to be considered by OFBiz contributors/commiters,
I'm going to try the POC on my end and will check the options to stay tuned
of your effort.

Kind Regards,
Victor

On Thu, Oct 31, 2019 at 10:03 AM Olivier Heintz <[hidden email]> 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.
>
> Current POC status is : done with example for some screen / field /menu,
> waiting user testing feed back before starting partymgr migration.
>
> Our demo platform is
> https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin
> / ofbiz
>
> the chosen architecture is,
> 1. a new ScreenViewHandler which
> - use new renderer for screen / form /menu
> - to return a json with 2 map
> * ViewScreen with detail about presentation (similar to xml tag and
> properies)
> * ViewEntity with data to populate ui generated (extract from screen/forms
> data)
> 2. a vue.js app with one component per "ofbiz xml tag" (similar to macro
> ftl)
> 3. using the event-update-area to do the extra action (ex: update a
> watcher, and so portlet which have subscribed to this watcher is updated)
>
> It's a POC, so it's a support to discuss about technical or GUI point. All
> current choices can be challenged to find the correct or strong solution
> and quickly see the result.
>
> We work on a agile mode, so most of the parts are prototype which should
> be reviewed and maybe finalized.
>
> Documentation has begun
>
> https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_frontjs_portal
>
> if you want to test it in your environment, the 3 plugins
> * vusjsportal : all vuejs components and new handler and new renderers and
> all common files for all fjs components
> * examplefjs : specifics files for the ofbiz example component using vue.js
> * flatgreyfjs : dedicated theme for vue.js with vuetify
> are available on https://gitlab.ofbizextra.org/ofbizextra/ofbizplugins.
>
> I don't detail more, it's better to answer questions or remarks than a too
> long mail !
>
> Next step seems to be to migrate all party portlets to
> 1. check if current component are enough for all common screens / fields /
> menus
> 2. have more real use case to test
>
>
>

[Mathieu Lirzin]

Hello Olivier,

Olivier Heintz <[hidden email]> writes:

> 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.
>
> Current POC status is : done with example for some screen / field /menu, waiting user testing feed back before starting partymgr migration.
>
> Our demo platform is https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin / ofbiz
>
> the chosen architecture is,
> 1. a new ScreenViewHandler which
> - use new renderer for screen / form /menu
> - to return a json with 2 map
> * ViewScreen with detail about presentation (similar to xml tag and properies)
> * ViewEntity with data to populate ui generated (extract from screen/forms data)

Providing a JSON view handler is very interesting because it enables any kind
of Javascript front-end to consume data rendered by existing OFBiz screens
(with data preparation, etc).  This contributes to the current effort of
implementing a REST API by enabling consumers to have a JSON representation of
the retrieved data which is convenient to manipulate from Javascript [1].

Would you be interested in spending some time integrating this view handler
inside the framework?

The requirements for such task would be to lint the code, write some
integration tests, some javadoc, some comments explaining the non-obvious
parts of the implementation, ... well a non-negligeable amount of work which
is important for maintainability reasons.

For example one requirement would be to use ‘org.apache.ofbiz.base.lang.JSON’
instead of ‘org.json.simple.JSONObject’ in order to avoid depending on
multiple JSON libraries.

Moreover on the features side, it might be interesting to make the
presentation related stuff optional for consumers only interested by the data
aspect of the data.

What do you think?

[1] https://issues.apache.org/jira/browse/OFBIZ-4274

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[holivier]

answer inline

Le 27/11/2019 à 19:02, Mathieu Lirzin a écrit :

> Hello Olivier,
>
> Olivier Heintz <[hidden email]> writes:
>
>> 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.
>>
>> Current POC status is : done with example for some screen / field /menu, waiting user testing feed back before starting partymgr migration.
>>
>> Our demo platform is https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main with admin / ofbiz
>>
>> the chosen architecture is,
>> 1. a new ScreenViewHandler which
>> - use new renderer for screen / form /menu
>> - to return a json with 2 map
>> * ViewScreen with detail about presentation (similar to xml tag and properies)
>> * ViewEntity with data to populate ui generated (extract from screen/forms data)
>
> Providing a JSON view handler is very interesting because it enables any kind
> of Javascript front-end to consume data rendered by existing OFBiz screens
> (with data preparation, etc).  This contributes to the current effort of
> implementing a REST API by enabling consumers to have a JSON representation of
> the retrieved data which is convenient to manipulate from Javascript [1].
>
> Would you be interested in spending some time integrating this view handler
> inside the framework?

of course, I can created a Jira with the java and update them when there are remarks or discussions
>
> The requirements for such task would be to lint the code, write some
> integration tests, some javadoc, some comments explaining the non-obvious
> parts of the implementation, ... well a non-negligeable amount of work which
> is important for maintainability reasons.
the amount of work is not the main problem ;-)
My knowledge and skill will be more difficult to solve,
I am a business/functional consultant and so a java copy/paste developer (or a "java simple/procedural" business process developer)
not a java framework developer.
In the team I'm working, other Co-workers are front-end  developer or profile similar than me.

So,
1) javadoc no problem and documentation in adoc format no problem too
2) cleaning code, and applying best practice, no problem if reviewer can give me some link or example
3) integration test, when I read the ModelFormFieldTest.java I don't understand what it does and the java ... so I will need some help for this sub-task
>
> For example one requirement would be to use ‘org.apache.ofbiz.base.lang.JSON’
> instead of ‘org.json.simple.JSONObject’ in order to avoid depending on
> multiple JSON libraries.
Clear, I have done it.
Thank you for the remark

>
> Moreover on the features side, it might be interesting to make the
> presentation related stuff optional for consumers only interested by the data
> aspect of the data.
>
> What do you think?
Yes it's in the POC plan, but currently we are more focus on having a clear user demonstration in a business environment.
This month a large part of Party component have been done and we are working on solving all bugs/"form xml functionality not yet implemented"
Hoping to have a usable demo next week. (https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs)

Next week I will do a mail with the detail of what is usable and which next step are possible
If you or community think that implemented this option is a priority, we will do it, I think it will not too difficult.
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-4274
Yes I know it, but very too technical for me, too many word I don't understand ;-)
>

[Mathieu Lirzin]

Olivier Heintz <[hidden email]> writes:

>> Would you be interested in spending some time integrating this view handler
>> inside the framework?
>
> of course, I can created a Jira with the java and update them when
> there are remarks or discussions

Excellent. :-)

>> The requirements for such task would be to lint the code, write some
>> integration tests, some javadoc, some comments explaining the non-obvious
>> parts of the implementation, ... well a non-negligeable amount of work which
>> is important for maintainability reasons.
> the amount of work is not the main problem ;-)
> My knowledge and skill will be more difficult to solve,
> I am a business/functional consultant and so a java copy/paste developer (or a "java simple/procedural" business process developer)
> not a java framework developer.
> In the team I'm working, other Co-workers are front-end  developer or profile similar than me.
>
> So,
> 1) javadoc no problem and documentation in adoc format no problem too

For a JSON screen view handler I guess most documentation effort would be in
Javadoc making clear what kind of XML elements is handled by a method, what
cases are considered and what are the expected effects, stating if ‘null’
values are accepted and potentially returned.

The issue is that some interfaces like ‘FormStringRenderer’ are not documented
so it would be nice to add the documentation for those interface too.

The following link provides good advice and conventions for Javadoc:

    https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#terminology

> 2) cleaning code, and applying best practice, no problem if reviewer can
> give me some link or example

Works for me. The first step is to remove commented code and run ‘gradlew
check’, to ensure that before and after your changes no linting errors are
introduced (alternatively you can configure your IDE to run ‘checkstyle’ lint
tool on your source files).

I can help with best practice guidance if needed.

> 3) integration test, when I read the ModelFormFieldTest.java I don't understand what it does and the java ... so I will need some help for this sub-task

ModelFormFieldTest is indeed tricky to understand because the semantics of the
tested feature is complex (which motivated writing those tests in the first
place).  I guess what is hard for you to understand is related to the usage of
lambdas denoted by ‘… -> …’ and passed as parameter to the
‘ModelFormField#from(Consumer<ModelFormFieldBuilder>)’ static method ?

IMO There is no need to use lambdas to write maintainable code so this is not
a blocker.

Regarding the kind of tests that matters for JSON rendering, it is important
for example to make sure that screen values are mapped to an adequate JSON
types (for example that boolean, numbers, list of values), that <action>
elements are run and have the expected effects, that pagination is working and
that ‘null’ values are handled as intended.

>> Moreover on the features side, it might be interesting to make the
>> presentation related stuff optional for consumers only interested by the data
>> aspect of the data.
>>
>> What do you think?
> Yes it's in the POC plan, but currently we are more focus on having a clear user demonstration in a business environment.
> This month a large part of Party component have been done and we are working on solving all bugs/"form xml functionality not yet implemented"
> Hoping to have a usable demo next week. (https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs)
>
> Next week I will do a mail with the detail of what is usable and which next step are possible
> If you or community think that implemented this option is a priority, we will do it, I think it will not too difficult.

Since you seem OK with spending some time in the reviewing process, feel free
to open a ticket on Jira with a first version that I can start reviewing.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Nicolas Malin-2]

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

[holivier]

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
>

[Nicolas Malin-2]

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

[holivier]

Le 13/12/2019 à 23:58, Nicolas Malin a écrit :

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

only task needed too many training before be able to do it
xml with sxd and so auto-completion and auto-documentation are not technical

>>     ** 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 ?
last mail from Gil is the answer
>>     ** one function, with maybe some parameters available on installation/personalisation at the server level.
personalisation for gui is sometime understanding as ability for the end-user to change some screen elements for himself.
When I say  "at the server level" I mean, in a implementation process, manage as part of production environment (with a version control tools, like
your good remark below about continuous integration process)
and not for a simple user but for business user group.

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

+1

>
>> 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 ?
I don't see link with editor or community, but of course for not open source editor, parameters are mandatory :-)
> Step by step, we have currently some difficulty to convert ftl screen to
> xml (1. homogenize).
Clearly each evolution should be manage as part of (already decided) current action.

Add some parameters for existing screens/forms should be done only when a use case exist and simplifying existing situation.
If screen is with ftl, migration should be done first, Clearly.

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

Very good example, when I speak about parameters, I do not say be able to do all implementation process with parameters.
The 80-20 rule is always true.
Most of personalisation are very simple, remove a menu option, add a hidden parameter (ex roleType) in a search form, ...
I think theses tasks could be done with parameters
but the 20% of specifics screen should be develop

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

:-) I have other "during task" in mind, but it's maybe link to the expertise domain of each :-)
In implmentation process, it's needed to have multiple profil to work together
Not a group of expert which not understand the others, but multi-knowledge people with expertise domain to be able to help other co-worker.

in a functional consultant point of view (TROLL):
if "valid needed, based on business discussion" is easly 1 to 2 days,
Search it on library, test, configure, is, during discussion and on a agile perspective 2 hours
Create screen from scratch with business condition is 1 or 2 days

:-)


>
>
> 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.
Realy a very important point, You are right, parameters should be in the VCS

>
> 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.
Only a evolution for a large functionality software, but maybe it's to early for OFBiz.
I don't think so
>
> 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)
exactly like mini-lang code with more than 5-10 line

GUI scenario test help to have no regression and documentation for each business use case.
>
> 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.

Thank you very much for your remarks, they help to be more clear and focus on the good discusion points

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