[PROPOSITION] Demos: replace old by trunk framework only

[Jacques Le Roux]

Hi Taher, Julien

I'm all for and looking forward for a generic solution.

I still believe (like Julien) it's better to hide, than remove or ignore, those links in the meantime. They are there for already too long...

Jacques


Le 22/08/2018 à 18:52, Taher Alkhateeb a écrit :

> Hi Julien,
>
> Good ideas, and this is a good start to try and tackle the problem.
> Whatever we do, we must not keep "ghosts" or things that are waiting
> for specific outside plugins. The framework should _never_ know
> anything about the outside. This is a fundamental architectural
> concept in any layered software system.
>
> I'm ready to help if needed, and I think there are many ways to fix
> this problem. As you said one way is to extend webapps, another is
> perhaps to optionally include freemarker templates that match a
> certain pattern if they exist. In other words, you provide a generic
> plugin-like mechanism for enhancing the system, but the direction is
> _always_ from the outside to the inside, and not the other way around.
> And that is what I mean with a root-cause analysis and solutions.
>
> So I'm all for a generic solution, but not for hard-wiring any
> component or any link that is specific to a certain component. That is
> definitely a code smell and beats the entire purpose of splitting the
> repositories in the first place.
> On Wed, Aug 22, 2018 at 11:13 AM Julien NICOLAS
> <[hidden email]> wrote:
>> Hi all,
>>
>> My opinion is to hide the link instead of delete it. I don't know if we
>> have other link in this case but it could be important to keep it in
>> source code. It could be convenient to have it for replacement by the
>> good solution
>>
>> But in the same time, we need to think about inter-webapp connection.
>> How a menu from webapp A could be extended by webapp B without putting
>> code in webapp A.
>>
>> It could be interesting to have a new tool bar in product to manage
>> ecommerce when ecommerce is installed. If we have this kind of feature,
>> it could work as well for OOTB webapp like product and stock, party and
>> order, etc.
>>
>> Julien.
>>
>>
>> Le 21/08/2018 à 10:10, Jacques Le Roux a écrit :
>>> OK, that your and Michael's opinions. So you prefer NPEs in code than
>>> hiding them when necessary?
>>>
>>> What others think?
>>>
>>> Jacques
>>>
>>>
>>> Le 21/08/2018 à 09:45, Taher Alkhateeb a écrit :
>>>> Again, hiding is not a solution and is correcting an error with another
>>>> error.
>>>>
>>>> -1
>>>>
>>>> On Tue, Aug 21, 2018, 10:37 AM Jacques Le Roux
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> See my answer in the Jira, we can't tolerate NPEs, they are already
>>>>> there
>>>>> for too long
>>>>>
>>>>> Being smart is cool, being smart and clean is better ;)
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 21/08/2018 à 08:57, Michael Brohl a écrit :
>>>>>> We should neither simply remove those links nor should we have
>>>>>> anything
>>>>> hard coded.
>>>>>> Let's look for a smarter solution. No need to hurry, better take some
>>>>> time to implement something sustainable.
>>>>>> Regards,
>>>>>>
>>>>>> Michael Brohl
>>>>>> ecomify GmbH
>>>>>> www.ecomify.de
>>>>>>
>>>>>>
>>>>>> Am 21.08.18 um 07:00 schrieb Jacques Le Roux:
>>>>>>> Of course, but I like to be able to get from the backend to the
>>>>> frontend when it's possible.
>>>>>>> I don't see any troubles keeping them once it's handled that way, but
>>>>> theoretical ones .
>>>>>>> Of course if the community prefers to remove them it's far easier and
>>>>> was what I wanted to do initially before having this idea of hiding
>>>>> links
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 21/08/2018 à 01:03, Taher Alkhateeb a écrit :
>>>>>>>> Simple, don't put any logic that points outwards from the framework.
>>>>> That
>>>>>>>> is sort of why we split repositories in the first place.
>>>>>>>>
>>>>>>>> On Mon, Aug 20, 2018, 8:00 PM Jacques Le Roux <
>>>>> [hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Le 20/08/2018 à 16:53, Taher Alkhateeb a écrit :
>>>>>>>>>> Makes sense. However, i note reading in the JIRA that "we can
>>>>>>>>>> simply
>>>>> hide
>>>>>>>>>> the button when the ecommerce component is not present". That
>>>>>>>>>> sounds
>>>>> like
>>>>>>>>>> logic that points outwards which is a bad design IMHO.
>>>>>>>>> I could not find a better way yet, I'm all ears for ideas.
>>>>>>>>>
>>>>>>>>>> Anyway, I think it is a reasonable step to take. +1
>>>>>>>>> I attached a patch for today at OFBIZ-9241
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>> On Mon, Aug 20, 2018, 5:31 PM Jacques Le Roux <
>>>>>>>>> [hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> The proposition is in the title.
>>>>>>>>>>>
>>>>>>>>>>> With the changes I'm introducing with OFBIZ-9241 there will few
>>>>>>>>>>> differences in UI (and presence of js files) between the
>>>>>>>>>>> framework
>>>>> only
>>>>>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>> framework+plugins
>>>>>>>>>>>
>>>>>>>>>>> I must add:
>>>>>>>>>>>
>>>>>>>>>>>       * since the old is often no longer supported and a
>>>>>>>>>>> release of
>>>>> it is
>>>>>>>>>>> always available (today R13) for users. I think removing the old
>>>>> demo is
>>>>>>>>>>> maybe
>>>>>>>>>>>         not a big deal.
>>>>>>>>>>>       * I found several cases where people, new to OFBiz,
>>>>>>>>>>> considered
>>>>> OFBiz
>>>>>>>>> as
>>>>>>>>>>> what we call the framework, and were considering the plugins as
>>>>>>>>> optional.
>>>>>>>>>>> What do you think?
>>>>>>>>>>>
>>>>>>>>>>> Jacques
>>>>>>>>>>>
>>>>>>>>>>>
>>>

[Nicolas Malin-2]

Hello

This thread about a "simple" problem highlights the difficulty for a
plugin to extend the framework on different elements. Since many years I
search different solution to how surcharge correctly the framework and
it was not easy :)

in line

On 22/08/2018 18:52, Taher Alkhateeb wrote:
> Hi Julien,
>
> Good ideas, and this is a good start to try and tackle the problem.
> Whatever we do, we must not keep "ghosts" or things that are waiting
> for specific outside plugins. The framework should _never_ know
> anything about the outside. This is a fundamental architectural
> concept in any layered software system.
Absolutely right, I knew a ghost history with addons that changed source
code base to load plugin's specificsinstead of understandingwhy we can't
surcharge the framework :)
> I'm ready to help if needed, and I think there are many ways to fix
> this problem. As you said one way is to extend webapps, another is
> perhaps to optionally include freemarker templates that match a
> certain pattern if they exist. In other words, you provide a generic
> plugin-like mechanism for enhancing the system, but the direction is
> _always_ from the outside to the inside, and not the other way around.
> And that is what I mean with a root-cause analysis and solutions.

