Re: [PROPOSITION] Extend the screen engine via plugins

[Mathieu Lirzin <ma...@nereide.fr>]

Hello Nicolas,

Nicolas Malin <ni...@nereide.fr> 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

Re: [PROPOSITION] Extend the screen engine via plugins

[Nicolas Malin <ni...@nereide.fr>]

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
>