RFC: Plugin naming rationalisation

[Andrew Eddie]

Louis and I have been working over the comments branch and looking at
how plugins interact with forms and data and things, and in that
process we feel it's time to rationalise most of the key events that
will form part of 1.6 (and leave some alone that aren't perfect but
aren't particularly broken).

As we all know plugins are loaded by group and this will not change.
What we are proposing, however, is to namespace the events and this
was discussed at the developer summit last year (at my place). The
namespaces are:

Config - reserved for a future purpose
Content - dealing with content CRUD
Extension - used by the installation process
User - anything to do with users

Following this methodology, and event affecting a user would prefix
with "onUser*" even though it might reside in it's own folder
(authentication or user, etc). All content events would prefix with
"onContent" and so on.

So let's go through a few examples.

USER
======

In the User namespace we would rename the following events:

onAuthenticate -> onUserAuthenticate
onAfterDeleteUser -> onUserAfterDelete
onAfterStoreUser -> onUserAfterDelete
onAfterStoreUsergroup -> onUserAfterSaveGroup
onBeforeDeleteUser -> onUserBeforeDelete
onBeforeStoreUser -> onUserBeforeSave
onLoginFailure -> onUserLoginFailure
onLoginUser -> onUserLogin
onLogoutFailure -> onUserLogoutFailure
onLogoutUser -> onUserLogout

In addition, there are some new events that will be introduced:

onUserAfterDeleteGroup
onUserBeforeDeleteGroup
onUserBeforeSaveGroup

EXTENSION
===========

In the Extension namespace we have all new events and we'd rename these to be:

onExtensionBeforeInstall
onExtensionAfterInstall
onExtensionBeforeUpdate
onExtensionAfterUpdate
onExtensionBeforeUninstall
onExtensionAfterUninstall

CONTENT
=========

In the Content namespace, we would rename the following events:

onAfterContentSave -> onContentAfterSave
onAfterDisplayContent -> onContentAfterDisplay
onAfterDisplayTitle -> onContentAfterTitle
onBeforeContentSave -> onContentBeforeSave
onBeforeDisplayContent -> onContentBeforeDisplay
onPrepareContent -> onContentPrepare

Now, one of the problems we have is that the existing plugins assume
you are dealing with an article only, and this is really not going to
be flexible enough to deal with all the new toys in 1.6 (including
some of the events I will mention soon). With the above-mentioned
content plugins we are going to need to add a context argument so that
the plugin knows what kind of content it will be dealing with. For
example, the onAfterContentSave is declared as:

// 1.5 format
function onAfterContentSave(&$article, $isNew)

we would change this to:

// 1.6 format
function onContentAfterSave($context, $data, $isNew)

in practice this would become:

$dispatcher->trigger('onContentAfterSave', 'com_banners.banner',
$banner, $isNew)
$dispatcher->trigger('onContentAfterSave', 'com_banners.client',
$client, $isNew)
$dispatcher->trigger('onContentAfterSave', 'com_content.article',
$article, $isNew)
$dispatcher->trigger('onContentAfterSave', 'com_weblink.weblink',
$weblink, $isNew)

In this way we can consistently intercept all content and the plugin
can pick and choose what it wants to work on.

With the new JForm API we can introduce the following generic events:

onContentPrepareForm

This is an event that allows a plugin to add additional XML data to
the form. This could be user profile fields, custom fields in an
article, etc.

onContentPrepareFormData

This is an event that compliments onPrepareForm but for the data. If
you have extra fields injected in a form, this method injects the
extra data that was saved if it has come from a custom source (note,
you don't need this if you are extending params fields as this is
handled just with onPrepareForm).

onContentPrepareCustomData

This is an event that collects custom data when displaying an object
(as opposed to using a form). This would allow you to display custom
user profile information, custom fields in an article, etc.

onContentBeforeDelete
onContentAfterDelete

A pair of events to trap the when content gets deleted.
onContentBeforeDelete can potentially stop some content from being
deleted.

onContentChangeState

This event would be fired, for example, when you publish or unpublish
a list of articles or other content.

Each of these events will include some sort of context to help the
plugin work out what kind of data it is working with.

---

We won't be touching the search or editor plugins for now - let the
sleeping dogs lie. The other system events (onAfterRoute, etc) will
also remain unchanged.

What are the implications?

Well, we are between a rock and a hard place. We could keep the
current names, but have to include a new event name for each type of
content (eg, onNewsfeedAfterSave, onBannerClientBeforeDelete) and that
could get onerous. We could keep the current names but risk existing
plugins breaking a site because we passed a weblink object to it and
it though it was an article. We could have a split
old-naming-convention and new-naming-convention. We could rationalise
and be consistent across the board providing maximum flexibility but
requiring developers to upgrade their plugin events.

In the end, we feel rationalisation is the best approach, and given
that plugin developers MUST change their XML install files anyway,
it's not an onerous task to map old names to new names. During this
process we will of course document the events (finally) so that you
can reference what they are supposed to do.

We are under a bit of time pressure so I would appreciate feedback on
this as quickly as possible. Jump into the #joomla-dev IRC if you see
Louis or I there to chat about it if you want. Also, if you want
additional triggers SPEAK NOW otherwise you will miss the boat for
their inclusion in 1.6 (and being prepared to code a patch would be
appreciated).

Thanks for your due consideration of this matter. Unfortunately there
is no easy road to take regarding the plugins, it's a matter of
choosing where we want to compromise.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Peter van Westen]