Maybe I have two different solutions, based on theidea to usethemodel
pattern toload all plugin surcharge at the ofbiz start like services and
entities
* The first, load all screen engine modelsin memory at start, but I
fearthatit would be too expensive on memory (load unnecessary screens)
* The second, create an'extend model' who permit to surcharge all screen
engine model elements,andload it on ofbiz start and when we load a
model, we check on extend model if the element have surcharge to apply
just before settingit as immutable and put it in cache.

example :
<extend-form location='component://party/widget/PartyForms.xm'
name='ViewPartyGroup'>
<field name="partyId" >
<hyperlink description="Goto my plugin with : ${parameters.partyId}"
target="/myplugin/control/viewprofile" target-type="inter-app"
target-window="blank_">
<parameter param-name="partyId"/>
</hyperlink>
</field>
</extend-form>

With this, we would have a plugin that can surcharge a screen, a form, a
menu without changingnothing in the framework, identify clearly what
change has been made and a failure support when the extend can't be applied.

Currently I didn't found a solution to surcharge ftl.

If you feel that it's a good way to explore, I will start a new thread.

Nicolas
> So I'm all for a generic solution, but not for hard-wiring any
> component or any link that is specific to a certain component. That is
> definitely a code smell and beats the entire purpose of splitting the
> repositories in the first place. [...]

