× This forum has been locked. Please submit new Feature Requests on GitHub: github.com/Jensen-Technologies/component-creator-issues/issues

Plugin Triggers JOLLY GOOD SO VOTE IT!

Plugin Triggers JOLLY GOOD SO VOTE IT!

4 years 10 months ago - 4 years 10 months ago #1139 by Steven Pignataro

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! 

The following user(s) said Thank You: Andres Maeso, Walt Sorensen

Please Log in or Create an account to join the conversation.

4 years 10 months ago #1141 by Walt Sorensen

+1

Please Log in or Create an account to join the conversation.

4 years 10 months ago #1142 by Randy Carey

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).

The following user(s) said Thank You: Andres Maeso

Please Log in or Create an account to join the conversation.

4 years 10 months ago #1144 by Søren Beck Jensen

Thank you for your suggestions. I think Randy is right, that there are two philosophies on what Component Creator should be. It definitely started as a way to generate the "boring" code and then for you to take over, but the sentiment raised by Steven we see more and more. You want to be able to go back and edit your component, and not loose any custom coding you have done.

We are monitoring the discussions and are also talking in the team about how to approach this, the best way. 


Søren Beck Jensen
Founder, Component-Creator.com

Please Log in or Create an account to join the conversation.

4 years 8 months ago #1198 by Steven Voorhees

+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.

The following user(s) said Thank You: Andres Maeso

Please Log in or Create an account to join the conversation.

Time to create page: 0.142 seconds
Powered by Kunena Forum

We use cookies so that you can place orders and we can provide a better service. You can control the use of cookies at the individual browser level. If you reject cookies, you may still use our website, but your ability to use some features or areas of our website may be limited.