Hi,
How about event triggers instead of fork system.I just read through the FOF and it has builtin support for trigger events.

This will help to keep the cook generated code as it is and implement the extra functionality through plugins.

Regards
Vivek

In the works already.

Forks will always be usefull, but as you say, handled much better.

Hi Both (@vivek & @admin),

Despite having developed numerous custom plugins for Akeeba Subscriptions using FoF, I must admit, I was blissfully unaware of the true power of it until today! Sure, I was damn impressed by the quality of the plugin API however, I'd attributed it completely to Akeeba Subs and at that point, I had only really used 1% of FoF's capabilities. Since its integration into Joomla 3.2 and the announcement of it's inclusion on the J-Cook Roadmap, I'd been dying to read the complete docs but for various reasons, I haven't had time. Today, I finally did it!

FoF = AWESOME!
J-Cook = AWESOME!
FoF + J-Cook = AWESOME!!¹⁰⁰

Anyways, back to the thread...

@vivek
As you said/implied, the core joomla 'content' events such as onContentAfterSave() are readily implemented for you when FoF is enabled which I think is very slick! However, FoF's plugin 'hooks' are slightly different in purpose & implementation to that in Cook. They are intended to expose your extension to the wider system events to enable plugins to manipulate the output of your extension dynamically (Observer/Observable paradigm). Plugin events are decoupled in the sense that the 'calling' extension is never aware of the plugins that will manipulate its output (return to the subject), nor are the plugins really aware of the extensions calling them.

In Cook on the other hand, forks work 1:1. It is intended to provide a mechanism to further develop iterations of your 'Cooked' components without losing prior, forked modifications. Once a component is production ready, you'd most likely want to merge all forked files/methods etc. into their 'core' counterparts before removing calls to check/call them. This is a 'single' overridden instance of an object, class, form or whatever provided by the cook fork system.

Have you read the FoF Developers Guide?
Assuming that your goal is to specifically go the FoF route to 'open up' your extensions via a plugin mechanism, you could take a look at how to 'enable' FoF in your component... It'll be a lot faster to work out how to do it manually for one extension than it will for poor @admin who'll have to get his head around doing it all automatically us. Plus, It doesn't look difficult at all in terms of adapting an existing component - all in the docs. Alternatively, if you're not specifically interested in FoF and your primary goal is to create some 'listeners' for your component to trigger, the Joomla Docs on the subject are in a moderately healthy state.

To conclude: IMHO I don't think that it's really a question ofI mean,whilst their functionality may at first appear similar to an extent, the purpose they each serve is quite different. Both are excellent at what they do. FoF's event triggers (or Joomla native ones for that matter) are a mechanism to provide 3rd party integrations with your extensions whilst J-Cook forking is a development tool.

Anyway, that's just my 2 pennies-worth! I think its all up for debate...

Please share your experience of it, whichever path you take... We'd love to hear how you went about it and how it turned out.

hope there's something useful in there!

Gez

Exactly, the triggers used in FoF are more powerfull because they can be used inside the component.
FoF doc is loooong... maybe you are eve consacrating more time than me... I have so many things to fix before to goes on (because I want Cook beeing perfect in its last version before FoF) This point is loooong ! You cannot imagine, because I must check all very precisly and change thestandard of coding in a nice migration.
I have explained this already... anyway.


When I saw FoF for the first time, I contacted Nicholas dionysopoulos to congratulate his great job.
I was deadly discouraged because actually the component are really reduced to ashes, and so a little bit feeling all my work useless.
But when I discovered the numerous quantity of parameters, I realized that a generator is necessary !!!
So I need to implement all this sh...t .Lol, with respect, but it is a lot of work more !!!

I am very excited about all the new explosive features coming and no need to debug them !!!! This is the most cool stuff.
Then Cook will keep its usefull layers when necessary.

About JDom, we can open a debate as well.
For my part, it is obviously a framework to keep because there is no other such usefull HTML abstraction in Joomla, but I recognize it can be slow rendering for long lists. Also with the use of XML forms everything gets simplier.
But what happen when you want to customize a template and explode the forms in parts, or manipulate the controls in a really free way ? To show the filters differently ? To recieve special datas such as a complete Google Map or other controls ...
JDom is really good to develop fast raw templates, modules, etc....
To my point of view, I never had doubts, but your review are welcome.

Hi @admin,admin wrote: This is all EXCITING STUFF!!! Can't wait! I'm really interested to see how straight-forward making a cook generated component FoF enabled really is since from the docs, it all looks very straightforward.admin wrote: JDOM ROCKS! To be fair, what developer doesn't want his own stash house of HTML inputs, and sub layouts I'm also keen to see what can be achieved with making the JDom library run FoF with regards to filtering, loading/overriding model states etc...