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