Something missing in Joomla and would be a great benifit:
A set of triggers for modules. So you can trigger plugins to have
effect on the module list and module outputs.
Take a look at the (overruling) module helper file in MetaMod (Pro)
and Advanced Module Manager...

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

[Hannes Papenberg]

Hi Andrew,
I like that approach. Even though from a project standpoint I'd say to
not start yet another refactoring, I actually think that it is essential
to add this now. Am I correct in assuming that all plugins will get a
$context variable? I even think it would be good to have this in search
and system plugins. For example in system plugins you could then
distinguish between administrator and site application or an XML-RPC
app. And for the search plugins it would implement the selection of
search areas easily. Regarding that and maybe the system plugins also,
it might be of interest to allow both a string and an array for the
context...

Hannes

[Andrew Eddie]

Actually, just thinking we could refactor the search plugins into:

onContentSearch
onContentSearchAreas

and indeed pass them a context. I like that.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrew Eddie]

Hi Peter.

Wanted you to comment on modules so glad you are here. Could you have
a look at exactly where you need a trigger to make your life easier.
I suspect it's something like a way to post-process the list of
modules the system pulls before we hand it off.

Regards,
Andrew Eddie

http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Andrea Tarr]

Would those new form plugins allow you to make changes to existing
fields in the xml?

For instance, for accessibility reasons, I need to strip out any
"onchange" events. Right now I'm forced to do it with a preg replace
in the template override.

Another example is the "hidden" labels when I need to display a label.

The new forms take away from the ability of designers to override the
output. If this is out of scope for 1.6 then it should be considered
for 1.7.

The last thing I want to do is suggest anything that would delay 1.6.

Andy


Andrea Tarr

Sent from mobile

[Andrew Eddie]

Hi Andy.

No, we can't change the HTML output just the form definition. We can
probably apply some pain relief in other ways though.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Kevin M]

Hey Joomla Team,

I have been haunting this list for quite some time with interest and open
eyes watching this amazing development. First I want to give a big hand to
everyone for their contribution, time and resolve bringing all this to life!

I have a request that has been a real pain for me working with Joomla!
sites. I don't know the trouble it would be to implement but I would like to
see the file system be able to put articles and other elements in
alphabetical order, or give me the control to organize them the way I work.
When you get a site that is very large and you have multiple categories.
Even with the filter system it is still a nightmare to find that one article
you need to work with. I have to keep a separate list so that I can find the
items I am looking for. It does not help that they are in order as last
wrote is on top or on bottom. Unless there is a parameter I have overlooked
that gives me the ability to do this?

Again thanks goes out to all the great people that have helped make Joomla!
such an awesome CMS.

Kevin M.

[Andrea Tarr at Tarr Consulting]

Have you tried clicking on Title to sort by Title in the Article Manager?

Andrea Tarr
www.tarrconsulting.com

[Hannes Papenberg]

I'm not really sure what you mean, but there are parameters to order the
frontend output by title, name, order that they were created in and both
forward and backwards. in the backend you can simply sort the lists by
clicking on the heading of the table for example by title, authorname,
access level, ordering...

Hannes

[Kevin M]

Andrea,

Well I never knew that was there;) Thanks for getting it implemented so
fast..;)

Kevin M.

--------------------------------------------------
From: "Andrea Tarr at Tarr Consulting" <at...@tarrconsulting.com>
Sent: Thursday, April 29, 2010 8:16 AM
To: <joomla-...@googlegroups.com>
Subject: RE: File organization

[Andrea Tarr at Tarr Consulting]

I aim to please ;)

[Karlos Rikáryo]

Well friend I was thinking with this thread ... Today this form of
organization gives just a click on the top of the article category ... only
to make a sequel now the Joomla! 1.5 has two forms, click the arrow at the
front of the article and the other way is to type the number of the desired
sequence, has the same features in the control of the homepage, I was
thinking! it would be interesting to think about a click and drag to
facilitate the order of modules and articles? would be easier and simpler,
even keeping the other options! Mostly on the front page today has not
evolved much in Joomla! 1.5 believe that lack even a publish and unpublish
the articles within the organization's home page at administrator Joomla!,
Functionality that is only available within the category. I think these
features are designed to be implemented and who knows the root of the new
version of Joomla! 1.6?

hugs

Rikaryo
Joomla!Brasil
www.rikaryo.com.br
@rikaryo

--------------------------------------------------
From: "Kevin M" <eart...@tejungle.com>
Sent: Thursday, April 29, 2010 1:03 PM

To: <joomla-...@googlegroups.com>
Subject: Re: File organization

[Amy Stephen]

Andrew -

Good topic - I think this is going to be part of that common content
data model and the road to 2.0.

In the work I am doing, I created a couple of new renderers and moved
away from components/modules. I have a few controllers - a composite
(page) controller, a position controller, and an events controller.

I use the term portlets, instead of components/modules and all output
follows the same processing flow, whether it's a blog post or a web
link or an image or an appointment.

The page controller walks thru the JDoc statements, extracting
positions, the position controller drives the production of all
portlets for that page, and the Events controller processes portlets
invoked within content, like comments. Threaded comments are created
by the comment portlet firing off subordinate comments, and so on.
But, all portlets follow the same set of processing - thru the use of
events.

