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