[James Yong-2]

Not sure why my 1st post didn't get through. So reposting again..


Hi all,

Good discussion so far.

I am in favour of having a proper solution from start rather than a stopgap.

Propose something similar to what Nicolas mentioned but making use of a fragment-type plugin framework like https://pf4j.org/.

The idea is for the fragment-type plugins to be located within framework or plugins, and loaded by a new OFBiz container.
For now, this fragment-type plugin helps to extend a particular UI Menu Item.
When fetching a menu for a page, OFBiz looks into the fragment-type plugins that are loaded and add any new menu items as required.

Regards,
James

PS: Regarding the thread topic, I prefer trunk demo for framework.


On 2018/08/23 09:19:02, Nicolas Malin <[hidden email]> wrote:

> Hello
>
> This thread about a "simple" problem highlights the difficulty for a
> plugin to extend the framework on different elements. Since many years I
> search different solution to how surcharge correctly the framework and
> it was not easy :)
>
> in line
>
> On 22/08/2018 18:52, Taher Alkhateeb wrote:
> > Hi Julien,
> >
> > Good ideas, and this is a good start to try and tackle the problem.
> > Whatever we do, we must not keep "ghosts" or things that are waiting
> > for specific outside plugins. The framework should _never_ know
> > anything about the outside. This is a fundamental architectural
> > concept in any layered software system.
> Absolutely right, I knew a ghost history with addons that changed source
> code base to load plugin's specificsinstead of understandingwhy we can't
> surcharge the framework :)
> > I'm ready to help if needed, and I think there are many ways to fix
> > this problem. As you said one way is to extend webapps, another is
> > perhaps to optionally include freemarker templates that match a
> > certain pattern if they exist. In other words, you provide a generic
> > plugin-like mechanism for enhancing the system, but the direction is
> > _always_ from the outside to the inside, and not the other way around.
> > And that is what I mean with a root-cause analysis and solutions.
>
> Maybe I have two different solutions, based on theidea to usethemodel
> pattern toload all plugin surcharge at the ofbiz start like services and
> entities
> * The first, load all screen engine modelsin memory at start, but I
> fearthatit would be too expensive on memory (load unnecessary screens)
> * The second, create an'extend model' who permit to surcharge all screen
> engine model elements,andload it on ofbiz start and when we load a
> model, we check on extend model if the element have surcharge to apply
> just before settingit as immutable and put it in cache.
>
> example :
> <extend-form location='component://party/widget/PartyForms.xm'
> name='ViewPartyGroup'>
> <field name="partyId" >
> <hyperlink description="Goto my plugin with : ${parameters.partyId}"
> target="/myplugin/control/viewprofile" target-type="inter-app"
> target-window="blank_">
> <parameter param-name="partyId"/>
> </hyperlink>
> </field>
> </extend-form>
>
> With this, we would have a plugin that can surcharge a screen, a form, a
> menu without changingnothing in the framework, identify clearly what
> change has been made and a failure support when the extend can't be applied.
>
> Currently I didn't found a solution to surcharge ftl.
>
> If you feel that it's a good way to explore, I will start a new thread.
>
> Nicolas
> > So I'm all for a generic solution, but not for hard-wiring any
> > component or any link that is specific to a certain component. That is
> > definitely a code smell and beats the entire purpose of splitting the
> > repositories in the first place. [...]
>
>

[Mathieu Lirzin]

Hello Nicolas,

Nicolas Malin <[hidden email]> writes:

> This thread about a "simple" problem highlights the difficulty for a
> plugin to extend the framework on different elements. Since many years
> I search different solution to how surcharge correctly the framework
> and it was not easy :)