Views are shared between content - a list is a list whether it's a
list of blog post or web links or a menu - it's still a list. This
way, we can begin using Design Layout Patterns that are starting to
emerge. (ex. http://quince.infragistics.com/#/Search$tag=Browse )

Each view has five parts - and an event can fire before/after each
file is processed:

collection-header
item-header
item-body
item-footer
collection-footer

The item-header/body/footer happen once for each item, whereas the
collection header/footer happen once for the view. Same 5-part pattern
for the overall position.

It doesn't matter if it's a form or a plain old post, it's output, and
it doesn't matter what type of content it is, it's just data, by
treating everything the same and using parameters to turn on or off
processing, the logic is simplified and all content shares standard
events.

The result is you can tweet a video or a post or an image, or ping
these items, or email notify, or archive changes, or check ACL, it
doesn't matter, it's just content, and all content is looked at a
certain way.

I think with questions like you are raising about standardizing
events, you are heading towards the same discussion and I hope it goes
much further than event names into a great deal of simplification
across the entire application. To me, this is 2.0 stuff and I am
really eager to get there. For now, I think finding a place to get out
the good stuff available without too many additional changes might be
best.

You might have seen this discussion on twitter this week
http://engineeredweb.com/blog/10/4/its-time-nomvc - and I agree with
Matt Butcher's comments, which get into what Peter is talking about
with modules and Fotis has said about using the MVC for Plugins in
Modules. The truth is, our implementation of the MVC can be much
better, much simplier, and much more powerful.

Nooku has a lot of code savings, but it doesn't address these changes
either.

Both core and nooku controllers and file structure are too focused on
the component. Resetting that perspective for producing the page, the
position, the little square of output, starts to shake out a really
nimble architecture.

I've watched a number of times as you start discussions into these
areas that I know, if you keep pulling that string, Andrew, you'll
collapse this MVC into a the very lean structure it should be. But
it's going to be a lot of work to sort it out once you start doing
that, and it goes beyond 1.6 and takes you to 2.0.

Sorry to never answer your question nicely. :P

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

[Louis Landry]

Amy,

While what you are doing is interesting it isn't really commenting on the proposed changes or suggesting realistic alternatives... next time maybe a new thread?

- Louis

--
Development Coordinator
Joomla! ... because open source matters.
http://www.joomla.org

[elin]

Andrew,

A question about the context issue. We've been through this whole big
thing of adding content plugins to other components (and as you said
to things like category text). Which leads to the question of whether
there are plugins that should only run in a specific context and some
content plugins that run everywhere? Emailcloak is a good example of
run everywhere off the top of my head. Do we separate those out or
make component specific ones even if they are essentially the same?
I'm thinking for example about contact where you might want the
possibility of content plugin in text like in an article (common) and
also component specific things like those around submitting the
contact form.

Elin

> >http://engineeredweb.com/blog/10/4/its-time-nomvc- and I agree with

> ...
>
> read more »

[Andrew Eddie]

Hi Elin.

In the case of most test modifying plugins, like Emailcloak, they
would effectively ignore the context and just operate on the data
provide. Those onPrepareContent plugins require a 'text' property to
work on. It's still worth adding the context just in case you have a
plugin that can only operate on a particular data type, eg, a K2 or
Zoo article for example.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Christophe Demko]

I suggest a onContentQuery trigger. I create this one in the
languageswitcher branch to add additional filters on list query.

onContentQuery($name, &$query)

$query is an object of class JDatabaseQuery and $name is the context.

Ch.D

On 30 avr, 07:22, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Elin.
>
> In the case of most test modifying plugins, like Emailcloak, they
> would effectively ignore the context and just operate on the data
> provide.  Those onPrepareContent plugins require a 'text' property to
> work on.  It's still worth adding the context just in case you have a
> plugin that can only operate on a particular data type, eg, a K2 or
> Zoo article for example.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

> >> >http://engineeredweb.com/blog/10/4/its-time-nomvc-and I agree with

> ...
>
> plus de détails »

[Amy Stephen]

More clearly put - no more features. Just get 1.6 out.

When we get to the next phase, I hope we come up with fewer events,
standardized for all content. If that comes to be, then this time will
not only be wasted, but we will have to remove events from developers
who would have used them in extensions.

No reason for a new thread, no reason for an interesting discussion, I
only wanted to provide context that might help you understand my
response, rather than possibly sound like a whiner or naysayer.

On Apr 29, 3:43 pm, Louis Landry <louis.lan...@joomla.org> wrote:
> Amy,
>
> While what you are doing is interesting it isn't really commenting on the
> proposed changes or suggesting realistic alternatives... next time maybe a
> new thread?
>
> - Louis
>

> >http://engineeredweb.com/blog/10/4/its-time-nomvc- and I agree with

> ...
>
> read more »

[Andrew Eddie]

Hi Christophe.

A query trigger would put enormous load on the system. I would not
support that.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Shyam Verma]

Hi Andrew,

Yes, A query trigger for public is bad. But what if some are ready for those performance hits.
So my suggestion would be add those trigger under the flags, so one who want to these, just need to enable few flags. Rather then hacking into the core code.

Thanks
Shyam

On Fri, Apr 30, 2010 at 4:39 PM, Andrew Eddie <mamb...@gmail.com> wrote:

support that.

[Andrew Eddie]

