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