This is indeed a desirable but hard problem to solve.

> Maybe I have two different solutions, based on theidea to usethemodel
> pattern toload all plugin surcharge at the ofbiz start like services
> and entities
> * The first, load all screen engine modelsin memory at start, but I
> fearthatit would be too expensive on memory (load unnecessary screens)
> * The second, create an'extend model' who permit to surcharge all
> screen engine model elements,andload it on ofbiz start and when we
> load a model, we check on extend model if the element have surcharge
> to apply just before settingit as immutable and put it in cache.
>
> example :
> <extend-form location='component://party/widget/PartyForms.xm'
> name='ViewPartyGroup'>
> <field name="partyId" >
> <hyperlink description="Goto my plugin with : ${parameters.partyId}"
> target="/myplugin/control/viewprofile" target-type="inter-app"
> target-window="blank_">
> <parameter param-name="partyId"/>
> </hyperlink>
> </field>
> </extend-form>

I find the “extend” term confusing in that case, because AIUI extending
is more about defining a new thing by inheriting from what is extended.
If I understand the semantics of your example correctly, it is more
about monkey patching [1]
‘component://party/widget/PartyForms.xml#ViewPartyGroup' than to create
an extended of version of it.  Is that a correct interpretation?

If my interpretation is correct, it is not clear what should happen when
multiple plugings modify/patch the same form?

> With this, we would have a plugin that can surcharge a screen, a form,
> a menu without changingnothing in the framework, identify clearly what
> change has been made and a failure support when the extend can't be
> applied.
>
> Currently I didn't found a solution to surcharge ftl.
>
> If you feel that it's a good way to explore, I will start a new thread.

I guess I have started the thread :-)

[1] https://en.wikipedia.org/wiki/Monkey_patch

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

[Nicolas Malin-2]

Hi,

On 23/08/2018 17:16, Mathieu Lirzin wrote:

> Hello Nicolas,
>
>> [...]
>> example :
>> <extend-form location='component://party/widget/PartyForms.xm'
>> name='ViewPartyGroup'>
>> <field name="partyId" >
>> <hyperlink description="Goto my plugin with : ${parameters.partyId}"
>> target="/myplugin/control/viewprofile" target-type="inter-app"
>> target-window="blank_">
>> <parameter param-name="partyId"/>
>> </hyperlink>
>> </field>
>> </extend-form>
> I find the “extend” term confusing in that case, because AIUI extending
> is more about defining a new thing by inheriting from what is extended.
> If I understand the semantics of your example correctly, it is more
> about monkey patching [1]
> ‘component://party/widget/PartyForms.xml#ViewPartyGroup' than to create
> an extended of version of it.  Is that a correct interpretation?

Not exactly how I imagine it. It's not the plugin who change the model
but more the ModelReader who would come and take modifications wanted by
plugins. I used 'extend model' term simply we already use a similar
system with <extend-entity> element to surcharge an entity from an other
component.
We can naming how we want, the most important part for me is record all
modifications wanted by plugins at the start without apply them.
> If my interpretation is correct, it is not clear what should happen when
> multiple plugings modify/patch the same form?
As it would be the ModelReader who load wanted modifications, if one (or
more) failed we can analyze why we can't apply it, generate information
in log for developer and protect the model creation to ensure rendering
all screens.

If a conflict appear between two plugins we can use different algorithm:
* FIWLC : First In Win Last Cry
* LIWFC : Last In Win First Cry
* NCNW : No Cooperation No Win
>> With this, we would have a plugin that can surcharge a screen, a form,
>> a menu without changingnothing in the framework, identify clearly what
>> change has been made and a failure support when the extend can't be
>> applied.
>>
>> Currently I didn't found a solution to surcharge ftl.
>>
>> If you feel that it's a good way to explore, I will start a new thread.
> I guess I have started the thread :-)
Indeed !
Cheers,
Nicolas
>
> [1] https://en.wikipedia.org/wiki/Monkey_patch
>