Hi Shyam

You will have to give me a use-case example. I don't understand what you mean.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Shyam Verma]

@Andrew :

I just want to tell that few triggers which can be disabled for public (as they are under some if and else), as they do not create value for general plugins. But such events can be very interesting for developers and these can be enabled by advance-user. Rather then hacking into the core code.

This was my suggestion only as I checked the request from Christophe was aborted just due to Performance.
Personally, I never had any requirement for such a event.

Thanks
Shyam

On Fri, Apr 30, 2010 at 5:19 PM, Andrew Eddie <mamb...@gmail.com> wrote:

You will have to give me a use-case example.  I don't understand what you mean.

[Hannes Papenberg]

This is not something that we will implement. Its not because we don't
want to, but because the developer that needs this, has to do this
himself. We generally can't add this to core Joomla queries, but if you
need this in an extension of yours, feel free to create a trigger where
you add this. In the end however, it is much more likely that just
running another query in your extension to get the additional
information is faster than modifying an existing query with such a plugin.

Hannes

[Stephen]

Just to concur with Peter:

Peter and I worked together on some changes to the Module Helper class
in 1.5.x, because we both have products/plugins that override the
helper with quite similar functionality. We have users who use both of
our products at the same time, so our 2 different implementations
ended up conflicting. As a result of this, we came up with a flexible,
shared replacement for the Module Helper class that works for us both.

We wrote this with an eye to getting it put into Joomla, so we don't
have to override the class (something neither of us like doing, but
were forced to because of lack of hooks into this part of the code).

Essentially, we inserted 5 new triggers:

1 - a trigger within renderModule() called onRenderModule, which is
passed a reference to the module to be rendered. onRenderModule is
allowed to alter the content of the module. It can also return a
boolean, and if that boolean is true, then the module is not rendered
at all (no chrome, no title, no content). This allows plugins to
switch off modules at the point of rendering, for example if the
contents evaluate to an empty string. The only down-side of using this
in this way is that countModules() will still count the module, and
templates are liable to reserve space if the empty module is the only
module in the position. On the other hand, it's still a great help.

2 - a trigger in &_load() called onCreateModuleQuery. This is passed
an array of strings which will get used for the main query to get the
list of modules for display, and has the opportunity to manipulate
these.
Peter's Advanced Module Manager uses this to join and query a separate
table holding extra information about the modules.

3, 4, 5 - further triggers near the end of &_load() which allow
components to further manipulate the list of modules, and/or any of
the parameters of the individual modules. There are 3 of these which
may seem like overkill, but it means that we can make decisions within
the plugins as to what order the plugins will be executed, rather than
burdening the user with the task of ordering the plugins in the right
order.

onPrepareModuleList
onAlterModuleList
onPostProcessModuleList

Each plugin is passed a reference to the array of modules. Following
the last plugin, the list of modules is consolidated by removing any
modules who have had their "published" parameter set to "false". This
allows the plugins to unpublish modules if they want to, during any
stage of the process.

If I can speak for Peter, I would say that we would both be delighted
if these triggers and the slightly edited surrounding code were
considered for immediate inclusion into 1.6. It's shipping code in 2
products, and seems both stable and efficient. I think that if it
becomes part of the official release, it should open up many more
possibilities for useful 3rd-party components/plugins that manipulate
modules. Yes - competition for both Peter and I, but great for the
community.


Ok, so what can we do to help to get this into 1.6? I haven't looked
at this part of 1.6 recently, so I don't know how different the module
helper class is compared to 1.5.

Can anyone speak for the 1.6 maintainers regarding whether you're
willing to consider this additional functionality? We're all busy, so
would like some confirmation of interest before spending time on it.

Best regards,
Stephen Brandon
metamodpro.com

> > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer

[Sam Moffatt]

I'll be making the onExtension change at some point today to alter
those module trigger names.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Andrew Eddie]

Hi Stephen

I'm happy to look at including your #2 for onCreateModuleQuery. Get
me a patch pronto to review.

I think lets work on #1 for 1.7. The others I'm still not convinced about.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Peter van Westen]

Hi Andrew,

Sorry for not replying earlier. But I am glad Stephen jumped in.

Just to explain a bit more: The triggers we came up with are based on
what we are trying to do (our extensions cover quite a bit of ground
together when it comes to module 'manipulation').
The first trigger is only useful for altering the content of the
actual module. Which is nice for certain content modules that now only
have effect on the articles (and such).

But it is not enough for extensions that want to control the actual
placement and even positioning of modules (advanced assignments).

So just to say it bluntly, if these other triggers are not added to
the core, extensions like mine and Stephen's will have to keep
overruling the core functionality with a helper override (= not
ideal).

Peter

On 4 May, 04:49, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Stephen
>
> I'm happy to look at including your #2 for onCreateModuleQuery.  Get
> me a patch pronto to review.
>
> I think lets work on #1 for 1.7.  The others I'm still not convinced about.
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

> ...
>
> read more »

[Andrew Eddie]

Thanks Peter.

