Plugin Triggers JOLLY GOOD SO VOTE IT!

Anyone that has worked on a complex component knows that it has to go much further than just grid views and such. There are certain times when you need to do a little (or big) custom job outside the box. With component creator it is VERY difficult to do this if you want to keep being able to build out your component... you will find that you are continually having to "hack" the build output and this becomes extremely frustrating and in the end you will likely spend much time "hacking" the component build again and again and again.

There is a simple solution to this, but one that the developers of component creator will need to implement. The solution being to implement the observer pattern to component creator so that plugins can be used to customise the build without losing the ability to modify your build online. The implementation is extremely trivial, the biggest part would be planning on where to add the triggers and naming conventions.

docs.joomla.org/Plugin_Developer_Overview

Consider a model, say you want to customise the query to implement something like acl, etc - it would be simple matter of adding a small amount of code to the model getListQuery() method a simple matter of this:


// Add the list ordering clause.
$orderCol  = $this->state->get('list.ordering');
$orderDirn = $this->state->get('list.direction');
if ($orderCol && $orderDirn){
$query->order($db->escape($orderCol . ' ' . $orderDirn));
}
//
//

JPluginHelper::importPlugin('ComponentBuilder');
$app = JFactory::getApplication();
$query = $app->triggerEvent('onMyMOdelGetListQuery', array($context));

return $query;

And there you go, you can now alter the model query without touching the component build "core".

By strategically placing these triggers throughout the component build, Component Builder would be bought to a new level.

Such a system is of such importance to our company that we will likely implement our own component builder if it is not feasible for the developers of Component Builder to do such a thing. We would not like to compete with CB, but if we did such a thing it would be made available to the community.

Thank you for your time! 

+1

I approach Component Creator from a different perspective.  I use it to generate the base component, with the MVCs, fields, and filters that I want.  Then I develop directly on the component from there - never overwriting my component with a newly generated base.  Adding fields to a CC generated component is easy (thanks to JForm), and adding or changing filters is also easy.  If I need a new view, I regenerate from CC but selectively port over the extra MVC files and directories.  So once I take ownership of the code, if I want to do something such as modify the query, I make that change in the model.  I'm the component's developer, so I don't have to be hands-off on the code as I would on a third-party component.  

I guess there are two approaches as to how we handle CC-generated components.  Some want to use them with no direct customization so that they can simply replace a component with the latest that CC generates.  Others (the camp to which I belong) use it as a starting point for building custom components, and take ownership of the code for the model, controller, and everything else.  Each camp behind these two approaches will value proposed features differently.  From my approach, I seldom need triggers, and if I do, I would know which triggers and where to insert them (perhaps better than CC could suggest).

+1

Having been a Joomla! user/web designer since it's early days (2005), I haven't ventured into designing component until recently. My initial vision was that CC would allow me to create my component, add some code functions, such as plugin triggers, fieldsets, etc, then work on the layouts. If I needed to make a modification, I would come back to the component in CC, make the changes, then create a new build.

I find CC a good step forward, but I do agree with Steven that there is so much more that CC could do.