[Julien NICOLAS]

Hi Nicolas,

With your proposal, I'm afraid that we can't simply add a new menu in an
application from a plugin. Maybe it's another subject but it could be
interesting to manage it in the same times.

Technically I understand your proposal but it's difficult for me to
understand the impact ^^

Julien.


Le 23/08/2018 à 11:19, Nicolas Malin a écrit :

> Hello
>
> This thread about a "simple" problem highlights the difficulty for a
> plugin to extend the framework on different elements. Since many years
> I search different solution to how surcharge correctly the framework
> and it was not easy :)
>
> in line
>
> On 22/08/2018 18:52, Taher Alkhateeb wrote:
>> Hi Julien,
>>
>> Good ideas, and this is a good start to try and tackle the problem.
>> Whatever we do, we must not keep "ghosts" or things that are waiting
>> for specific outside plugins. The framework should _never_ know
>> anything about the outside. This is a fundamental architectural
>> concept in any layered software system.
> Absolutely right, I knew a ghost history with addons that changed
> source code base to load plugin's specificsinstead of understandingwhy
> we can't surcharge the framework :)
>> I'm ready to help if needed, and I think there are many ways to fix
>> this problem. As you said one way is to extend webapps, another is
>> perhaps to optionally include freemarker templates that match a
>> certain pattern if they exist. In other words, you provide a generic
>> plugin-like mechanism for enhancing the system, but the direction is
>> _always_ from the outside to the inside, and not the other way around.
>> And that is what I mean with a root-cause analysis and solutions.
>
> Maybe I have two different solutions, based on theidea to usethemodel
> pattern toload all plugin surcharge at the ofbiz start like services
> and entities
> * The first, load all screen engine modelsin memory at start, but I
> fearthatit would be too expensive on memory (load unnecessary screens)
> * The second, create an'extend model' who permit to surcharge all
> screen engine model elements,andload it on ofbiz start and when we
> load a model, we check on extend model if the element have surcharge
> to apply just before settingit as immutable and put it in cache.
>
> example :
> <extend-form location='component://party/widget/PartyForms.xm'
> name='ViewPartyGroup'>
> <field name="partyId" >
> <hyperlink description="Goto my plugin with : ${parameters.partyId}"
> target="/myplugin/control/viewprofile" target-type="inter-app"
> target-window="blank_">
> <parameter param-name="partyId"/>
> </hyperlink>
> </field>
> </extend-form>
>
> With this, we would have a plugin that can surcharge a screen, a form,
> a menu without changingnothing in the framework, identify clearly what
> change has been made and a failure support when the extend can't be
> applied.
>
> Currently I didn't found a solution to surcharge ftl.
>
> If you feel that it's a good way to explore, I will start a new thread.
>
> Nicolas
>> So I'm all for a generic solution, but not for hard-wiring any
>> component or any link that is specific to a certain component. That is
>> definitely a code smell and beats the entire purpose of splitting the
>> repositories in the first place. [...]
>
>

[taher]

I have just reviewed the links again, and the example provided by Jacques
is to access the ecommerce product page from the product component as a
menu item.

Honestly, I think for this example it should simply be deleted. It serves
no substantial value to me:

- I most likely will not use the standard ecommerce component
- I can easily view all the products directly from the ecommerce component.
There is no terrible need to access it from the product component.
- It does not even make sense to access the product page from the product
component. The purpose of the product component is to define and control
products, not view their ecommerce pages, heck you might have them on an
external system all together.

Furthermore, I'm not sure we need another superman initiative in the widget
system? The price to pay for this does not seem to be worth the added
value, I would hardly call it a value but maybe I'm wrong?

On Aug 24, 2018 9:55 AM, "Julien NICOLAS" <[hidden email]> wrote:

Hi Nicolas,

With your proposal, I'm afraid that we can't simply add a new menu in an
application from a plugin. Maybe it's another subject but it could be
interesting to manage it in the same times.

Technically I understand your proposal but it's difficult for me to
understand the impact ^^