I guess my concern is I don't feel it's the core's job to build in
failsafe's for your customers getting the ordering of two competing
extensions wrong (I do however empathise with your suffering, please
don't get me wrong). I think we need to find a bit of a compromise
but you guys need to help me (and quickly) find the appropriate places
to put the plugins.

So here's what I can buy into and also allow for a new group of
plugins called "modules" if you want.

onContentPrepareModuleQuery

Passes the JDatabaseQuery object to the plugin and you can manipulate
it however you want.

onContentPrepareModuleList

Passes the final module list to the plugin and you manipulate the list.

onContentRenderModule

Passes each module to the plugin and you can manipulate the output.

Does that sound fair? Try and catch me on IRC if you want to discuss
this further and I'll try to give you as much assistance as possible
but we'll need to have whatever "it" is battle-ready within the next
24 hours.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Peter van Westen]

Hello Andrew,

I understand what you are saying and agree.
The plugin order problem goes beyond modules and needs to be thought about on a higher level.
Something for another discussion, but I am thinking in the direction of subgroups. So SEF extensions can be placed in the last subgroup of the system plugins for example... That would fix a large part of the problems.

Anyway, I would say, go for what you suggested.

I do not use IRC, is there a web room?
I am on skype: petervanwesten or MSN: pe...@nonumber.nl

Peter

[Andrew Eddie]

Just going through the plugin change-over at the moment.

It strikes me as appropriate to have:

onExtensionBeforeSave
onExtensionAfterSave

as events to happen when saving modules, plugins, languages, and
templates. Currently it's using onContent* which is "ok" but probably
not quite contextually correct.

Last minute thoughts?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Artyom Bisyarin]

On Tue, 04 May 2010 15:32:42 +0300, Andrew Eddie <mamb...@gmail.com>
wrote:

> Just going through the plugin change-over at the moment.
>
> It strikes me as appropriate to have:
>
> onExtensionBeforeSave
> onExtensionAfterSave
>
> as events to happen when saving modules, plugins, languages, and
> templates. Currently it's using onContent* which is "ok" but probably
> not quite contextually correct.
>
> Last minute thoughts?

I think this is a nice idea. The names are semantically correct as I see.
As I understand with this and with $context variable we will can do some
stuff only for all languages, templates, modules and components too.

--
Artyom

[Peter van Westen]

Hello Andrew,

I have added the 3 triggers to the helper file (onContentPrepareModuleQuery, onContentPrepareModuleList, onContentRenderModule).
I hope the patch format (by NetBeans) is ok like this.

Maybe Stephen wants to take a look at it first....?

Peter

[Stephen]

I agree with Peter's patch; it does the minimum required to get AMM
and MMP (and any other extensions that want to use the triggers)
running together.

Unfortunately, without having extra plugins at the
onContentPrepareModuleList point, it does cause a major usability
issue for users using more than 1 plugin that uses these triggers.

Getting users to re-order the plugins correctly has been a major
bugbear for MetaMod Pro.

It's also a headache for development, in this sense: MetaMod Pro
actually goes through a 2 stage process in the plugin. The first is to
manipulate the list of modules, and the second is to post-process the
list, applying parameter changes to the final list of modules.

To make my plugin play nicely with other plugins when there's only 1
trigger, I should really separate my plugin into 2 separate plugins,
so that other plugins could get in between my 2 functions. Then, I am
faced with trying to ensure that my 2 plugins are ordered in the right
way, because that's now at the mercy of the installation procedure,
which should really have no say in the matter.

After some robust discussion over this, Peter and I came to the
conclusion that it was much more important for our users to be able to
do a simple install and not worry about having to go through plugin
ordering issues, than it was to give users complete control over
ordering using plugin ordering.

We felt that it was actually our responsibility as developers to
determine the correct ordering of our code, rather than pass that
responsibility to the site administrator. This was based on
differences in role/functionality of the code.

At the end of the day, our respective plugins fulfilled distinct roles
in the process which could be categorised as "prepare", "alter" and
"postprocess" steps in the process of manipulating the module list and
the module parameters, so it made sense to make triggers that
reflected those stages. This still allows other plugins to get into
the process whilst retaining the same overall ordering structure.

Ok Andrew, so I understand your general objection to adding triggers
willy-nilly. But advanced module manipulation such as Peter and I are
doing is quite complex and all it requires is a few lines of code to
really open this up. AMM and MMP are already 2 very popular and mature
Joomla extensions that have a proven need and solution (in 1.5) to the
issues.

Can you please consider putting in 3 triggers instead of 1, at the
point in Peter's patch where onContentPrepareModuleList is found? i.e.
onContentPrepareModuleList, onContentAlterModuleList and
onContentPostprocessModuleList

Thanks for your consideration,
Stephen

On 5 May, 01:27, Peter van Westen <petervanwes...@gmail.com> wrote:
> Hello Andrew,
>
> I have added the 3 triggers to the helper file (onContentPrepareModuleQuery,
> onContentPrepareModuleList, onContentRenderModule).
> I hope the patch format (by NetBeans) is ok like this.
>
> Maybe Stephen wants to take a look at it first....?
>
> Peter
>
>
>
>
>

> On Tue, May 4, 2010 at 2:49 PM, Artyom Bisyarin <arts...@ukr.net> wrote:
> > On Tue, 04 May 2010 15:32:42 +0300, Andrew Eddie <mambob...@gmail.com>

