com_modules cleanup
11 views
Skip to first unread message
Andrew Eddie
Nov 17, 2009, 7:13:55 PM11/17/09
to joomla-...@googlegroups.com
Sometime in the next few days I'll be bringing com_modules up to
Beta-ready status.
Beta-ready status.
Are the any practical (*and* achievable) productivity improvements
that can be looked at before it's signed off? What are the gnawing
annoyances in the management of modules from the backend? Are there
things you wish you could do (eg, batch change a heap of selected
modules to a different position; toggle module title setting from the
list view; etc)?
I've had one suggestion to include some way of filtering the module
list by a specific menu page and/or it's child menus. I can see that
being useful (not quite sure about how to do the child menus
'elegantly', but anyway).
I think the option to exclude modules on a page is in but I've not had
a good look at how this works yet.
Are there things that you simply don't use or that aren't terribly
useful (the Template filter in the module list for example)?
Thanks in advance for your input. As always no guarantees on anything
but if you are willing to help code it then this can be taken into
consideration :)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
rickblalock
Nov 17, 2009, 9:07:54 PM11/17/09
to Joomla! CMS Development
One would be default forcing some module parameters, namely the module
suffix one. I hate it when 3PD devs forget to put it in there. It's
easy to implement so I don't know why they forget that param...but
forcing it on all modules would be nice so it's always available.
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
suffix one. I hate it when 3PD devs forget to put it in there. It's
easy to implement so I don't know why they forget that param...but
forcing it on all modules would be nice so it's always available.
Andrew Eddie
Nov 17, 2009, 9:41:35 PM11/17/09
to joomla-...@googlegroups.com
Hi Rick (??)
So are you suggesting that even if the module develop forgets to put
in those common params, like suffix, cache, etc, Joomla should inject
them? Sort of like the Page Options in the menu manager with the page
title and stuff?
Or in other words, make it so the developer doesn't have to put them
in, Joomla will add them automatically? If that's the case, I like
it.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/18 rickblalock <rbla...@gmail.com>:
So are you suggesting that even if the module develop forgets to put
in those common params, like suffix, cache, etc, Joomla should inject
them? Sort of like the Page Options in the menu manager with the page
title and stuff?
Or in other words, make it so the developer doesn't have to put them
in, Joomla will add them automatically? If that's the case, I like
it.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/18 rickblalock <rbla...@gmail.com>:
Stephen
Nov 17, 2009, 10:37:17 PM11/17/09
to Joomla! CMS Development
Inserting them "if the developer forgets them" sounds interesting, but
second-guessing the developer doesn't quite sound right. Wouldn't it
be better to make an accordion section that just always automatically
includes these standard items? (like the Advanced section). Perhaps
these are good candidates to automatically go in the Advanced section?
Whichever way it's done, I think that it would be great to include
these for every module since they have a system-defined function
irrespective of the particular module.
Apart from that, here's my partial wish-list, in no particular order:
- the ability for module developers to create arbitrary accordion
sections. For modules with multiple parameters this could really help
with grouping and therefore usability.
- adding start datetime and stop datetime to modules, as for
components. I already submitted a patch for this months ago - I hope
now might be the time to resurrect this!
- having some way of displaying which menu items a module has been
assigned to, from the main module list. Perhaps this could be a popup/
hover/tooltip when hovering over some cell in the table? On a site
with hundreds of modules, it's very inconvenient to have to edit a
module simply to find out which pages it has been assigned to.
- "assigned to all pages *except*..." option when doing menu
assignments. (perhaps you have already added this?)
- a means for determining which modules have been assigned to a
particular page. This could be a panel in the Menu Manager, when
editing a particular menu item, that simply lists, in order, which
modules are assigned to ALL pages and which are assigned to that page
in particular (or have not been excluded from that page, if using the
exclusion feature mentioned above). Others might be able to suggest a
suitable location closer to the Module Manager (i.e. accessible from
within that component) where you might be able to get hold of the same
information - this is to do with the workflow of managing modules,
after all, so necessary to have a way to view that without needing to
go to the Menu Manager.
--- Oh, I know -- make a drop-down filter (like the other filters on
the Module Manager) that contains all the menu items from all the
menus. Filter the list of modules by those that appear on that menu
item. This would SO rock. I would be using it constantly.
- a defined plugin API within the Module Helper class. There are at
least 2 developers now (nonumber.nl for Advanced Modules, and
metamodpro.com for MetaMod Pro) who are overriding the module helper
class in order to provide advanced functionality. The functionality is
awesome... but the lack of a defined API means that only 1 plugin at a
time can override this class, and we're stepping on each others' toes.
-- in particular, a plugin point within _load() to allow plugins to
post-process the list of modules returned from the database.
- I've never used the filter for selecting modules in the manager
based on template. I hadn't even noticed it was there until now! I am
sure that for people who use lots of templates it could be very useful
though so I would suggest it stays. I use all the other filters
extensively.
- plugin functionality within the module editing screen, to allow 3rd
part components/plugins to add extra parameters to ALL types of
modules. This could end up being extra parameters in the list of
parameters on the right hand side (e.g. a new accordion tab), an
individual parameter inserted into the list of parameters, or an extra
section placed on the left hand side below the Menu Assignment box.
Again, 3PDs are providing ingenious overrides in order to place
additional UI in some of these places, and it would be great to make
an official API in order to do this.
That's all for now,
Stephen
@stephen_brandon
On 18 Nov, 15:41, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Rick (??)
>
> So are you suggesting that even if the module develop forgets to put
> in those common params, like suffix, cache, etc, Joomla should inject
> them? Sort of like the Page Options in the menu manager with the page
> title and stuff?
>
> Or in other words, make it so the developer doesn't have to put them
> in, Joomla will add them automatically? If that's the case, I like
> it.
>
> Regards,
> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
second-guessing the developer doesn't quite sound right. Wouldn't it
be better to make an accordion section that just always automatically
includes these standard items? (like the Advanced section). Perhaps
these are good candidates to automatically go in the Advanced section?
Whichever way it's done, I think that it would be great to include
these for every module since they have a system-defined function
irrespective of the particular module.
Apart from that, here's my partial wish-list, in no particular order:
- the ability for module developers to create arbitrary accordion
sections. For modules with multiple parameters this could really help
with grouping and therefore usability.
- adding start datetime and stop datetime to modules, as for
components. I already submitted a patch for this months ago - I hope
now might be the time to resurrect this!
- having some way of displaying which menu items a module has been
assigned to, from the main module list. Perhaps this could be a popup/
hover/tooltip when hovering over some cell in the table? On a site
with hundreds of modules, it's very inconvenient to have to edit a
module simply to find out which pages it has been assigned to.
- "assigned to all pages *except*..." option when doing menu
assignments. (perhaps you have already added this?)
- a means for determining which modules have been assigned to a
particular page. This could be a panel in the Menu Manager, when
editing a particular menu item, that simply lists, in order, which
modules are assigned to ALL pages and which are assigned to that page
in particular (or have not been excluded from that page, if using the
exclusion feature mentioned above). Others might be able to suggest a
suitable location closer to the Module Manager (i.e. accessible from
within that component) where you might be able to get hold of the same
information - this is to do with the workflow of managing modules,
after all, so necessary to have a way to view that without needing to
go to the Menu Manager.
--- Oh, I know -- make a drop-down filter (like the other filters on
the Module Manager) that contains all the menu items from all the
menus. Filter the list of modules by those that appear on that menu
item. This would SO rock. I would be using it constantly.
- a defined plugin API within the Module Helper class. There are at
least 2 developers now (nonumber.nl for Advanced Modules, and
metamodpro.com for MetaMod Pro) who are overriding the module helper
class in order to provide advanced functionality. The functionality is
awesome... but the lack of a defined API means that only 1 plugin at a
time can override this class, and we're stepping on each others' toes.
-- in particular, a plugin point within _load() to allow plugins to
post-process the list of modules returned from the database.
- I've never used the filter for selecting modules in the manager
based on template. I hadn't even noticed it was there until now! I am
sure that for people who use lots of templates it could be very useful
though so I would suggest it stays. I use all the other filters
extensively.
- plugin functionality within the module editing screen, to allow 3rd
part components/plugins to add extra parameters to ALL types of
modules. This could end up being extra parameters in the list of
parameters on the right hand side (e.g. a new accordion tab), an
individual parameter inserted into the list of parameters, or an extra
section placed on the left hand side below the Menu Assignment box.
Again, 3PDs are providing ingenious overrides in order to place
additional UI in some of these places, and it would be great to make
an official API in order to do this.
That's all for now,
Stephen
@stephen_brandon
On 18 Nov, 15:41, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Rick (??)
>
> So are you suggesting that even if the module develop forgets to put
> in those common params, like suffix, cache, etc, Joomla should inject
> them? Sort of like the Page Options in the menu manager with the page
> title and stuff?
>
> Or in other words, make it so the developer doesn't have to put them
> in, Joomla will add them automatically? If that's the case, I like
> it.
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/11/18 rickblalock <rblal...@gmail.com>:
>
Andrea Tarr at Tarr Consulting
Nov 18, 2009, 12:06:53 AM11/18/09
to joomla-...@googlegroups.com
The one suggestion I have is a UI one.
The menu selection dropdown on the menu assignment requires multi-selects on
a dropdown. It's very easy for users to make errors on the selection without
even realizing it. Some users don't recognize that they need to do the
ctl-click/shift-clicks -- or whatever it is on macs :) -- to select menu
items without wiping out the existing selection.
Something like a tree with checkboxes would be much more robust and less
prone to errors.
Andy
Andrea Tarr
www.tarrconsulting.com
The menu selection dropdown on the menu assignment requires multi-selects on
a dropdown. It's very easy for users to make errors on the selection without
even realizing it. Some users don't recognize that they need to do the
ctl-click/shift-clicks -- or whatever it is on macs :) -- to select menu
items without wiping out the existing selection.
Something like a tree with checkboxes would be much more robust and less
prone to errors.
Andy
Andrea Tarr
www.tarrconsulting.com
Andrew Eddie
Nov 18, 2009, 12:17:32 AM11/18/09
to joomla-...@googlegroups.com
Hi Stephen.
Great suggestions. Some are possible now, and some will be soon.
Others I'll look into.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/18 Stephen <ma...@clanbrandon.co.uk>:
Great suggestions. Some are possible now, and some will be soon.
Others I'll look into.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/18 Stephen <ma...@clanbrandon.co.uk>:
Andrew Eddie
Nov 18, 2009, 12:28:17 AM11/18/09
to joomla-...@googlegroups.com
Don't you hate it when that happens. Click - oops - what menus had I
assigned again?
Good catch. A list of checkboxes and labels in a scrolling div ok?
2009/11/18 Andrea Tarr at Tarr Consulting <at...@tarrconsulting.com>:
assigned again?
Good catch. A list of checkboxes and labels in a scrolling div ok?
2009/11/18 Andrea Tarr at Tarr Consulting <at...@tarrconsulting.com>:
Andrea Tarr
Nov 18, 2009, 12:48:26 AM11/18/09
to joomla-...@googlegroups.com
Yes, anything with a little less "oh, sh*t" to it would be good.
Andy
Andrea Tarr
Sent from mobile
Andy
Andrea Tarr
Sent from mobile
Terry Szykowny
Nov 18, 2009, 2:08:01 AM11/18/09
to joomla-...@googlegroups.com
Good question... i miss one thing in joomla, actually in general: the possibility to inherit settings for submenus and subpages of a menu. If u have a Plugin or Module to assign, sometimes it would be necessary and very comfortable to have an option saying "inherit assign for all subpages"... Typo3 (otherwise not my favourite...) has this as a standard. I did something similar recently for a J1.5 Plugin, it's well possible and so convenient...
Ercan Özkaya
Nov 18, 2009, 5:00:59 AM11/18/09
to Joomla! CMS Development
Hi Andrew,
Stephen sent a patch for publishing times and I decided to re-synch
and commit it after refactoring. If you can find a chance to implement
it, that would be useful. Patch is here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17099
On Nov 18, 9:08 am, Terry Szykowny <citystro...@gmail.com> wrote:
> Good question... i miss one thing in joomla, actually in general: the
> possibility to inherit settings for submenus and subpages of a menu. If u
> have a Plugin or Module to assign, sometimes it would be necessary and very
> comfortable to have an option saying "inherit assign for all subpages"...
> Typo3 (otherwise not my favourite...) has this as a standard. I did
> something similar recently for a J1.5 Plugin, it's well possible and so
> convenient...
>
Stephen sent a patch for publishing times and I decided to re-synch
and commit it after refactoring. If you can find a chance to implement
it, that would be useful. Patch is here:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17099
On Nov 18, 9:08 am, Terry Szykowny <citystro...@gmail.com> wrote:
> Good question... i miss one thing in joomla, actually in general: the
> possibility to inherit settings for submenus and subpages of a menu. If u
> have a Plugin or Module to assign, sometimes it would be necessary and very
> comfortable to have an option saying "inherit assign for all subpages"...
> Typo3 (otherwise not my favourite...) has this as a standard. I did
> something similar recently for a J1.5 Plugin, it's well possible and so
> convenient...
>
> 18. 11 2009 1:14 AM schrieb am "Andrew Eddie" <mambob...@gmail.com>:
>
> Sometime in the next few days I'll be bringing com_modules up to
> Beta-ready status.
>
> Are the any practical (*and* achievable) productivity improvements
> that can be looked at before it's signed off? What are the gnawing
> annoyances in the management of modules from the backend? Are there
> things you wish you could do (eg, batch change a heap of selected
> modules to a different position; toggle module title setting from the
> list view; etc)?
>
> I've had one suggestion to include some way of filtering the module
> list by a specific menu page and/or it's child menus. I can see that
> being useful (not quite sure about how to do the child menus
> 'elegantly', but anyway).
>
> I think the option to exclude modules on a page is in but I've not had
> a good look at how this works yet.
>
> Are there things that you simply don't use or that aren't terribly
> useful (the Template filter in the module list for example)?
>
> Thanks in advance for your input. As always no guarantees on anything
> but if you are willing to help code it then this can be taken into
> consideration :)
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer>
> Sometime in the next few days I'll be bringing com_modules up to
> Beta-ready status.
>
> Are the any practical (*and* achievable) productivity improvements
> that can be looked at before it's signed off? What are the gnawing
> annoyances in the management of modules from the backend? Are there
> things you wish you could do (eg, batch change a heap of selected
> modules to a different position; toggle module title setting from the
> list view; etc)?
>
> I've had one suggestion to include some way of filtering the module
> list by a specific menu page and/or it's child menus. I can see that
> being useful (not quite sure about how to do the child menus
> 'elegantly', but anyway).
>
> I think the option to exclude modules on a page is in but I've not had
> a good look at how this works yet.
>
> Are there things that you simply don't use or that aren't terribly
> useful (the Template filter in the module list for example)?
>
> Thanks in advance for your input. As always no guarantees on anything
> but if you are willing to help code it then this can be taken into
> consideration :)
>
> Regards,
Alan
Nov 18, 2009, 5:03:17 AM11/18/09
to joomla-...@googlegroups.com
One thing I have found useful in modules is to separate the display
title from the admin title. I have done this by adding allternative
title in XML and using custom chrome to display it. If this was in the
core then admins with lots of modules can make more relevant internal
titles and have different public facing titles too. This is especially
useful where modules have same name, eg "latest x" in different
contexts. Combined with other suggestions here would be near puurfect
Alan
Sent from my iPhone
title from the admin title. I have done this by adding allternative
title in XML and using custom chrome to display it. If this was in the
core then admins with lots of modules can make more relevant internal
titles and have different public facing titles too. This is especially
useful where modules have same name, eg "latest x" in different
contexts. Combined with other suggestions here would be near puurfect
Alan
Sent from my iPhone
Jen Kramer McKibben
Nov 18, 2009, 7:33:18 AM11/18/09
to Joomla! CMS Development
Since someone mentioned menus --
The little start/stop menu boxes in the main menu module are really
confusing for most non-developers. When one starts counting with zero,
and 0/0 means every level of nav but 1/0 means start at the 2nd level
and go forever after, it's just a little much for some people to wrap
their head around.
Perhaps this needs a good tooltip to explain how it works, or to start
counting with 1 and go from there (instead of zero, where zero could
mean infinite instead of primary navigation and going down to all
levels).
Small thing, but I've watched many beginners stumble on it.
thanks,
Jen
The little start/stop menu boxes in the main menu module are really
confusing for most non-developers. When one starts counting with zero,
and 0/0 means every level of nav but 1/0 means start at the 2nd level
and go forever after, it's just a little much for some people to wrap
their head around.
Perhaps this needs a good tooltip to explain how it works, or to start
counting with 1 and go from there (instead of zero, where zero could
mean infinite instead of primary navigation and going down to all
levels).
Small thing, but I've watched many beginners stumble on it.
thanks,
Jen
G. D. Speer
Nov 18, 2009, 10:24:04 AM11/18/09
to Joomla! CMS Development
+1 for this - it would be a Huge improvement.
Nice if the Front End Display Name can also include tags or designate it's
surrounding tag
Example: Module Title: Latest News for Staff New category
Display Name: <h3>Latest News</h3>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.69/2508 - Release Date: 11/17/09
07:40:00
Nice if the Front End Display Name can also include tags or designate it's
surrounding tag
Example: Module Title: Latest News for Staff New category
Display Name: <h3>Latest News</h3>
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.69/2508 - Release Date: 11/17/09
07:40:00
Niels Braczek
Nov 18, 2009, 10:43:40 AM11/18/09
to joomla-...@googlegroups.com
G. D. Speer schrieb:
> Display Name: <h3>Latest News</h3>
No! HTML elements belong to the template only, not to the data.
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
G. D. Speer
Nov 18, 2009, 11:27:52 AM11/18/09
to Joomla! CMS Development
You're right - but IMHO sometimes it's nice to be able to pass a
user-selected h-level preference into the template without having several
template permutations just to promote or demote the level of heading. (the
template doesn't have to honor it, but those that are equipped to do so, can
and I suggest core modules have this option exposed for users that are not
comfortable with the mechanics of cloning core module templates and adding
template selection parameters.)
----- Original Message -----
From: "Niels Braczek" <nbra...@bsds.de>
To: <joomla-...@googlegroups.com>
Sent: Wednesday, November 18, 2009 8:43 AM
Subject: Re: com_modules cleanup
07:50:00
user-selected h-level preference into the template without having several
template permutations just to promote or demote the level of heading. (the
template doesn't have to honor it, but those that are equipped to do so, can
and I suggest core modules have this option exposed for users that are not
comfortable with the mechanics of cloning core module templates and adding
template selection parameters.)
----- Original Message -----
From: "Niels Braczek" <nbra...@bsds.de>
To: <joomla-...@googlegroups.com>
Sent: Wednesday, November 18, 2009 8:43 AM
Subject: Re: com_modules cleanup
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09
No virus found in this incoming message.
Checked by AVG - www.avg.com
07:50:00
Phil Snell
Nov 18, 2009, 11:35:19 AM11/18/09
to joomla-...@googlegroups.com
but this should be done in chrome, no?
Alan Sparkes
Nov 18, 2009, 12:06:33 PM11/18/09
to joomla-...@googlegroups.com
The <h3> should be in the chrome/template rather than the module core.
alan
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00
Alan Sparkes
Nov 18, 2009, 12:09:38 PM11/18/09
to joomla-...@googlegroups.com
I have definitely read that com_content is NOT on the 1.6 map - I hear it J
However will there be any underlying structure/functioanilty that will allow extending of the content type (ie additional fields) manually through xml files?
Cheers alan
Poetic Systems
Nov 18, 2009, 12:27:29 PM11/18/09
to Joomla! CMS Development
There needs to be a way to set a module to show up if no other module
is published in a certain position. We have lots of cases where we use
different header images on pages and we assign them by menu item but
there are many times where certain components redirect to pages that
don't have menu items and as far as I can tell there is no way to have
a catch all module that will appear when no other module has been
specified.
is published in a certain position. We have lots of cases where we use
different header images on pages and we assign them by menu item but
there are many times where certain components redirect to pages that
don't have menu items and as far as I can tell there is no way to have
a catch all module that will appear when no other module has been
specified.
Gergő Erdősi
Nov 18, 2009, 12:29:53 PM11/18/09
to joomla-...@googlegroups.com
Hi,
All com_content related changes are targeted to 1.7. However you will
be able to extend easily the fields in 1.6 too using the JForm
library.
--
Gergő Erdősi
2009/11/18 Alan Sparkes <in...@joomkit.com>:
All com_content related changes are targeted to 1.7. However you will
be able to extend easily the fields in 1.6 too using the JForm
library.
--
Gergő Erdősi
2009/11/18 Alan Sparkes <in...@joomkit.com>:
Amy Stephen
Nov 18, 2009, 12:35:54 PM11/18/09
to joomla-...@googlegroups.com
Andrew gave a bit of a hint on how Content Extending might work in a response to the Joomla! 1.6 Alpha 2 discussion.
G. D. Speer
Nov 18, 2009, 1:18:08 PM11/18/09
to Joomla! CMS Development
Yes, within module chrome. Pardon me for making a
too vague a reference to the specific portion of the template rendering
process.
----- Original Message -----From: Phil SnellSent: Wednesday, November 18, 2009 9:35 AMSubject: Re: com_modules cleanupbut this should be done in chrome, no?
G. D. Speer wrote:You're right - but IMHO sometimes it's nice to be able to pass a user-selected h-level preference into the template without having several template permutations just to promote or demote the level of heading. (the template doesn't have to honor it, but those that are equipped to do so, can and I suggest core modules have this option exposed for users that are not comfortable with the mechanics of cloning core module templates and adding template selection parameters.) ----- Original Message ----- From: "Niels Braczek" <nbra...@bsds.de> To: <joomla-...@googlegroups.com> Sent: Wednesday, November 18, 2009 8:43 AM Subject: Re: com_modules cleanup G. D. Speer schrieb:Display Name: <h3>Latest News</h3>No! HTML elements belong to the template only, not to the data. Regards, Niels
Alex Kempkens
Nov 18, 2009, 2:46:30 PM11/18/09
to joomla-...@googlegroups.com
A little thing I'm adding for various clients is to replace the current text "various" for the pages column with a tooltip listing the pages selected. At lest the first 5 pages is most often enough.
I would suggest instead of the text "various" show the name of the page if it's only one - if it is more than one show the first one and the tooltip with a bigger list.
The filter for the menu pages is also a great improvement.
Alex
I would suggest instead of the text "various" show the name of the page if it's only one - if it is more than one show the first one and the tooltip with a bigger list.
The filter for the menu pages is also a great improvement.
Alex
David Joly
Nov 18, 2009, 4:00:21 PM11/18/09
to Joomla! CMS Development
To add to Andrea's suggestion on the UI level (and Andrew's
solution) , it would be nice to be able to open all the Parameters
sections at once instead of just one at a time.
Andrew Eddie
Nov 18, 2009, 4:56:23 PM11/18/09
to joomla-...@googlegroups.com
com_content is still getting quite a bit of refurbishing. Nested
categories and the ACL is still a big deal for content and should not
be overlooked. So there are improvements, maybe not as far as people
would like, but those two new features alone are quite big steps and
people are going to learn how to build sites with them. One of the
good things from a training perspective is that 1.5 does lock you into
a certain way of doing things. I know from experience that when you
give people more and more flexibility, they get a little freaked out
because they don't have an immediate compass heading.
Anyway, there will also be ways to extend the basic content object
through form plugins. There is a proof-of-concept example in the user
profile plugin which shows how an edit screen can be hijacked to add
new data. I can't recall if that translates to a "display" more or
not. My head is so in the backend at the moment.
So, all up, we will have generated a new sector for plugin development
with com_content and I hope to see lots of experiments from the
developer community. This is new territory and there are many paths
that can be travelled.
2009/11/19 Alan Sparkes <in...@joomkit.com>:
categories and the ACL is still a big deal for content and should not
be overlooked. So there are improvements, maybe not as far as people
would like, but those two new features alone are quite big steps and
people are going to learn how to build sites with them. One of the
good things from a training perspective is that 1.5 does lock you into
a certain way of doing things. I know from experience that when you
give people more and more flexibility, they get a little freaked out
because they don't have an immediate compass heading.
Anyway, there will also be ways to extend the basic content object
through form plugins. There is a proof-of-concept example in the user
profile plugin which shows how an edit screen can be hijacked to add
new data. I can't recall if that translates to a "display" more or
not. My head is so in the backend at the moment.
So, all up, we will have generated a new sector for plugin development
with com_content and I hope to see lots of experiments from the
developer community. This is new territory and there are many paths
that can be travelled.
2009/11/19 Alan Sparkes <in...@joomkit.com>:
Andrew Eddie
Nov 18, 2009, 5:14:51 PM11/18/09
to joomla-...@googlegroups.com
Peter's new advanced manager plugin allows you to filter on components
as well. I was thinking about that. For me, at the component level,
I tend to want to be able to turn whole module positions off, not just
individual modules. Now you can do that in the template sure, but is
there scope to be able to link positions to component.
as well. I was thinking about that. For me, at the component level,
I tend to want to be able to turn whole module positions off, not just
individual modules. Now you can do that in the template sure, but is
there scope to be able to link positions to component.
Not saying this could fit into 1.6 (you've given me a big list
already, hehe) but would like to hear thoughts on that angle.
Niels Braczek
Nov 18, 2009, 6:02:15 PM11/18/09
to joomla-...@googlegroups.com
G. D. Speer schrieb:
> Yes, within module chrome. Pardon me for making a too vague a reference to the specific portion of the template rendering process.
Isn't Beez doing so?
Pete Jones
Nov 19, 2009, 4:08:47 AM11/19/09
to Joomla! CMS Development
It would be nice to have an option to 'invert' the selected menu items
so that you could do 'all items except this one'. Further down the
line, it would be nice to be able to select this as an option so you
could always prevent a module showing on this menu item, even if more
items are added.
Thanks
Pete Jones
www.jeepstone.co.uk
so that you could do 'all items except this one'. Further down the
line, it would be nice to be able to select this as an option so you
could always prevent a module showing on this menu item, even if more
items are added.
Thanks
Pete Jones
www.jeepstone.co.uk
elin
Nov 19, 2009, 12:39:54 PM11/19/09
to Joomla! CMS Development
It would be nice to be able to set things like display title and a
default suffix globally.
Elin
default suffix globally.
Elin
Andrew Eddie
Nov 19, 2009, 4:12:50 PM11/19/09
to joomla-...@googlegroups.com
Pete, Elin, are you talking about articles (or possibly modules)?
2009/11/20 elin <elin....@gmail.com>:
2009/11/20 elin <elin....@gmail.com>:
elin
Nov 19, 2009, 6:55:04 PM11/19/09
to Joomla! CMS Development
Modules, isn't that what this thread is about? You can't set the
default values for them on things like show title. So even if you
don't show title 90% of the time, you have to manually change it each
and every time. I know probably if you have a highly customized
template this probably doesn't matter so much, but a lot of us do not
have that.
Would be nice to be able to set defaults for the core modules too, but
at least the parameters that are common to all the modules would be a
good start..
Elin
On Nov 19, 4:12 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> Pete, Elin, are you talking about articles (or possibly modules)?
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/11/20 elin <elin.war...@gmail.com>:
default values for them on things like show title. So even if you
don't show title 90% of the time, you have to manually change it each
and every time. I know probably if you have a highly customized
template this probably doesn't matter so much, but a lot of us do not
have that.
Would be nice to be able to set defaults for the core modules too, but
at least the parameters that are common to all the modules would be a
good start..
Elin
On Nov 19, 4:12 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> Pete, Elin, are you talking about articles (or possibly modules)?
>
> Regards,
>
> 2009/11/20 elin <elin.war...@gmail.com>:
Andrew Eddie
Nov 19, 2009, 7:45:51 PM11/19/09
to joomla-...@googlegroups.com
2009/11/20 elin <elin....@gmail.com>:
>
> Modules, isn't that what this thread is about?
>
> Modules, isn't that what this thread is about?
No, Alan was asking about extending com_content. Think Pete Jones put
you on the wrong track ;)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
elin
Nov 19, 2009, 9:18:49 PM11/19/09
to Joomla! CMS Development
Sorry I use the web interface and it still says com_modules cleanup.
Elin
On Nov 19, 7:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/11/20 elin <elin.war...@gmail.com>:
Elin
On Nov 19, 7:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/11/20 elin <elin.war...@gmail.com>:
>
>
>
> > Modules, isn't that what this thread is about?
>
> No, Alan was asking about extending com_content. Think Pete Jones put
> you on the wrong track ;)
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer>
>
> > Modules, isn't that what this thread is about?
>
> No, Alan was asking about extending com_content. Think Pete Jones put
> you on the wrong track ;)
>
> Regards,
Andrew Eddie
Nov 19, 2009, 9:55:26 PM11/19/09
to joomla-...@googlegroups.com
Ok, maybe Gmail has screwed up the threading a bit. Odd.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/20 elin <elin....@gmail.com>:
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/20 elin <elin....@gmail.com>:
Pete Jones
Nov 20, 2009, 6:23:17 AM11/20/09
to Joomla! CMS Development
I was talking about assigning modules to menu items (assuming this is
still com_modules).
It would be nice to be able to 'invert' the selection, or do it
automatically.
Pete
On 20 Nov, 02:55, Andrew Eddie <mambob...@gmail.com> wrote:
> Ok, maybe Gmail has screwed up the threading a bit. Odd.
>
> Regards,
still com_modules).
It would be nice to be able to 'invert' the selection, or do it
automatically.
Pete
On 20 Nov, 02:55, Andrew Eddie <mambob...@gmail.com> wrote:
> Ok, maybe Gmail has screwed up the threading a bit. Odd.
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/11/20 elin <elin.war...@gmail.com>:
>
>
>
>
>
>
> > Sorry I use the web interface and it still says com_modules cleanup.
>
> > Elin
>
> > On Nov 19, 7:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> >> 2009/11/20 elin <elin.war...@gmail.com>:
>
> >> > Modules, isn't that what this thread is about?
>
> >> No, Alan was asking about extending com_content. Think Pete Jones put
> >> you on the wrong track ;)
>
> >> Regards,
> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer>
>
>
>
> > Sorry I use the web interface and it still says com_modules cleanup.
>
> > Elin
>
> > On Nov 19, 7:45 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> >> 2009/11/20 elin <elin.war...@gmail.com>:
>
> >> > Modules, isn't that what this thread is about?
>
> >> No, Alan was asking about extending com_content. Think Pete Jones put
> >> you on the wrong track ;)
>
> >> Regards,
Andrew Eddie
Nov 24, 2009, 5:05:16 AM11/24/09
to joomla-...@googlegroups.com
2009/11/18 Stephen <ma...@clanbrandon.co.uk>:
>
> - the ability for module developers to create arbitrary accordion
> sections. For modules with multiple parameters this could really help
> with grouping and therefore usability.
>
> - the ability for module developers to create arbitrary accordion
> sections. For modules with multiple parameters this could really help
> with grouping and therefore usability.
Done.
> - "assigned to all pages *except*..." option when doing menu
> assignments. (perhaps you have already added this?)
Already done but cleaned up with check box list.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
Andrew Eddie
Nov 24, 2009, 5:14:29 AM11/24/09
to joomla-...@googlegroups.com
2009/11/18 Stephen <ma...@clanbrandon.co.uk>:
>
> - adding start datetime and stop datetime to modules, as for
> components. I already submitted a patch for this months ago - I hope
> now might be the time to resurrect this!
>
> - adding start datetime and stop datetime to modules, as for
> components. I already submitted a patch for this months ago - I hope
> now might be the time to resurrect this!
Stephen, would you like to upgrade the patch to marry with the
refactored extension in the trunk? I'm more than happy to implement
it. You should be able to pinch the date handling in the model and
form xml fields from com_content.
Thanks in advance.
Stephen
Nov 24, 2009, 5:32:32 AM11/24/09
to Joomla! CMS Development
Ugh. This will be the 3rd time I have refactored it, but at least this
time it'll be worth it. I'll work on it.
Just a quick note on one of my other suggestions - I have been talking
to Mr NoNumber.nl about how to make MetaMod Pro and Advanced Modules
play nicely with each other. We're going to work on a plugin
architecture for the module helper class, so that our respective
plugins don't have to directly override the complete class.
When we come up with a good solution for this (just putting in 2 or 3
events within the module helper class), can we submit this to you for
inclusion into 1.6? If it means that fewer plugins try to override a
core class, then everyone wins. There's massive power in being able to
control the module helper class more. (see MetaMod Pro and Advanced
Modules as examples)
To me this is a big deal...
Cheers,
Stephen
On 24 Nov, 23:14, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/11/18 Stephen <m...@clanbrandon.co.uk>:
time it'll be worth it. I'll work on it.
Just a quick note on one of my other suggestions - I have been talking
to Mr NoNumber.nl about how to make MetaMod Pro and Advanced Modules
play nicely with each other. We're going to work on a plugin
architecture for the module helper class, so that our respective
plugins don't have to directly override the complete class.
When we come up with a good solution for this (just putting in 2 or 3
events within the module helper class), can we submit this to you for
inclusion into 1.6? If it means that fewer plugins try to override a
core class, then everyone wins. There's massive power in being able to
control the module helper class more. (see MetaMod Pro and Advanced
Modules as examples)
To me this is a big deal...
Cheers,
Stephen
On 24 Nov, 23:14, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/11/18 Stephen <m...@clanbrandon.co.uk>:
>
>
>
> > - adding start datetime and stop datetime to modules, as for
> > components. I already submitted a patch for this months ago - I hope
> > now might be the time to resurrect this!
>
> Stephen, would you like to upgrade the patch to marry with the
> refactored extension in the trunk? I'm more than happy to implement
> it. You should be able to pinch the date handling in the model and
> form xml fields from com_content.
>
> Thanks in advance.
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer>
>
> > - adding start datetime and stop datetime to modules, as for
> > components. I already submitted a patch for this months ago - I hope
> > now might be the time to resurrect this!
>
> Stephen, would you like to upgrade the patch to marry with the
> refactored extension in the trunk? I'm more than happy to implement
> it. You should be able to pinch the date handling in the model and
> form xml fields from com_content.
>
> Thanks in advance.
>
> Regards,
Andrew Eddie
Nov 24, 2009, 5:36:33 AM11/24/09
to joomla-...@googlegroups.com
Hi Stephen.
Yeah sorry about the rework but it's one of the reasons I really,
really want to have all the code standardised for 1.6 so
patches/changes can be done more rationally for the next version (and
hopefully dramatically reduce the lead cycle time).
I'm really interested in your suggestions for the integration. Maybe
if you can outline the strategy of what you want to do I can help work
out the best way to fit it into the jigsaw puzzle?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/24 Stephen <ma...@clanbrandon.co.uk>:
Yeah sorry about the rework but it's one of the reasons I really,
really want to have all the code standardised for 1.6 so
patches/changes can be done more rationally for the next version (and
hopefully dramatically reduce the lead cycle time).
I'm really interested in your suggestions for the integration. Maybe
if you can outline the strategy of what you want to do I can help work
out the best way to fit it into the jigsaw puzzle?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/24 Stephen <ma...@clanbrandon.co.uk>:
Stephen
Nov 24, 2009, 6:18:19 AM11/24/09
to Joomla! CMS Development
The need for "plugin points" is this:
Advanced Modules and MetaMod Pro are both forced to override the
module helper class in order to get the functionality they provide.
There are currently no plugin points within the class that allow for
external manipulation of the list of modules retrieved from the
database, before they are used for display.
Naturally, this means that they tread on each others toes, which is
why we're talking about how to integrate better, and make a single
override class that we both use in our products. Then we can work to a
common plugin interface and not tread on toes. The aim is also to get
this into the next version of Joomla.
What I am suggesting is making at least 1 new "Event", something like
"onAfterRetrieveModuleList". This would be passed the array of modules
retrieved from the database so that the plugin can manipulate the
list.
I'd also like another event triggered after this one, which does
further post-processing on the list. i.e. MetaMod Pro can do 2 things:
adding (or subtracting) items from the list, and also directly
manipulating module parameters. If MetaMod Pro and Advanced Modules
were both installed, then I would like MetaMod Pro to be able to
dynamically alter parameters of modules included from Advanced
Modules, even if Advanced Modules was after MM Pro in the plugin list.
So the order of operations could be this:
1 - modules retrieved from database as they are now
2 - trigger onAfterRetrieveModuleList. This event would be
specifically for adding or subtracting modules.
3 - via plugins, MetaMod Pro and Advanced Modules both add or subtract
(*) modules from the list. It would not matter what order these are
in.
4 - trigger onPostProcessModuleList. This event would specifically
prohibit ADDING new modules, but could disable them and/or change
parameters.
5 - via plugins, MetaMod Pro (or any other plugin) is able to apply
parameter changes to any of the enabled modules.
6 - there should be a further step in the module helper class at this
point, that checks all the modules in the list to ensure they are all
tagged "enabled". Any that are not enabled should be removed from the
list.
(*) for any modules to be subtracted from the list, they could either
be directly removed, or just tagged as "disabled" so that step 6 does
the actual removal. Any plugin implementing onAfterRetrieveModuleList
or onPostProcessModuleList would need to remember that the array
passed in may contain disabled items.
As described, this *nearly* works for Advanced Modules. Apparently
A.M. has its own version of the modules table which is uses to look up
instead of the standard module table. This is because of the "exclude"
system, whereby you can specify a given menu item and the module gets
put onto every menu item *except* that one. This is done in a separate
table so that the standard modules table doesn't get confused with all
the extra menu items when exclusion is used. (sorry, not a good
explanation but you can ask Peter about it).
So the problem there is that in the case of A.M, you want the ability
to bypass the standard database call that retrieves the module list. I
haven't thought too much about that yet, but perhaps you could raise
another event at that point with the contents of the SQL statement in
it, for manipulation? It's not a great solution and I am sure there's
a better way. Your input is very welcome on that. We've only just
started working on it.
Cheers,
Stephen
On 24 Nov, 23:36, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Stephen.
>
> Yeah sorry about the rework but it's one of the reasons I really,
> really want to have all the code standardised for 1.6 so
> patches/changes can be done more rationally for the next version (and
> hopefully dramatically reduce the lead cycle time).
>
> I'm really interested in your suggestions for the integration. Maybe
> if you can outline the strategy of what you want to do I can help work
> out the best way to fit it into the jigsaw puzzle?
>
> Regards,
> >> Andrew Eddiehttp://www.theartofjoomla.com-the art of becoming a Joomla developer
Advanced Modules and MetaMod Pro are both forced to override the
module helper class in order to get the functionality they provide.
There are currently no plugin points within the class that allow for
external manipulation of the list of modules retrieved from the
database, before they are used for display.
Naturally, this means that they tread on each others toes, which is
why we're talking about how to integrate better, and make a single
override class that we both use in our products. Then we can work to a
common plugin interface and not tread on toes. The aim is also to get
this into the next version of Joomla.
What I am suggesting is making at least 1 new "Event", something like
"onAfterRetrieveModuleList". This would be passed the array of modules
retrieved from the database so that the plugin can manipulate the
list.
I'd also like another event triggered after this one, which does
further post-processing on the list. i.e. MetaMod Pro can do 2 things:
adding (or subtracting) items from the list, and also directly
manipulating module parameters. If MetaMod Pro and Advanced Modules
were both installed, then I would like MetaMod Pro to be able to
dynamically alter parameters of modules included from Advanced
Modules, even if Advanced Modules was after MM Pro in the plugin list.
So the order of operations could be this:
1 - modules retrieved from database as they are now
2 - trigger onAfterRetrieveModuleList. This event would be
specifically for adding or subtracting modules.
3 - via plugins, MetaMod Pro and Advanced Modules both add or subtract
(*) modules from the list. It would not matter what order these are
in.
4 - trigger onPostProcessModuleList. This event would specifically
prohibit ADDING new modules, but could disable them and/or change
parameters.
5 - via plugins, MetaMod Pro (or any other plugin) is able to apply
parameter changes to any of the enabled modules.
6 - there should be a further step in the module helper class at this
point, that checks all the modules in the list to ensure they are all
tagged "enabled". Any that are not enabled should be removed from the
list.
(*) for any modules to be subtracted from the list, they could either
be directly removed, or just tagged as "disabled" so that step 6 does
the actual removal. Any plugin implementing onAfterRetrieveModuleList
or onPostProcessModuleList would need to remember that the array
passed in may contain disabled items.
As described, this *nearly* works for Advanced Modules. Apparently
A.M. has its own version of the modules table which is uses to look up
instead of the standard module table. This is because of the "exclude"
system, whereby you can specify a given menu item and the module gets
put onto every menu item *except* that one. This is done in a separate
table so that the standard modules table doesn't get confused with all
the extra menu items when exclusion is used. (sorry, not a good
explanation but you can ask Peter about it).
So the problem there is that in the case of A.M, you want the ability
to bypass the standard database call that retrieves the module list. I
haven't thought too much about that yet, but perhaps you could raise
another event at that point with the contents of the SQL statement in
it, for manipulation? It's not a great solution and I am sure there's
a better way. Your input is very welcome on that. We've only just
started working on it.
Cheers,
Stephen
On 24 Nov, 23:36, Andrew Eddie <mambob...@gmail.com> wrote:
> Hi Stephen.
>
> Yeah sorry about the rework but it's one of the reasons I really,
> really want to have all the code standardised for 1.6 so
> patches/changes can be done more rationally for the next version (and
> hopefully dramatically reduce the lead cycle time).
>
> I'm really interested in your suggestions for the integration. Maybe
> if you can outline the strategy of what you want to do I can help work
> out the best way to fit it into the jigsaw puzzle?
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/11/24 Stephen <m...@clanbrandon.co.uk>:
>
Andrew Eddie
Nov 24, 2009, 7:03:20 AM11/24/09
to joomla-...@googlegroups.com
Thanks Stephen.
I don't quite get why the onPostProcessModuleList is needed. I would
just let the onAfterRetrieveModuleList (or similar) remove modules.
So I think all you need is the following code before the return in
JModuleHelper::_load
$dispatcher = JDispatcher::getInstance();
// Trigger the onAfterLoadModules event.
$result = $dispatcher->trigger('onAfterLoadModules', array(&$clean));
if (in_array(false, $result, true)) {
// handle error
}
I'm not sure whether error handling is absolutely needed in this case
- possibly not.
I think for the case where you want MetaMod Pro to do some magic on
your "stuff", you just need to tell customers to ensure MetaMod Pro
loads after yours.
Does that sound reasonable?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/24 Stephen <ma...@clanbrandon.co.uk>:
I don't quite get why the onPostProcessModuleList is needed. I would
just let the onAfterRetrieveModuleList (or similar) remove modules.
So I think all you need is the following code before the return in
JModuleHelper::_load
$dispatcher = JDispatcher::getInstance();
// Trigger the onAfterLoadModules event.
$result = $dispatcher->trigger('onAfterLoadModules', array(&$clean));
if (in_array(false, $result, true)) {
// handle error
}
I'm not sure whether error handling is absolutely needed in this case
- possibly not.
I think for the case where you want MetaMod Pro to do some magic on
your "stuff", you just need to tell customers to ensure MetaMod Pro
loads after yours.
Does that sound reasonable?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/24 Stephen <ma...@clanbrandon.co.uk>:
Stephen
Nov 24, 2009, 8:08:01 PM11/24/09
to Joomla! CMS Development
On 25 Nov, 01:03, Andrew Eddie <mambob...@gmail.com> wrote:
> Thanks Stephen.
>
> I don't quite get why the onPostProcessModuleList is needed. I would
> just let the onAfterRetrieveModuleList (or similar) remove modules.
>
> So I think all you need is the following code before the return in
> JModuleHelper::_load
>
> $dispatcher = JDispatcher::getInstance();
>
> // Trigger the onAfterLoadModules event.
> $result = $dispatcher->trigger('onAfterLoadModules', array(&$clean));
> if (in_array(false, $result, true)) {
> // handle error
>
> }
>
> I'm not sure whether error handling is absolutely needed in this case
> - possibly not.
>
> I think for the case where you want MetaMod Pro to do some magic on
> your "stuff", you just need to tell customers to ensure MetaMod Pro
> loads after yours.
>
> Does that sound reasonable?
module adding/subtracting, and module parameter changes which have to
work on a completed list of modules. No, if you have more than one
plugin trying to do both. Also no in terms of usability, if the exact
order of plugins starts to really matter. A certain amount of my
support load is due to ordering issues with plugins.
To me these are 2 separate operations - adding/subtracting from list
of modules, and then any post-processing on a completed list in terms
of parameter changes.
And, it doesn't suit Peter's Advanced Modules, because he does a
completely different lookup on a different table in order to create
the list of modules to start with. He's not simply adding/subtracting
from the existing list.
I suppose he could just decide to ditch the existing list of modules
created by the module helper class, then build his own, but there are
2 problems: (a) there has therefore been a pointless database call,
and (b) it would also ditch any alterations done by any other plugins
before his own.
Are there any patterns applicable to this situation, anywhere else in
Joomla?
ie. Joomla would normally create a list of its own for some purpose.
Joomla gives plugins the chance to override the creation of this list.
Then it gives the opportunity to add or remove items from the list.
Then it gives the opportunity for post-processing list parameters.
I realise this probably sounds like overkill, but we already have 2
successful extensions that are forced to do this sort of thing in an
inelegant way, and clashing with each other.
How much overhead is there in a single plugin event call, if there are
no listeners?
Thanks for taking the time to think about the whole issue, I
appreciate it very much.
Regards,
Stephen
Andrew Eddie
Nov 24, 2009, 8:23:19 PM11/24/09
to joomla-...@googlegroups.com
Well, the other thing I was going to suggest is do an aggregation
pattern (I think that's right) where you can literally override the
JModuleHelper::_load method, but that's really only going to work on
one of the solutions.
I'm just concerned that doing the double trigger just to get around
ordering issues doesn't really solve the problem (which is that the
ordering is important) because no matter how many times you keep
triggering, you still might have ordering problems causing unwanted
reversals.
I saw your tweet. Would be good if Peter can chime in to. I'm happy
to look at finding a resolution. We could even do things like
allowing you to set the plugin order at load time and mutually agree
to respective numbers :)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/25 Stephen <ma...@clanbrandon.co.uk>:
pattern (I think that's right) where you can literally override the
JModuleHelper::_load method, but that's really only going to work on
one of the solutions.
I'm just concerned that doing the double trigger just to get around
ordering issues doesn't really solve the problem (which is that the
ordering is important) because no matter how many times you keep
triggering, you still might have ordering problems causing unwanted
reversals.
I saw your tweet. Would be good if Peter can chime in to. I'm happy
to look at finding a resolution. We could even do things like
allowing you to set the plugin order at load time and mutually agree
to respective numbers :)
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/25 Stephen <ma...@clanbrandon.co.uk>:
Peter van Westen
Nov 25, 2009, 3:44:35 AM11/25/09
to Joomla! CMS Development
Ok, just adding my two cents.
Honestly I haven't thought about this as much as Stephen. And I don't
really foresee the whole pro/cons list for all the listeners.
Anyway, Just to tell you what my Advanced Modules would do:
It has the ability to also filter modules by excluding the selection
of menu items.
It also has a bunch of other filters.
So what Advanced Modules needs to be able to do is go through every
possible module for the module position and see if it should or
shouldn't be visible.
So if you let the core module handler do it's thing first, there will
probably be modules not in the list that should be added.
So I think it is best for Advanced Modules to allow it to run through
the modules list before the core processes it.
That would however mean that joomla would have to change the way it
handles its modules list.
Not the query is made by looking at the module assignment and such.
So here is how I think it could work for me (Stephen can say if that
would also work for him):
- Joomla core collects all the modules that have been assigned to a
specific module category
- This lists gets passed on to the onAfterRetrieveModuleList
- Joomla core does its own filtering of the list based on the menu
assignment
- Joomla core processes each module to get its rendered content
- This list gets passed on to the onAfterProcessModuleList
- Joomla core passes the module list on to the template or whatever it
does next.
onAfterRetrieveModuleList
In this way, there is no need for plugins to add modules to the list.
You theoretically could, but only really necessary if you want to show
modules not assigned to that module position.
The plugins have the possibility to change the settings for each
module here (for instance changing the menu assignment data to prevent
joomla core from filtering it out).
So the idea I have is that you start of with the full module list and
that each plugin (and core at the end) can filter modules out.
Of course, the plugin could do what it wants, as long as it returns a
valid module list.
onAfterProcessModuleList
This can be used to do stuff on the output of the modules.
For instance run content plugins over it or do search and replace
things.
Or remove the module from the list if it has (or hasn't) got certain
content.
Peter
On 25 Nov, 02:23, Andrew Eddie <mambob...@gmail.com> wrote:
> Well, the other thing I was going to suggest is do an aggregation
> pattern (I think that's right) where you can literally override the
> JModuleHelper::_load method, but that's really only going to work on
> one of the solutions.
>
> I'm just concerned that doing the double trigger just to get around
> ordering issues doesn't really solve the problem (which is that the
> ordering is important) because no matter how many times you keep
> triggering, you still might have ordering problems causing unwanted
> reversals.
>
> I saw your tweet. Would be good if Peter can chime in to. I'm happy
> to look at finding a resolution. We could even do things like
> allowing you to set the plugin order at load time and mutually agree
> to respective numbers :)
>
> Regards,
>
> read more »
Honestly I haven't thought about this as much as Stephen. And I don't
really foresee the whole pro/cons list for all the listeners.
Anyway, Just to tell you what my Advanced Modules would do:
It has the ability to also filter modules by excluding the selection
of menu items.
It also has a bunch of other filters.
So what Advanced Modules needs to be able to do is go through every
possible module for the module position and see if it should or
shouldn't be visible.
So if you let the core module handler do it's thing first, there will
probably be modules not in the list that should be added.
So I think it is best for Advanced Modules to allow it to run through
the modules list before the core processes it.
That would however mean that joomla would have to change the way it
handles its modules list.
Not the query is made by looking at the module assignment and such.
So here is how I think it could work for me (Stephen can say if that
would also work for him):
- Joomla core collects all the modules that have been assigned to a
specific module category
- This lists gets passed on to the onAfterRetrieveModuleList
- Joomla core does its own filtering of the list based on the menu
assignment
- Joomla core processes each module to get its rendered content
- This list gets passed on to the onAfterProcessModuleList
- Joomla core passes the module list on to the template or whatever it
does next.
onAfterRetrieveModuleList
In this way, there is no need for plugins to add modules to the list.
You theoretically could, but only really necessary if you want to show
modules not assigned to that module position.
The plugins have the possibility to change the settings for each
module here (for instance changing the menu assignment data to prevent
joomla core from filtering it out).
So the idea I have is that you start of with the full module list and
that each plugin (and core at the end) can filter modules out.
Of course, the plugin could do what it wants, as long as it returns a
valid module list.
onAfterProcessModuleList
This can be used to do stuff on the output of the modules.
For instance run content plugins over it or do search and replace
things.
Or remove the module from the list if it has (or hasn't) got certain
content.
Peter
On 25 Nov, 02:23, Andrew Eddie <mambob...@gmail.com> wrote:
> Well, the other thing I was going to suggest is do an aggregation
> pattern (I think that's right) where you can literally override the
> JModuleHelper::_load method, but that's really only going to work on
> one of the solutions.
>
> I'm just concerned that doing the double trigger just to get around
> ordering issues doesn't really solve the problem (which is that the
> ordering is important) because no matter how many times you keep
> triggering, you still might have ordering problems causing unwanted
> reversals.
>
> I saw your tweet. Would be good if Peter can chime in to. I'm happy
> to look at finding a resolution. We could even do things like
> allowing you to set the plugin order at load time and mutually agree
> to respective numbers :)
>
> Regards,
> Andrew Eddiehttp://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> 2009/11/25 Stephen <m...@clanbrandon.co.uk>:
>
> >> >> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
>
>
> >> >> 2009/11/24 Stephen <m...@clanbrandon.co.uk>:
>
> >> >> > Ugh. This will be the 3rd time I have refactored it, but at least this
> >> >> > time it'll be worth it. I'll work on it.
>
> >> >> > Just a quick note on one of my other suggestions - I have been talking
> >> >> > to Mr NoNumber.nl about how to make MetaMod Pro and Advanced Modules
> >> >> > play nicely with each other. We're going to work on a plugin
> >> >> > architecture for the module helper class, so that our respective
> >> >> > plugins don't have to directly override the complete class.
>
> >> >> > When we come up with a good solution for this (just putting in 2 or 3
> >> >> > events within the module helper class), can we submit this to you for
> >> >> > inclusion into 1.6? If it means that fewer plugins try to override a
> >> >> > core class, then everyone wins. There's massive power in being able to
> >> >> > control the module helper class more. (see MetaMod Pro and Advanced
> >> >> > Modules as examples)
>
> >> >> > To me this is a big deal...
>
> >> >> > Cheers,
> >> >> > Stephen
>
> >> >> > On 24 Nov, 23:14, Andrew Eddie <mambob...@gmail.com> wrote:
> >> >> >> 2009/11/18 Stephen <m...@clanbrandon.co.uk>:
>
> >> >> >> > - adding start datetime and stop datetime to modules, as for
> >> >> >> > components. I already submitted a patch for this months ago - I hope
> >> >> >> > now might be the time to resurrect this!
>
> >> >> >> Stephen, would you like to upgrade the patch to marry with the
> >> >> >> refactored extension in the trunk? I'm
>
> ...
>
> >> >> > Ugh. This will be the 3rd time I have refactored it, but at least this
> >> >> > time it'll be worth it. I'll work on it.
>
> >> >> > Just a quick note on one of my other suggestions - I have been talking
> >> >> > to Mr NoNumber.nl about how to make MetaMod Pro and Advanced Modules
> >> >> > play nicely with each other. We're going to work on a plugin
> >> >> > architecture for the module helper class, so that our respective
> >> >> > plugins don't have to directly override the complete class.
>
> >> >> > When we come up with a good solution for this (just putting in 2 or 3
> >> >> > events within the module helper class), can we submit this to you for
> >> >> > inclusion into 1.6? If it means that fewer plugins try to override a
> >> >> > core class, then everyone wins. There's massive power in being able to
> >> >> > control the module helper class more. (see MetaMod Pro and Advanced
> >> >> > Modules as examples)
>
> >> >> > To me this is a big deal...
>
> >> >> > Cheers,
> >> >> > Stephen
>
> >> >> > On 24 Nov, 23:14, Andrew Eddie <mambob...@gmail.com> wrote:
> >> >> >> 2009/11/18 Stephen <m...@clanbrandon.co.uk>:
>
> >> >> >> > - adding start datetime and stop datetime to modules, as for
> >> >> >> > components. I already submitted a patch for this months ago - I hope
> >> >> >> > now might be the time to resurrect this!
>
> >> >> >> Stephen, would you like to upgrade the patch to marry with the
> >> >> >> refactored extension in the trunk? I'm
>
>
> read more »
Andrew Eddie
Nov 25, 2009, 5:08:30 AM11/25/09
to joomla-...@googlegroups.com
Thanks Peter.
Appreciate the input.
This might be a dumb question but is it possible for you and Stephen
to combine into one work at all?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/25 Peter van Westen <peterva...@gmail.com>:
Appreciate the input.
This might be a dumb question but is it possible for you and Stephen
to combine into one work at all?
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/25 Peter van Westen <peterva...@gmail.com>:
klas berlič
Nov 25, 2009, 5:38:08 AM11/25/09
to joomla-...@googlegroups.com
As this already went from com_modules to modules in general, I'll add my 5 cents here:
Current implementation of module cache works in the same way as component's view cache does and this is appropriate only for the simplest modules that stay the same on all pages, creating problems on all others.
Please look at this discussion about module caching http://groups.google.com/group/joomlabugsquad/browse_thread/thread/b0c7e11406f71347?hl=en-GB#
Proposed solution:
--
------------------------------------------------------------------
http://www.bzzzz.biz - Creating images
Marketing and web communication agency
http://www.belmondo.si - vacation packages,
travel, flight tickets & hotels
------------------------------------------------------------------
Current implementation of module cache works in the same way as component's view cache does and this is appropriate only for the simplest modules that stay the same on all pages, creating problems on all others.
Please look at this discussion about module caching http://groups.google.com/group/joomlabugsquad/browse_thread/thread/b0c7e11406f71347?hl=en-GB#
Proposed solution:
Hidden module_cache_type parameter that would have 3 available options:
a) 1 cache for all model (built in framework)
b) 1 cache for each page models (built in framework)
c) 3rd option that
would fire loading of cacheidhelper.php if module wants to specify it's own
cache model (e.g. new cache file for each content category, itemid etc.).
That way only with modules that need to do something special a little speed
price for loading helper would have to be paid.
2009/11/25 Andrew Eddie <mamb...@gmail.com>
--
------------------------------------------------------------------
http://www.bzzzz.biz - Creating images
Marketing and web communication agency
http://www.belmondo.si - vacation packages,
travel, flight tickets & hotels
------------------------------------------------------------------
Stephen
Nov 25, 2009, 7:18:38 AM11/25/09
to Joomla! CMS Development
Hi Peter,
You wrote:
> (1) Joomla core collects all the modules that have been assigned to a
> specific module category
Module position? Menu assignment? Or just "the complete list"? Or are
there now module categories that I don't know about?
> (2) This lists gets passed on to the onAfterRetrieveModuleList
ok
> (3) Joomla core does its own filtering of the list based on the menu
> assignment
This implies that in (1) you gathered more than just the list of
modules for the current page (menu item). Can you clarify what form
this would be in and what it would contain?
I think that you're trying to make a way to do the Menu Exclusion
thing, but I don't understand the mechanism you're trying to describe.
> (4) Joomla core processes each module to get its rendered content
Pre-rendering of *all* modules? That's a big deal. At the moment IIRC
Joomla does not render a module until it knows that it needs to --
i.e. the module position has been found in the template, the list of
modules for that position is gathered from the overall list, and each
one is rendered.
... It's not unusual for people to assign modules to module positions
that don't necessarily exist on the template. There are a number of
extensions that use this mechanism to group together modules that will
later programatically be included into a component etc. That's the
standard way of doing modules inside VirtueMart pages, for example -
create a module position name, assign a module into it, then put a
module "include" into the template for a particular VM page.
Why is that a problem? Because those modules are probably assigned to
ALL pages but of course will never show up except on those VirtueMart
pages that include that module position.
So if we automatically pre-render all modules, there are going to be
wasted CPU cycles and memory, with potentially other side-effects.
Perhaps this doesn't need to be automatic though - just allow plugins
implementing onAfterProcessModuleList to selectively render if they
want to. e.g. for Peter's purpose of deciding whether to show/hide the
module based on the contents of the rendered module.
For a rule-engine approach, a plugin could do things like "examine
module 55 and if it evaluates to null then show module 56 instead".
But hang on - if I want to include other modules based on the rendered
contents of a module, then I need to be able to pre-render back in
"onAfterRetrieveModuleList".
So I don't think that (4) is particularly necessary. If plugins want/
need to pre-render then they should be given the opportunity to do so
within "onAfterRetrieveModuleList" or "onAfterProcessModuleList".
> (5) This list gets passed on to the onAfterProcessModuleList
I do like having this second plugin, where we assume that the module
list must not grow any more, but can shrink during post-processing. It
means that a plugin that only does post-processing does not have to be
manually ordered after any that manipulate the contents of the list.
e.g. plugin "A" adds some modules to certain pages based on certain
criteria. Plugin "B" dynamically changes a module parameter based on
GeoIP. I don't want to have to tell my users "you have to make sure
that module "B" is always ordered after module "A" in the Plugin
Manager", particularly if a user might install a number of plugins of
type "B" from other 3rd parties which I have no control over.
It's one thing to tweak the exact ordering of modules of type "A"
amongst themselves, but if type "A"s always have to appear before type
"B"s, then let's sort that out inside the class.
> (6) Joomla core passes the module list on to the template or whatever it
> does next.
Yes. Joomla core should remember any of the renderings that have
already taken place so they are not repeated.
Thoughts?
Cheers,
Stephen
On 25 Nov, 21:44, Peter van Westen <petervanwes...@gmail.com> wrote:
> Ok, just adding my two cents.
>
> Honestly I haven't thought about this as much as Stephen. And I don't
> really foresee the whole pro/cons list for all the listeners.
>
> Anyway, Just to tell you what my Advanced Modules would do:
> It has the ability to also filter modules by excluding the selection
> of menu items.
> It also has a bunch of other filters.
>
> So what Advanced Modules needs to be able to do is go through every
> possible module for the module position and see if it should or
> shouldn't be visible.
> So if you let the core module handler do it's thing first, there will
> probably be modules not in the list that should be added.
>
> So I think it is best for Advanced Modules to allow it to run through
> the modules list before the core processes it.
>
> That would however mean that joomla would have to change the way it
> handles its modules list.
> Not the query is made by looking at the module assignment and such.
>
> So here is how I think it could work for me (Stephen can say if that
> would also work for him):
>
> - Joomla core collects all the modules that have been assigned to a
> specific module category
Module position? Menu assignment? Or just "the complete list"? Or are
there now module categories that I don't know about?
> > >> > to bypass the standard database call that...
>
> read more »
You wrote:
> (1) Joomla core collects all the modules that have been assigned to a
> specific module category
Module position? Menu assignment? Or just "the complete list"? Or are
there now module categories that I don't know about?
> (2) This lists gets passed on to the onAfterRetrieveModuleList
ok
> (3) Joomla core does its own filtering of the list based on the menu
> assignment
This implies that in (1) you gathered more than just the list of
modules for the current page (menu item). Can you clarify what form
this would be in and what it would contain?
I think that you're trying to make a way to do the Menu Exclusion
thing, but I don't understand the mechanism you're trying to describe.
> (4) Joomla core processes each module to get its rendered content
Pre-rendering of *all* modules? That's a big deal. At the moment IIRC
Joomla does not render a module until it knows that it needs to --
i.e. the module position has been found in the template, the list of
modules for that position is gathered from the overall list, and each
one is rendered.
... It's not unusual for people to assign modules to module positions
that don't necessarily exist on the template. There are a number of
extensions that use this mechanism to group together modules that will
later programatically be included into a component etc. That's the
standard way of doing modules inside VirtueMart pages, for example -
create a module position name, assign a module into it, then put a
module "include" into the template for a particular VM page.
Why is that a problem? Because those modules are probably assigned to
ALL pages but of course will never show up except on those VirtueMart
pages that include that module position.
So if we automatically pre-render all modules, there are going to be
wasted CPU cycles and memory, with potentially other side-effects.
Perhaps this doesn't need to be automatic though - just allow plugins
implementing onAfterProcessModuleList to selectively render if they
want to. e.g. for Peter's purpose of deciding whether to show/hide the
module based on the contents of the rendered module.
For a rule-engine approach, a plugin could do things like "examine
module 55 and if it evaluates to null then show module 56 instead".
But hang on - if I want to include other modules based on the rendered
contents of a module, then I need to be able to pre-render back in
"onAfterRetrieveModuleList".
So I don't think that (4) is particularly necessary. If plugins want/
need to pre-render then they should be given the opportunity to do so
within "onAfterRetrieveModuleList" or "onAfterProcessModuleList".
> (5) This list gets passed on to the onAfterProcessModuleList
I do like having this second plugin, where we assume that the module
list must not grow any more, but can shrink during post-processing. It
means that a plugin that only does post-processing does not have to be
manually ordered after any that manipulate the contents of the list.
e.g. plugin "A" adds some modules to certain pages based on certain
criteria. Plugin "B" dynamically changes a module parameter based on
GeoIP. I don't want to have to tell my users "you have to make sure
that module "B" is always ordered after module "A" in the Plugin
Manager", particularly if a user might install a number of plugins of
type "B" from other 3rd parties which I have no control over.
It's one thing to tweak the exact ordering of modules of type "A"
amongst themselves, but if type "A"s always have to appear before type
"B"s, then let's sort that out inside the class.
> (6) Joomla core passes the module list on to the template or whatever it
> does next.
Yes. Joomla core should remember any of the renderings that have
already taken place so they are not repeated.
Thoughts?
Cheers,
Stephen
On 25 Nov, 21:44, Peter van Westen <petervanwes...@gmail.com> wrote:
> Ok, just adding my two cents.
>
> Honestly I haven't thought about this as much as Stephen. And I don't
> really foresee the whole pro/cons list for all the listeners.
>
> Anyway, Just to tell you what my Advanced Modules would do:
> It has the ability to also filter modules by excluding the selection
> of menu items.
> It also has a bunch of other filters.
>
> So what Advanced Modules needs to be able to do is go through every
> possible module for the module position and see if it should or
> shouldn't be visible.
> So if you let the core module handler do it's thing first, there will
> probably be modules not in the list that should be added.
>
> So I think it is best for Advanced Modules to allow it to run through
> the modules list before the core processes it.
>
> That would however mean that joomla would have to change the way it
> handles its modules list.
> Not the query is made by looking at the module assignment and such.
>
> So here is how I think it could work for me (Stephen can say if that
> would also work for him):
>
> - Joomla core collects all the modules that have been assigned to a
> specific module category
there now module categories that I don't know about?
> > >> Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
>
> > >> 2009/11/24 Stephen <m...@clanbrandon.co.uk>:
>
>
> > >> 2009/11/24 Stephen <m...@clanbrandon.co.uk>:
>
>
> read more »
Ian MacLennan
Nov 25, 2009, 9:46:14 AM11/25/09
to joomla-...@googlegroups.com
We've had this discussion before.
I think this is a broken way to do it. Modules that need it that don't fit the normal model should handle their own caching rather than trying to build a catchall system that only applies to a few cases.
Ian
I think this is a broken way to do it. Modules that need it that don't fit the normal model should handle their own caching rather than trying to build a catchall system that only applies to a few cases.
Ian
2009/11/25 klas berlič <klas....@gmail.com>
Peter van Westen
Nov 26, 2009, 7:04:31 AM11/26/09
to Joomla! CMS Development
Ok, I'll try to discribe from a non-technical point of view:
- Template tells joomla "ok, I want to place all modules for - say -
position 'left' here.
- Joomla does a db search for all the modules assigned to position
'left'. It might skip all non-published. But should not look at menu
assignment.
- Plugins have the possibility to run through this list and change
modules parameters or through them out or whatever
- Joomla does its core filtering regarding menu assignment
- Joomla renders the output for each of the remaining modules in the
list (per module)
- Plugins get the possibility to do stuff on the list of module
outputs
- Joomla does the final rendering of the complete html (according to
module style) and passes it on to the template
- Template says "thank you".
That's my idea of how it could work and - at least from my point of
view - would give plugins enough room to do what they need.
> ...
>
> read more »
- Template tells joomla "ok, I want to place all modules for - say -
position 'left' here.
- Joomla does a db search for all the modules assigned to position
'left'. It might skip all non-published. But should not look at menu
assignment.
- Plugins have the possibility to run through this list and change
modules parameters or through them out or whatever
- Joomla does its core filtering regarding menu assignment
- Joomla renders the output for each of the remaining modules in the
list (per module)
- Plugins get the possibility to do stuff on the list of module
outputs
- Joomla does the final rendering of the complete html (according to
module style) and passes it on to the template
- Template says "thank you".
That's my idea of how it could work and - at least from my point of
view - would give plugins enough room to do what they need.
> > > Andrew Eddiehttp://www.theartofjoomla.com-theart of becoming a Joomla developer
>
>
>
> read more »
klas berlič
Nov 26, 2009, 9:59:01 AM11/26/09
to joomla-...@googlegroups.com
option a) would do what we have now, b) would be what we had in 1.5.12 (one cache file for each page) and c) option would do just what you are saying - enable module to specify it's own cache model without having to reinvent the wheel any time it is needed.
Probably b) can be left out, but c) would come handy - at the moment any module that doesn't stay the same on all pages has to disable framework module caching and invoke all needed caching methods by it's own - at the end it works the same, but it does not seem to be the right way to have to repeat it for each such module.
Probably b) can be left out, but c) would come handy - at the moment any module that doesn't stay the same on all pages has to disable framework module caching and invoke all needed caching methods by it's own - at the end it works the same, but it does not seem to be the right way to have to repeat it for each such module.
2009/11/25 Ian MacLennan <ian.ma...@joomla.org>
Ian MacLennan
Nov 26, 2009, 10:27:10 AM11/26/09
to joomla-...@googlegroups.com
Only solution c would handle cases where Modules need to load CSS or Javascript or make other API calls that affect page output but aren't directly echoed in the module itself.
Ian
Ian
2009/11/26 klas berlič <klas....@gmail.com>
Stephen
Nov 29, 2009, 10:54:41 PM11/29/09
to Joomla! CMS Development
Ok, that sounds reasonable. Let's work through this a bit more...
At present, _load() in the helper class holds a static array of all
published modules, to provide to the template via &getModules
($position). This means that only 1 database call has to be done, for
the entire page, no matter how many module positions are going to be
used.
At present both Advanced Modules and MetaMod Pro override parts of
_load(), so that the output of _loadModules contains the entire set of
enabled modules for the current menu item, irrespective of module
position. It's up to getModules($position) and getModule
($name,title=null) to filter this by module position or name as
required.
Instead, perhaps we could (a) keep the existing _load() like it is
except for NOT restricting by menu item, then (b) putting in a layer
between getModule/s and _load(), that handles the plugins and
"default" filtering (your [4] below).
My biggest concern is about memory usage. For sites with hundreds of
modules, particularly with large custom html modules, this is going to
load a LOT of stuff from the database, most of which may not be needed
because it relates to different pages. This is a memory hog.
<thinking-aloud>Ideally, shouldn't we be trying to determine which
modules to load as closely as possible before doing a database lookup?
Mmm, this is a catch-22, isn't it. You don't know what modules to load
because the instructions about whether or not they should display are
held in the database. So ideally we would want the parameters to be
database-searchable, so that the sql query itself could query on
modules that are to be displayed on a specific content category, for
example.</thinking-aloud>
Optimisation suggestion: we could reduce that memory usage at the cost
of 1 extra database call, but splitting into 2 queries:
1 - Do as Peter suggests, but don't retrieve the "content" of the
modules (as used by mod_custom). This should provide enough data (e.g.
module parameters) to make decisions about inclusion and exclusion.
2 - For any mod_custom modules a second query is done like: select id,
content from #__modules where id in (list of module ids here), and the
results of this are merged in with the main array.
Here's my amended version though it's still not perfect:
1. Template tells joomla "ok, I want to place all modules for - say -
position 'left' here via getModules("left")
2. getModules($position) calls _filteredList() instead of _load(),
then returns only the ones in the specified position.
3. _filteredList() calls _load() which is almost identical to the
current _load(), except that it does not restrict by menu item.
4. In _filteredList(), plugins have the possibility to run through
this list and change modules parameters or throw them out or whatever
5. In _filteredList(), Joomla does its core filtering regarding menu
assignment
6. _filteredList would use a static variable to cache the results. The
static caching in _load() could be removed.
7. Back in getModules($position), the list is filtered by the
requested module position
8. Joomla renders the output for each of the remaining modules in the
list (per module). This would reside in getModules($position).
8b. Plugins get the possibility to do stuff on the list of module
outputs
8c. Any modules set to "disabled" after 8b get removed from the list
9. List of modules (with the pre-rendering if that has been done) gets
passed back, and the rest of the system works as it does in 1.5. We
would need to ensure that modules are not re-rendered.
Issues with this:
- in (8), is it right to do the rendering here? Why can't it wait
until the module is rendered wherever this is done in 1.5? Plugins can
still be run over the output; doesn't matter where this is done.
The main advantage I can think of for doing it here is that a plugin
would be able to "turn off" a module depending on its rendered state.
- The main thing I want to avoid is pre-rendering if the module wasn't
going to end up on the page regardless. If we can ensure that modules
rendered here are definitely going to end up on the page, or that the
pre-rendering is necessary to determine whether they should or not,
then here *would* be a good place.
That's why I moved the pre-rendering back up into getModules
($position), so that only modules in positions that have been
requested by the template for display or calculation (e.g. countModules
()) get pre-rendered.
- this scheme still uses only a single plugin point to allow plugins
to add/remove from the list, and to manipulate parameters. I still
think that these should be 2 distinct plugins, because parameter
manipulation should operate on a final list if at all possible. I
don't want to have to have to create screencasts demonstrating to
people how to move the MetaModPro plugin to the end of the list, and
the Advanced Modules one to the start of the list, for example. And if
there is more than one plugin that does *both* tasks, then one of them
is always going to be prevented from doing parameter manipulation on
the full list. The (8b) plugin can't be used for parameter
manipulation because it's post-render.
- how is the menu-item-exclusion done in the current version of 1.6?
How would that fit into the above scheme?
Finally, I think that this is starting to become workable. There are
still some issues with performance (selecting all enabled modules from
the database whether or not they will appear on this particular page),
but that's probably inevitable based on the nature of what we're
trying to do.
Peter? Andrew?
Cheers,
Stephen
> > > > Andrew Eddiehttp://www.theartofjoomla.com-theartof becoming a Joomla developer
>
> read more »
At present, _load() in the helper class holds a static array of all
published modules, to provide to the template via &getModules
($position). This means that only 1 database call has to be done, for
the entire page, no matter how many module positions are going to be
used.
At present both Advanced Modules and MetaMod Pro override parts of
_load(), so that the output of _loadModules contains the entire set of
enabled modules for the current menu item, irrespective of module
position. It's up to getModules($position) and getModule
($name,title=null) to filter this by module position or name as
required.
Instead, perhaps we could (a) keep the existing _load() like it is
except for NOT restricting by menu item, then (b) putting in a layer
between getModule/s and _load(), that handles the plugins and
"default" filtering (your [4] below).
My biggest concern is about memory usage. For sites with hundreds of
modules, particularly with large custom html modules, this is going to
load a LOT of stuff from the database, most of which may not be needed
because it relates to different pages. This is a memory hog.
<thinking-aloud>Ideally, shouldn't we be trying to determine which
modules to load as closely as possible before doing a database lookup?
Mmm, this is a catch-22, isn't it. You don't know what modules to load
because the instructions about whether or not they should display are
held in the database. So ideally we would want the parameters to be
database-searchable, so that the sql query itself could query on
modules that are to be displayed on a specific content category, for
example.</thinking-aloud>
Optimisation suggestion: we could reduce that memory usage at the cost
of 1 extra database call, but splitting into 2 queries:
1 - Do as Peter suggests, but don't retrieve the "content" of the
modules (as used by mod_custom). This should provide enough data (e.g.
module parameters) to make decisions about inclusion and exclusion.
2 - For any mod_custom modules a second query is done like: select id,
content from #__modules where id in (list of module ids here), and the
results of this are merged in with the main array.
Here's my amended version though it's still not perfect:
1. Template tells joomla "ok, I want to place all modules for - say -
position 'left' here via getModules("left")
2. getModules($position) calls _filteredList() instead of _load(),
then returns only the ones in the specified position.
3. _filteredList() calls _load() which is almost identical to the
current _load(), except that it does not restrict by menu item.
4. In _filteredList(), plugins have the possibility to run through
this list and change modules parameters or throw them out or whatever
5. In _filteredList(), Joomla does its core filtering regarding menu
assignment
6. _filteredList would use a static variable to cache the results. The
static caching in _load() could be removed.
7. Back in getModules($position), the list is filtered by the
requested module position
8. Joomla renders the output for each of the remaining modules in the
list (per module). This would reside in getModules($position).
8b. Plugins get the possibility to do stuff on the list of module
outputs
8c. Any modules set to "disabled" after 8b get removed from the list
9. List of modules (with the pre-rendering if that has been done) gets
passed back, and the rest of the system works as it does in 1.5. We
would need to ensure that modules are not re-rendered.
Issues with this:
- in (8), is it right to do the rendering here? Why can't it wait
until the module is rendered wherever this is done in 1.5? Plugins can
still be run over the output; doesn't matter where this is done.
The main advantage I can think of for doing it here is that a plugin
would be able to "turn off" a module depending on its rendered state.
- The main thing I want to avoid is pre-rendering if the module wasn't
going to end up on the page regardless. If we can ensure that modules
rendered here are definitely going to end up on the page, or that the
pre-rendering is necessary to determine whether they should or not,
then here *would* be a good place.
That's why I moved the pre-rendering back up into getModules
($position), so that only modules in positions that have been
requested by the template for display or calculation (e.g. countModules
()) get pre-rendered.
- this scheme still uses only a single plugin point to allow plugins
to add/remove from the list, and to manipulate parameters. I still
think that these should be 2 distinct plugins, because parameter
manipulation should operate on a final list if at all possible. I
don't want to have to have to create screencasts demonstrating to
people how to move the MetaModPro plugin to the end of the list, and
the Advanced Modules one to the start of the list, for example. And if
there is more than one plugin that does *both* tasks, then one of them
is always going to be prevented from doing parameter manipulation on
the full list. The (8b) plugin can't be used for parameter
manipulation because it's post-render.
- how is the menu-item-exclusion done in the current version of 1.6?
How would that fit into the above scheme?
Finally, I think that this is starting to become workable. There are
still some issues with performance (selecting all enabled modules from
the database whether or not they will appear on this particular page),
but that's probably inevitable based on the nature of what we're
trying to do.
Peter? Andrew?
Cheers,
Stephen
>
> > > > 2009/11/25 Stephen <m...@clanbrandon.co.uk>:
>
> > > > > On 25 Nov, 01:03, Andrew Eddie <mambob...@gmail.com> wrote:
> > > > >> Thanks Stephen.
>
> > > > >> I don't quite get why the onPostProcessModuleList is needed. I would
> > > > >> just let the onAfterRetrieveModuleList (or similar) remove modules.
>
> > > > >> So I think all you need is the following code before the return in
> > > > >> JModuleHelper::_load
>
> > > > >> $dispatcher = JDispatcher::getInstance();
>
> > > > >> // Trigger the onAfterLoadModules event.
> > > > >> $result = $dispatcher->trigger('onAfterLoadModules', array(&$clean));
> > > > >> if (in_array(false, $result, true)) {
> > > > >> // handle error
>
> > > > >> }
>
> > > > >> I'm not sure whether error handling is absolutely needed in this case
> > > > >> - possibly not.
>
> > > > >> I think for the case where you want MetaMod Pro to do some magic on
> > > > >> your "stuff", you just need to tell customers to ensure MetaMod Pro
> > > > >> loads after yours.
>
> > > > >> Does that sound reasonable?
>
> > > > > Yes and no. Yes, if there's only 1 plugin doing a combination of
> > > > > module adding/subtracting, and module...
> > > > 2009/11/25 Stephen <m...@clanbrandon.co.uk>:
>
> > > > > On 25 Nov, 01:03, Andrew Eddie <mambob...@gmail.com> wrote:
> > > > >> Thanks Stephen.
>
> > > > >> I don't quite get why the onPostProcessModuleList is needed. I would
> > > > >> just let the onAfterRetrieveModuleList (or similar) remove modules.
>
> > > > >> So I think all you need is the following code before the return in
> > > > >> JModuleHelper::_load
>
> > > > >> $dispatcher = JDispatcher::getInstance();
>
> > > > >> // Trigger the onAfterLoadModules event.
> > > > >> $result = $dispatcher->trigger('onAfterLoadModules', array(&$clean));
> > > > >> if (in_array(false, $result, true)) {
> > > > >> // handle error
>
> > > > >> }
>
> > > > >> I'm not sure whether error handling is absolutely needed in this case
> > > > >> - possibly not.
>
> > > > >> I think for the case where you want MetaMod Pro to do some magic on
> > > > >> your "stuff", you just need to tell customers to ensure MetaMod Pro
> > > > >> loads after yours.
>
> > > > >> Does that sound reasonable?
>
> > > > > Yes and no. Yes, if there's only 1 plugin doing a combination of
>
> read more »
Reply all
Reply to author
Forward
0 new messages