Julien.



Le 23/08/2018 à 11:19, Nicolas Malin a écrit :

> Hello
>
> This thread about a "simple" problem highlights the difficulty for a
> plugin to extend the framework on different elements. Since many years
> I search different solution to how surcharge correctly the framework
> and it was not easy :)
>
> in line
>
> On 22/08/2018 18:52, Taher Alkhateeb wrote:
>> Hi Julien,
>>
>> Good ideas, and this is a good start to try and tackle the problem.
>> Whatever we do, we must not keep "ghosts" or things that are waiting
>> for specific outside plugins. The framework should _never_ know
>> anything about the outside. This is a fundamental architectural
>> concept in any layered software system.
> Absolutely right, I knew a ghost history with addons that changed
> source code base to load plugin's specificsinstead of understandingwhy
> we can't surcharge the framework :)
>> I'm ready to help if needed, and I think there are many ways to fix
>> this problem. As you said one way is to extend webapps, another is
>> perhaps to optionally include freemarker templates that match a
>> certain pattern if they exist. In other words, you provide a generic
>> plugin-like mechanism for enhancing the system, but the direction is
>> _always_ from the outside to the inside, and not the other way around.
>> And that is what I mean with a root-cause analysis and solutions.
>
> Maybe I have two different solutions, based on theidea to usethemodel
> pattern toload all plugin surcharge at the ofbiz start like services
> and entities
> * The first, load all screen engine modelsin memory at start, but I
> fearthatit would be too expensive on memory (load unnecessary screens)

> * The second, create an'extend model' who permit to surcharge all
> screen engine model elements,andload it on ofbiz start and when we
> load a model, we check on extend model if the element have surcharge
> to apply just before settingit as immutable and put it in cache.

>
> example :
> <extend-form location='component://party/widget/PartyForms.xm'
> name='ViewPartyGroup'>
> <field name="partyId" >
> <hyperlink description="Goto my plugin with : ${parameters.partyId}"
> target="/myplugin/control/viewprofile" target-type="inter-app"
> target-window="blank_">
> <parameter param-name="partyId"/>
> </hyperlink>
> </field>
> </extend-form>
>
> With this, we would have a plugin that can surcharge a screen, a form,
> a menu without changingnothing in the framework, identify clearly what
> change has been made and a failure support when the extend can't be
> applied.
>
> Currently I didn't found a solution to surcharge ftl.
>
> If you feel that it's a good way to explore, I will start a new thread.
>
> Nicolas
>> So I'm all for a generic solution, but not for hard-wiring any
>> component or any link that is specific to a certain component. That is
>> definitely a code smell and beats the entire purpose of splitting the
>> repositories in the first place. [...]
>
>

[Nicolas Malin-2]

On 24/08/2018 09:16, Taher Alkhateeb wrote:
> Furthermore, I'm not sure we need another superman initiative in the widget
> system? The price to pay for this does not seem to be worth the added
> value, I would hardly call it a value but maybe I'm wrong?
I'm the feeling that it's not a mountain (less that common-theme :) ). I
will sharing in face to face tomorrow if we have at Néréide a benefit
for an improvement like that and if we are ready consume some time to
create a POC to trail it.

Nicolas

[Nicolas Malin-2]

I forgot to reply :), after sharing with my coworkers, It's would b
interesting for us to works on this parts.

So I will start a POC just to see if we go on a good way.

Nicolas


On 25/08/2018 13:35, Nicolas Malin wrote:

> On 24/08/2018 09:16, Taher Alkhateeb wrote:
>> Furthermore, I'm not sure we need another superman initiative in the
>> widget
>> system? The price to pay for this does not seem to be worth the added
>> value, I would hardly call it a value but maybe I'm wrong?
> I'm the feeling that it's not a mountain (less that common-theme :) ).
> I will sharing in face to face tomorrow if we have at Néréide a
> benefit for an improvement like that and if we are ready consume some
> time to create a POC to trail it.
>
> Nicolas
>