> > wrote:
>
> >  Just going through the plugin change-over at the moment.
>
> >> It strikes me as appropriate to have:
>
> >> onExtensionBeforeSave
> >> onExtensionAfterSave
>
> >> as events to happen when saving modules, plugins, languages, and
> >> templates.  Currently it's using onContent* which is "ok" but probably
> >> not quite contextually correct.
>
> >> Last minute thoughts?
>
> > I think this is a nice idea. The names are semantically correct as I see.
> > As I understand with this and with $context variable we will can do some
> > stuff only for all languages, templates, modules and components too.
>
> > --
> > Artyom
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! CMS Development" group.
> > To post to this group, send an email to joomla-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsubscribe@go oglegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>

>  module_helper.patch
> 2KViewDownload

[Andrew Eddie]

Hi Stephen

I was talking to Louis this morning and I think we've come up with a
better solution. What we propose is to add a list getter and setter
to JModuleHelper.

The getter will get the internal list of modules currently loaded.

The setter will allow you to override the internal list with whatever
you want. The setter will also set an internal flag that the module
list is loaded. When _load is called, if the loaded flag is set, it
will not do the normal Joomla query.

In this way you and Peter can use onAfterInitilise, onAfterRoute or
onBeforeRender (most likely suspect). It doesn't solve the plugin
order issue, but that's also not confined to just your case, but will
give you the ability to control modules how you want.

So what you'll do is write a onBeforeRender Plugin that does this:

$existingModules = JModuleHelper::getModuleList();
// do your processing
JModuleHelper::setModuleList($newList);

Sound like a plan?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Stephen]

Hi Andrew,

that sounds interesting, and I'm spending a little time digesting it.

1 - I take it that onBeforeRender is a new trigger, perhaps replacing
onAfterDispatch?

2 - apart from allowing plugins to alter the module list without
implementing the event we were talking about earlier, just by using
the new getter/setter, what advantages does this actually offer? If it
allows triggers inside the component/content system to manipulate the
module list, that would certainly be interesting!

3 - there are some uses of MetaMod that parse the rendered output of
the main component on the page. This obviously relies on the
construction of the module list happening after the component has been
rendered. Is there any trigger that will occur after the component is
rendered but before the modules are rendered? (I know this is an edge
case but I'm just trying to understand the new scenario)

4 - are you still considering the 1st 2 triggers in Peter's patch, viz
onContentRenderModule (with the return value able to short circuit
module output), and onContentPrepareModuleQuery able to alter the
query? Both are important for Advanced Module Manager (neither are
used by MetaMod Pro).

5 - as I think about this some more I am bothered about the fact that
allowing access to change the module list at a number of different
times and places means that there's no definitive place in the code
where you know that the module list has been finalised. In J1.5, at
the end of the _load() method, the module list was finalised, so the
part of my plugin that alters module parameters could run last (in the
new triggers we put in) and know that the rest of the list was
finalised. Under the new system, I would have to search for the last
possible trigger that runs anywhere before the module list is actually
used, then use that for my plugin, in order to guarantee that my post-
processing runs over the finalised list.

This is really not ideal - in fact it looks like spaghetti. I think I
would prefer the triple-whammy of onContentPrepareModuleList,
onContentAlterModuleList and onContentPostprocessModuleList, because
(sorry to repeat myself) these are 3 separate tasks which need to be
done in that order. Ok, we could cut that down to just
onContentPrepareModuleList and onContentPostprocessModuleList at a
pinch.

I see this being a bit like the content-related triggers
onBeforeDisplayContent and onAfterDisplayContent. You have separate
ones because some things just have to go before, and some have to go
after the content. You don't rely on users to reorder plugins just to
get the plugins to render before the content or after it. I know the
analogy is not perfect, but the principle is simply that if we already
know that 1 set of things has to happen before another set of things,
there's no point in leaving the task of ordering them correctly to the
user, using the plugin manager.

In summary - the thought of components being able to insert/delete
modules is an attractive one, but I strongly think that there are sub-
tasks inherent in module list manipulation that need to be done in a
specified order. Therefore I don't support this idea as a replacement
for the plugin suggestion from Peter and myself unless the subtask
issue is also addressed.

Sorry Andrew,
Stephen

On 5 May, 12:31, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Stephen
>
> I was talking to Louis this morning and I think we've come up with a
> better solution.  What we propose is to add a list getter and setter
> to JModuleHelper.
>
> The getter will get the internal list of modules currently loaded.
>
> The setter will allow you to override the internal list with whatever
> you want.  The setter will also set an internal flag that the module
> list is loaded.  When _load is called, if the loaded flag is set, it
> will not do the normal Joomla query.
>
> In this way you and Peter can use onAfterInitilise, onAfterRoute or
> onBeforeRender (most likely suspect).  It doesn't solve the plugin
> order issue, but that's also not confined to just your case, but will
> give you the ability to control modules how you want.
>
> So what you'll do is write a onBeforeRender Plugin that does this:
>
> $existingModules = JModuleHelper::getModuleList();
> // do your processing
> JModuleHelper::setModuleList($newList);
>
> Sound like a plan?
>
> Regards,

> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer

> > For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.

>
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Andrew Eddie]

Hi Stephen

On 5 May 2010 12:02, Stephen <ma...@clanbrandon.co.uk> wrote:
> Hi Andrew,
>
> that sounds interesting, and I'm spending a little time digesting it.
>
> 1 - I take it that onBeforeRender is a new trigger, perhaps replacing
> onAfterDispatch?

It might be new to 1.6, can't recall.

> 2 - apart from allowing plugins to alter the module list without
> implementing the event we were talking about earlier, just by using
> the new getter/setter, what advantages does this actually offer? If it
> allows triggers inside the component/content system to manipulate the
> module list, that would certainly be interesting!

It is.

> 3 - there are some uses of MetaMod that parse the rendered output of
> the main component on the page. This obviously relies on the
> construction of the module list happening after the component has been
> rendered. Is there any trigger that will occur after the component is
> rendered but before the modules are rendered? (I know this is an edge
> case but I'm just trying to understand the new scenario)

That's what onBeforeRender is for.

> 4 - are you still considering the 1st 2 triggers in Peter's patch, viz
> onContentRenderModule (with the return value able to short circuit
> module output), and onContentPrepareModuleQuery able to alter the
> query? Both are important for Advanced Module Manager (neither are
> used by MetaMod Pro).

The render yes, the query event is not needed. Peter just has a look
at what's already processed and diff's, intersects, whatever he wants
to do. Ideally he would fire first.

> 5 - as I think about this some more I am bothered about the fact that
> allowing access to change the module list at a number of different
> times and places means that there's no definitive place in the code
> where you know that the module list has been finalised. In J1.5, at
> the end of the _load() method, the module list was finalised, so the
> part of my plugin that alters module parameters could run last (in the
> new triggers we put in) and know that the rest of the list was
> finalised. Under the new system, I would have to search for the last
> possible trigger that runs anywhere before the module list is actually
> used, then use that for my plugin, in order to guarantee that my post-
> processing runs over the finalised list.

I've got to look at things beyond what just suits your extension, and
likewise you have to take into account other extensions that may range
from "tolerating" each other to flat out conflicting.

> This is really not ideal - in fact it looks like spaghetti. I think I
> would prefer the triple-whammy of onContentPrepareModuleList,
> onContentAlterModuleList and onContentPostprocessModuleList, because
> (sorry to repeat myself) these are 3 separate tasks which need to be
> done in that order. Ok, we could cut that down to just
> onContentPrepareModuleList and onContentPostprocessModuleList at a
> pinch.
>
> I see this being a bit like the content-related triggers
> onBeforeDisplayContent and onAfterDisplayContent. You have separate
> ones because some things just have to go before, and some have to go
> after the content. You don't rely on users to reorder plugins just to
> get the plugins to render before the content or after it. I know the
> analogy is not perfect, but the principle is simply that if we already
> know that 1 set of things has to happen before another set of things,
> there's no point in leaving the task of ordering them correctly to the
> user, using the plugin manager.

No, that's not a good analogy. The users still have to order the
plugins to display things within those positions how they want. What
you are proposing is more like having

onContentAfterTitle_preprocess
onContentAfterTitle_process
onContentAfterTitle_postprocess

> In summary - the thought of components being able to insert/delete
> modules is an attractive one, but I strongly think that there are sub-
> tasks inherent in module list manipulation that need to be done in a
> specified order. Therefore I don't support this idea as a replacement
> for the plugin suggestion from Peter and myself unless the subtask
> issue is also addressed.
>
> Sorry Andrew,
> Stephen

Well, I guess you have a choice of spaghetti or nothing for dinner.
I'm willing to put the effort in right at the eleventh hour but you
are going to have to work with me. The way I would solve your
challenged customer ordering problem is put the logic in your backend
interface and have it throw a system message that plugin ordering need
to be fixed "click here to adjust". If you don't have a UI component,
then there are tricks you can certainly use in the plugin itself to
let your customer know that they are going to run into trouble.

Regards,
Andrew Eddie

[Peter van Westen]

Hi Andrew, Stephen,

The whole reason I used the query stuff  is to reduce server power / page load.
If plugins are going to 'only' be able to overrule the module list, then you have a lot of overhead.

In the case of AMM (just taking as example because I know how it works :) ), it would basically through away the modulelist collected by Joomla (and any other plugin) and start over fresh.
So you have a lot of extra mysql queries and a lot of redundant code being executed.

What I am basically saying is that Stephen and I are - I think - the major players having any use for the module triggers. We are at least the ones that suggested it.
If stuff is not implemented in a way we can actually use, then we will have to keep overruling the core helper. Which kind of defies the whole need of putting any new triggers in.

Peter

[Andrew Eddie]

Hi Peter.

On 5 May 2010 14:41, Peter van Westen <peterva...@gmail.com> wrote:
> Hi Andrew, Stephen,
>
> The whole reason I used the query stuff  is to reduce server power / page
> load.
> If plugins are going to 'only' be able to overrule the module list, then you
> have a lot of overhead.
>
> In the case of AMM (just taking as example because I know how it works :) ),
> it would basically through away the modulelist collected by Joomla (and any
> other plugin) and start over fresh.
> So you have a lot of extra mysql queries and a lot of redundant code being
> executed.

As long as you are the first to "set" the module list, no further
queries will be executed. That's the beauty of it - you get to
override the core query. Think about it realistically, do you really
want more than one thing controlling the query? For example, a second
plugin tries to modify your query - er, with unexpected results.

Or am I missing something?

Do you both need to modify the base query (I'm thinking that starts to
get dangerous)?

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer

[Stephen]

On 5 May, 16:47, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Peter.
>

> On 5 May 2010 14:41, Peter van Westen <petervanwes...@gmail.com> wrote:
>
> > Hi Andrew, Stephen,
>
> > The whole reason I used the query stuff  is to reduce server power / page
> > load.
> > If plugins are going to 'only' be able to overrule the module list, then you
> > have a lot of overhead.
>
> > In the case of AMM (just taking as example because I know how it works :) ),
> > it would basically through away the modulelist collected by Joomla (and any
> > other plugin) and start over fresh.
> > So you have a lot of extra mysql queries and a lot of redundant code being
> > executed.
>
> As long as you are the first to "set" the module list, no further
> queries will be executed.  That's the beauty of it - you get to
> override the core query.

Ok, so you are saying that the core module helper class would only do
its own query if someone does a "getModules()" call and a list hadn't
already been self-generated or set externally? That makes better
sense, and I think is probably preferable to modifying the query
parameters in the way that we had been doing.

The challenge for anyone writing a plugin that is to take advantage of
this, however, is to ensure that their plugin does the getModules()
call before anything else does... because *it has to be done first*.

> Think about it realistically, do you really
> want more than one thing controlling the query?  For example, a second
> plugin tries to modify your query - er, with unexpected results.

Yes, always a danger.

>
> Or am I missing something?
>
> Do you both need to modify the base query (I'm thinking that starts to
> get dangerous)?

Actually MetaMod Pro doesn't need to do that, only AMM does; so far we
haven't had to deal with conflicts there.


Without interspersing extra comments below, I'll just summarise my
thoughts here:

Andrew, I can see, and respect, that you are trying to ensure that any
changes don't set dangerous precedents, and consider "things beyond
what just suits your[my] extension".

What I haven't seen yet is any examples of what other types of
situations there might be. Peter's and my extensions had been quite
different in approach, and yet we came up with a good solution using
plugins. We came to the realisation that there were specific steps in
the preparation of a module list that transcended both of our
extensions, and using a prepare-alter-postprocess paradigm made sense
and allowed our extensions to slot into the right part of the process
without conflicting. And, there was nothing in the rewritten helper
class which was particularly specific to our extensions - just a good
general trigger/plugin architecture.

Can you give some example of the sort of reason why a prepare-alter-
postprocess structure wouldn't be a good architectural solution in
this case?

I know this is all 11th-hour, but as Peter says, if the changes that
you make don't end up working for us we'll just have to go back to
overriding the entire class, and I would be really saddened to have to
do that. We all want Joomla to be as versatile and well-written as
possible.


Best regards,
Stephen

>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
>
>

> > What I am basically saying is that Stephen and I are - I think - the major
> > players having any use for the module triggers. We are at least the ones
> > that suggested it.
> > If stuff is not implemented in a way we can actually use, then we will have
> > to keep overruling the core helper. Which kind of defies the whole need of
> > putting any new triggers in.
>
> > Peter
>

> > On Wed, May 5, 2010 at 5:11 AM, Andrew Eddie <mambob...@gmail.com> wrote:
>
> >> Hi Stephen
>

> >> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla

[Christopher Garvis]

I think this is very interesting and would like to see this discussed
further. Andrew, how is this going to be implemented? Do you need
some extra hands to get this moving?

On May 5, 4:09 am, Stephen <m...@clanbrandon.co.uk> wrote:
> On 5 May, 16:47, Andrew Eddie <mambob...@gmail.com> wrote:
>
>
>
> > Hi Peter.
>
> > On 5 May 2010 14:41, Peter van Westen <petervanwes...@gmail.com> wrote:
>
> > > Hi Andrew, Stephen,
>
> > > The whole reason I used the query stuff  is to reduce server power / page
> > > load.
> > > If plugins are going to 'only' be able to overrule the module list, then you
> > > have a lot of overhead.
>

> > > In the case ofAMM(just taking as example because I know how it works :) ),

> > > it would basically through away the modulelist collected by Joomla (and any
> > > other plugin) and start over fresh.
> > > So you have a lot of extra mysql queries and a lot of redundant code being
> > > executed.
>
> > As long as you are the first to "set" the module list, no further
> > queries will be executed.  That's the beauty of it - you get to
> > override the core query.
>
> Ok, so you are saying that the core module helper class would only do
> its own query if someone does a "getModules()" call and a list hadn't
> already been self-generated or set externally? That makes better
> sense, and I think is probably preferable to modifying the query
> parameters in the way that we had been doing.
>
> The challenge for anyone writing a plugin that is to take advantage of
> this, however, is to ensure that their plugin does the getModules()
> call before anything else does... because *it has to be done first*.
>
> > Think about it realistically, do you really
> > want more than one thing controlling the query?  For example, a second
> > plugin tries to modify your query - er, with unexpected results.
>
> Yes, always a danger.
>
>
>
> > Or am I missing something?
>
> > Do you both need to modify the base query (I'm thinking that starts to
> > get dangerous)?
>

> Actually MetaMod Pro doesn't need to do that, onlyAMMdoes; so far we

> > Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
>

> ...
>
> read more »

[Andrew Eddie]

Hi Christopher.

The proposed changes have been made. I haven't done anything with the
modules issues - just ran out of time to give that the justice it
deserved. I'd recommend Peter and Stephen grad a branch and start
playing with ideas there. I also missed an opportunity to put in an
event for when someone uploads a file (onContentAfterUpload maybe).
Will have to wait till 1.7.

Thanks for the offer. We can alway use help on the Bug Squad though.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer