I'm thinking about hiring a trusted developer (it's beyond my capabilities) to propose a feature patch for a more powerful overriding system (in addition to what we have now). I wanted to first to run my idea by you in case it wasn't worth pursuing.
Joomla has a lot of great override abilities (template overrides, alternative layout overrides, etc), however why don't we create an override folder where admins can insert files with the same same paths to override the originals? The platform would just have to process those files first. If an override is found, there's no need to process the file being overridden.
For example, if you wanted to override the following file (to change the Type attribute): /libraries/joomla/document/html/renderer/head.php
You could just upload the override to: overrides/libraries/joomla/document/html/renderer/head.php
without having to resort to all sorts of elaborate hacks.
It's a very simple concept and I think it would be relatively easy to implement (for a capable developer). This wouldn't replace any of our current override capabilities, but just add an additional way to override. The current capabilities, although great, have limitations that this method would help resolve and would allow us to basically override almost every file easily.
I have just that, but a bit more sophisticated: I *extend *the class I want to override after giving the "old" class another name and extending from that class. In that way I can for instance easily override a single method and even still use the old (parent) method. I use it regularly to extend-override classes, not only from the platform, but even more often from 3PD-extensions. I now use it looking where the file is located in my override-folder, but planned to make an administrative interface with it too, so you can also override a class in the /administrator-folder if you want to use that in the site-side of the CMS. For at the moment you must look out not to override a class in the frontend if you use the same class in the backend (and the other way around).
I simply use the "not a hack hack" plugin method as described in the Joomla! Programming Book page 182-185. But as I said: I read the "old" class, change the classname, include that old class with the new name, and then load the "overriden" class with the old name (extended from the old clas with new name). Works like a charm.
Word of warning: there are extensions that use this system-plugin method too and that could give conflicts: who is the first one to be loaded. That is also why you sometimes see plugins with an ordering of say -30000 (lowest numbers go first). There even seem to be agreements between some 3PD's who gets first... So just look out if those plugins are doing the same trick with the same classes as you want to override, for that won't work (class can only be loaded once).
My thought is: if I just put it on the JED, you can use it as you want; but it is not necessary a core feature. Probably only a few developers who want to use this (and they could allready use the plugin-trick). BTW: in PrestaShop (an open source e-commerce application) every class can be overridden in your theme. That works nice (but not as good as my *extended override*, hehe).
On Wednesday, 15 August 2012 20:54:57 UTC+2, Nick Savov wrote:
> Hi everyone,
> I'm thinking about hiring a trusted developer (it's beyond my > capabilities) to propose a feature patch for a more powerful overriding > system (in addition to what we have now). I wanted to first to run my idea > by you in case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides, > alternative layout overrides, etc), however why don't we create an override > folder where admins can insert files with the same same paths to override > the originals? The platform would just have to process those files first. > If an override is found, there's no need to process the file being > overridden.
> For example, if you wanted to override the following file (to change the > Type attribute): > /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to: > overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to > implement (for a capable developer). This wouldn't replace any of our > current override capabilities, but just add an additional way to override. > The current capabilities, although great, have limitations that this > method would help resolve and would allow us to basically override almost > every file easily.
Here is the way I change the classname (will change JFile into native PHP):
// read the old class-deninition file $oldfile = JFile::read($oldfile_path); // change the classname $oldfile = str_replace($classname, $classname.'_overridebase', $oldfile);
Before, I did an eval() on $oldfile (after removing <?php from the beginning), but now I write the changed file in a cache-subfolder of my overrides-folder and include_once that modified file. In that way I also have a cache for the old files (which has to be cleaned up if the old file is updated. Still working on automating that; thought on an onAfterUpdate-plugin).
Having a standard approach to override any file -- without loading a system
plugin -- would be ideal. One consideration for future releases is
preparing for namespaces. That's something that adds a level of difficulty
to overrides that we have yet to encounter with Joomla.
On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren <herman.pee...@gmail.com>wrote:
> Before, I did an eval() on $oldfile (after removing <?php from the
> beginning), but now I write the changed file in a cache-subfolder of my
> overrides-folder and include_once that modified file. In that way I also
> have a cache for the old files (which has to be cleaned up if the old file
> is updated. Still working on automating that; thought on an
> onAfterUpdate-plugin).
I would think that the autoloader opens up some possibilities for
creating simple overrides. For example, how hard would it be to load a
custom autoloader in place of the standard one? In that case, you
could have that one look first to an override folder. If that works,
perhaps make the standard autoloader look first to an override folder?
Just thinking out loud. Mark
On Wed, Aug 15, 2012 at 5:29 PM, Amy Stephen <amystep...@gmail.com> wrote:
> I've seen others do that eval approach. Interesting how many ways people
> have devised to come up with overrides for Joomla.
> Having a standard approach to override any file -- without loading a system
> plugin -- would be ideal. One consideration for future releases is preparing
> for namespaces. That's something that adds a level of difficulty to
> overrides that we have yet to encounter with Joomla.
> On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren <herman.pee...@gmail.com>
> wrote:
>> Here is the way I change the classname (will change JFile into native
>> PHP):
>> // read the old class-deninition file
>> $oldfile = JFile::read($oldfile_path);
>> // change the classname
>> $oldfile = str_replace($classname,
>> $classname.'_overridebase', $oldfile);
>> Before, I did an eval() on $oldfile (after removing <?php from the
>> beginning), but now I write the changed file in a cache-subfolder of my
>> overrides-folder and include_once that modified file. In that way I also
>> have a cache for the old files (which has to be cleaned up if the old file
>> is updated. Still working on automating that; thought on an
>> onAfterUpdate-plugin).
There is no need to load another autoloader in place of the standard ones. Autoloaders cascade. It is simply a matter of loading another path for the J prefix and those paths will be searched first.
Here are some trivial solutions to the problem, if all you want to do is load alternative class definitions: 1. Write a system plugin that calls JLoader::registerPrefix to register a new path for the 'J' prefix. (2.5+) 2. Call spl_autoload_register to register a new autoloader to load classes. If you use the prepend option it will use the autoloader you specify first which will take precedence over the system one. (2.5+) 3. Write a system plugin that loads class definitions for the class you want to override (1.5+ - most classes, 2.5 probably all classes) 4. The CMS could choose to load a specific path as an alternative prefix in future versions (i.e. do option 1 out of the box). You can also reference http://community.joomla.org/blogs/community/521-did-you-know-override... for a discussion on this topic for Joomla 1.5, which for the most part also applies to Joomla 2.5.
On Wednesday, 15 August 2012 20:32:15 UTC-4, Mark Dexter wrote:
> I would think that the autoloader opens up some possibilities for > creating simple overrides. For example, how hard would it be to load a > custom autoloader in place of the standard one? In that case, you > could have that one look first to an override folder. If that works, > perhaps make the standard autoloader look first to an override folder? > Just thinking out loud. Mark
> On Wed, Aug 15, 2012 at 5:29 PM, Amy Stephen <amyst...@gmail.com<javascript:>> > wrote: > > I've seen others do that eval approach. Interesting how many ways people > > have devised to come up with overrides for Joomla.
> > Having a standard approach to override any file -- without loading a > system > > plugin -- would be ideal. One consideration for future releases is > preparing > > for namespaces. That's something that adds a level of difficulty to > > overrides that we have yet to encounter with Joomla.
> > On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren <herman...@gmail.com<javascript:>>
> > wrote:
> >> Here is the way I change the classname (will change JFile into native > >> PHP):
> >> // read the old class-deninition file > >> $oldfile = JFile::read($oldfile_path); > >> // change the classname > >> $oldfile = str_replace($classname, > >> $classname.'_overridebase', $oldfile);
> >> Before, I did an eval() on $oldfile (after removing <?php from the > >> beginning), but now I write the changed file in a cache-subfolder of my > >> overrides-folder and include_once that modified file. In that way I > also > >> have a cache for the old files (which has to be cleaned up if the old > file > >> is updated. Still working on automating that; thought on an > >> onAfterUpdate-plugin).
> There is no need to load another autoloader in place of the standard ones.
> Autoloaders cascade. It is simply a matter of loading another path for
> the J prefix and those paths will be searched first.
> Here are some trivial solutions to the problem, if all you want to do is
> load alternative class definitions:
> 1. Write a system plugin that calls JLoader::registerPrefix to register a
> new path for the 'J' prefix. (2.5+)
> 2. Call spl_autoload_register to register a new autoloader to load classes.
> If you use the prepend option it will use the autoloader you specify first
> which will take precedence over the system one. (2.5+)
> 3. Write a system plugin that loads class definitions for the class you
> want to override (1.5+ - most classes, 2.5 probably all classes)
> 4. The CMS could choose to load a specific path as an alternative prefix in
> future versions (i.e. do option 1 out of the box).
> You can also referencehttp://community.joomla.org/blogs/community/521-did-you-know-override... > a discussion on this topic for Joomla 1.5, which for the most part also
> applies to Joomla 2.5.
> Ian
> On Wednesday, 15 August 2012 20:32:15 UTC-4, Mark Dexter wrote:
> > I would think that the autoloader opens up some possibilities for
> > creating simple overrides. For example, how hard would it be to load a
> > custom autoloader in place of the standard one? In that case, you
> > could have that one look first to an override folder. If that works,
> > perhaps make the standard autoloader look first to an override folder?
> > Just thinking out loud. Mark
> > On Wed, Aug 15, 2012 at 5:29 PM, Amy Stephen <amyst...@gmail.com<javascript:>>
> > wrote:
> > > I've seen others do that eval approach. Interesting how many ways people
> > > have devised to come up with overrides for Joomla.
> > > Having a standard approach to override any file -- without loading a
> > system
> > > plugin -- would be ideal. One consideration for future releases is
> > preparing
> > > for namespaces. That's something that adds a level of difficulty to
> > > overrides that we have yet to encounter with Joomla.
> > > On Wed, Aug 15, 2012 at 3:08 PM, Herman Peeren <herman...@gmail.com<javascript:>>
> > > wrote:
> > >> Here is the way I change the classname (will change JFile into native
> > >> PHP):
> > >> Before, I did an eval() on $oldfile (after removing <?php from the
> > >> beginning), but now I write the changed file in a cache-subfolder of my
> > >> overrides-folder and include_once that modified file. In that way I
> > also
> > >> have a cache for the old files (which has to be cleaned up if the old
> > file
> > >> is updated. Still working on automating that; thought on an
> > >> onAfterUpdate-plugin).
> > >> You bet I had fun playing around with this!
Overriding a class by adding an auto-loader for it is a rather interesting hack....but remains imho a hack. Unless it's the "official" way to override in Joomla... ?
When ever you override something you always run the risk that either
a) someone else will want to override it or b) you will override it in
a way that is incompatible with someone else. There isn't an official
way in that sense because each time something is 'overridden' it's
unmanageable in a sense without further co-ordination.
What I'd suggest is that we look around and work out where we can put
in plugin hooks to make things more dynamic through this mechanism and
enable us to more predictably behave and change behaviours in an
extensible way.
On Fri, Aug 17, 2012 at 1:43 AM, Beat <beat...@gmail.com> wrote:
> Overriding a class by adding an auto-loader for it is a rather interesting
> hack....but remains imho a hack.
> Unless it's the "official" way to override in Joomla... ?
> On Friday, August 17, 2012 2:01:00 AM UTC+2, piotr_cz wrote:
>> There's a note in the Platform (12.1+) manual that might be helpful
>> with an example
>> Example 1.5. Using JLoader::registerPrefix (http://
>> developer.joomla.org/manual/ch01s04.html#idp10406856)
>> ...A developer can register a force override for a prefix. This could
>> be used to completely override the core classes with a custom
>> replacement.
There are a couple of PR's submitted in the last month that provide better
predictable extendability that Sam is correctly calling for. Would be good
for maintainers to consider these -- at least to buy a little time until
better architecture is put in place. Or, if it's not a direction
maintainers are considered, comments on why it's not a good fit could help
build a common vision.
On Fri, Aug 17, 2012 at 5:26 PM, Sam Moffatt <pasa...@gmail.com> wrote:
> When ever you override something you always run the risk that either
> a) someone else will want to override it or b) you will override it in
> a way that is incompatible with someone else. There isn't an official
> way in that sense because each time something is 'overridden' it's
> unmanageable in a sense without further co-ordination.
> What I'd suggest is that we look around and work out where we can put
> in plugin hooks to make things more dynamic through this mechanism and
> enable us to more predictably behave and change behaviours in an
> extensible way.
> On Fri, Aug 17, 2012 at 1:43 AM, Beat <beat...@gmail.com> wrote:
> > Overriding a class by adding an auto-loader for it is a rather
> interesting
> > hack....but remains imho a hack.
> > Unless it's the "official" way to override in Joomla... ?
> > On Friday, August 17, 2012 2:01:00 AM UTC+2, piotr_cz wrote:
> >> There's a note in the Platform (12.1+) manual that might be helpful
> >> with an example
> >> Example 1.5. Using JLoader::registerPrefix (http://
> >> developer.joomla.org/manual/ch01s04.html#idp10406856)
> >> ...A developer can register a force override for a prefix. This could
> >> be used to completely override the core classes with a custom
> >> replacement.
I think Nick talks about an automatic override system without requiring plugins. The best override system that I've tested is in Magento. It's exactly as Nick describes. Default code is at:
*app/code/core*
and overrides are at:
*app/code/local*
You can just copy a file from core folder to local and then edit/customize it. You don't need Classes have the same name in both.
Prestashop also uses the same override system. An override folder where you can copy/edit core files with the same folder structure.
El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
> I'm thinking about hiring a trusted developer (it's beyond my > capabilities) to propose a feature patch for a more powerful overriding > system (in addition to what we have now). I wanted to first to run my idea > by you in case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides, > alternative layout overrides, etc), however why don't we create an override > folder where admins can insert files with the same same paths to override > the originals? The platform would just have to process those files first. > If an override is found, there's no need to process the file being > overridden.
> For example, if you wanted to override the following file (to change the > Type attribute):
> /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to:
> overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to > implement (for a capable developer). This wouldn't replace any of our > current override capabilities, but just add an additional way to override. > The current capabilities, although great, have limitations that this > method would help resolve and would allow us to basically override almost > every file easily.
> Kind regards,
> Nick
El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
> I'm thinking about hiring a trusted developer (it's beyond my > capabilities) to propose a feature patch for a more powerful overriding > system (in addition to what we have now). I wanted to first to run my idea > by you in case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides, > alternative layout overrides, etc), however why don't we create an override > folder where admins can insert files with the same same paths to override > the originals? The platform would just have to process those files first. > If an override is found, there's no need to process the file being > overridden.
> For example, if you wanted to override the following file (to change the > Type attribute):
> /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to:
> overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to > implement (for a capable developer). This wouldn't replace any of our > current override capabilities, but just add an additional way to override. > The current capabilities, although great, have limitations that this > method would help resolve and would allow us to basically override almost > every file easily.
> Kind regards,
> Nick
El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
> I'm thinking about hiring a trusted developer (it's beyond my > capabilities) to propose a feature patch for a more powerful overriding > system (in addition to what we have now). I wanted to first to run my idea > by you in case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides, > alternative layout overrides, etc), however why don't we create an override > folder where admins can insert files with the same same paths to override > the originals? The platform would just have to process those files first. > If an override is found, there's no need to process the file being > overridden.
> For example, if you wanted to override the following file (to change the > Type attribute):
> /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to:
> overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to > implement (for a capable developer). This wouldn't replace any of our > current override capabilities, but just add an additional way to override. > The current capabilities, although great, have limitations that this > method would help resolve and would allow us to basically override almost > every file easily.
> Kind regards,
> Nick
El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
> I'm thinking about hiring a trusted developer (it's beyond my > capabilities) to propose a feature patch for a more powerful overriding > system (in addition to what we have now). I wanted to first to run my idea > by you in case it wasn't worth pursuing.
> Joomla has a lot of great override abilities (template overrides, > alternative layout overrides, etc), however why don't we create an override > folder where admins can insert files with the same same paths to override > the originals? The platform would just have to process those files first. > If an override is found, there's no need to process the file being > overridden.
> For example, if you wanted to override the following file (to change the > Type attribute):
> /libraries/joomla/document/html/renderer/head.php
> You could just upload the override to:
> overrides/libraries/joomla/document/html/renderer/head.php
> without having to resort to all sorts of elaborate hacks.
> It's a very simple concept and I think it would be relatively easy to > implement (for a capable developer). This wouldn't replace any of our > current override capabilities, but just add an additional way to override. > The current capabilities, although great, have limitations that this > method would help resolve and would allow us to basically override almost > every file easily.
The problem is that Magento has a different user profile than what
Joomla! does. While that may work well for Magento which is a much
more targeted application with a much more limited extension
ecosystem. It is also aimed at a much more high end market, I don't
think Joomla! has any extensions that cost $25k yet[1]. The
fundamental problem is what happens when more than one extension
wishes to override the same file.
On Fri, Aug 17, 2012 at 4:31 PM, Roberto Segura <robe...@phproberto.com> wrote:
> I think Nick talks about an automatic override system without requiring
> plugins. The best override system that I've tested is in Magento. It's
> exactly as Nick describes. Default code is at:
> app/code/core
> and overrides are at:
> app/code/local
> You can just copy a file from core folder to local and then edit/customize
> it. You don't need Classes have the same name in both.
> Prestashop also uses the same override system. An override folder where you
> can copy/edit core files with the same folder structure.
> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>> Hi everyone,
>> I'm thinking about hiring a trusted developer (it's beyond my
>> capabilities) to propose a feature patch for a more powerful overriding
>> system (in addition to what we have now). I wanted to first to run my idea
>> by you in case it wasn't worth pursuing.
>> Joomla has a lot of great override abilities (template overrides,
>> alternative layout overrides, etc), however why don't we create an override
>> folder where admins can insert files with the same same paths to override
>> the originals? The platform would just have to process those files first.
>> If an override is found, there's no need to process the file being
>> overridden.
>> For example, if you wanted to override the following file (to change the
>> Type attribute):
>> /libraries/joomla/document/html/renderer/head.php
>> You could just upload the override to:
>> overrides/libraries/joomla/document/html/renderer/head.php
>> without having to resort to all sorts of elaborate hacks.
>> It's a very simple concept and I think it would be relatively easy to
>> implement (for a capable developer). This wouldn't replace any of our
>> current override capabilities, but just add an additional way to override.
>> The current capabilities, although great, have limitations that this method
>> would help resolve and would allow us to basically override almost every
>> file easily.
>> Kind regards,
>> Nick
> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>> Hi everyone,
>> I'm thinking about hiring a trusted developer (it's beyond my
>> capabilities) to propose a feature patch for a more powerful overriding
>> system (in addition to what we have now). I wanted to first to run my idea
>> by you in case it wasn't worth pursuing.
>> Joomla has a lot of great override abilities (template overrides,
>> alternative layout overrides, etc), however why don't we create an override
>> folder where admins can insert files with the same same paths to override
>> the originals? The platform would just have to process those files first.
>> If an override is found, there's no need to process the file being
>> overridden.
>> For example, if you wanted to override the following file (to change the
>> Type attribute):
>> /libraries/joomla/document/html/renderer/head.php
>> You could just upload the override to:
>> overrides/libraries/joomla/document/html/renderer/head.php
>> without having to resort to all sorts of elaborate hacks.
>> It's a very simple concept and I think it would be relatively easy to
>> implement (for a capable developer). This wouldn't replace any of our
>> current override capabilities, but just add an additional way to override.
>> The current capabilities, although great, have limitations that this method
>> would help resolve and would allow us to basically override almost every
>> file easily.
>> Kind regards,
>> Nick
> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>> Hi everyone,
>> I'm thinking about hiring a trusted developer (it's beyond my
>> capabilities) to propose a feature patch for a more powerful overriding
>> system (in addition to what we have now). I wanted to first to run my idea
>> by you in case it wasn't worth pursuing.
>> Joomla has a lot of great override abilities (template overrides,
>> alternative layout overrides, etc), however why don't we create an override
>> folder where admins can insert files with the same same paths to override
>> the originals? The platform would just have to process those files first.
>> If an override is found, there's no need to process the file being
>> overridden.
>> For example, if you wanted to override the following file (to change the
>> Type attribute):
>> /libraries/joomla/document/html/renderer/head.php
>> You could just upload the override to:
>> overrides/libraries/joomla/document/html/renderer/head.php
>> without having to resort to all sorts of elaborate hacks.
>> It's a very simple concept and I think it would be relatively easy to
>> implement (for a capable developer). This wouldn't replace any of our
>> current override capabilities, but just add an additional way to override.
>> The current capabilities, although great, have limitations that this method
>> would help resolve and would allow us to basically override almost every
>> file easily.
>> Kind regards,
>> Nick
> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>> Hi everyone,
>> I'm thinking about hiring a trusted developer (it's beyond my
>> capabilities) to propose a feature patch for a more powerful overriding
>> system (in addition to what we have now). I wanted to first to run my idea
>> by you in case it wasn't worth pursuing.
>> Joomla has a lot of great override abilities (template overrides,
>> alternative layout overrides, etc), however why don't we create an override
>> folder where admins can insert files with the same same paths to override
>> the originals? The platform would just have to process those files first.
>> If an override is found, there's no need to process the file being
>> overridden.
>> For example, if you wanted to override the following file (to change the
>> Type attribute):
>> /libraries/joomla/document/html/renderer/head.php
>> You could just upload the override to:
>> overrides/libraries/joomla/document/html/renderer/head.php
>> without having to resort to all sorts of elaborate hacks.
>> It's a very simple concept and I think it would be relatively easy to
>> implement (for a capable developer). This wouldn't replace any of our
>> current override capabilities, but just add an additional way to override.
>> The current capabilities, although great, have limitations that this method
>> would help resolve and would allow us to basically override almost every
>> file easily.
> Overriding a class by adding an auto-loader for it is a rather interesting
> hack....but remains imho a hack.
> Unless it's the "official" way to override in Joomla... ?
>> ...A developer can register a force override for a prefix. This could
>> be used to completely override the core classes with a custom
>> replacement.
Roberto's right. My suggestion is an automatic override system without
requiring plugins. To override, simply copy the file over to the right
directory and then modify to your liking :) This makes it very simple for
even novice developers to override practically everything in their Joomla
site if desired.
It's the responsibility of the developer of the site to make sure their
overrides don't break anything (as it is now with layout overrides and
alternative overrides).
In the same way, extensions shouldn't hack overridden core files. So in my
opinion, namespacing is not an issue.
I'm happy to take suggestions on how to implement namespacing in the
project, however even without it, at the very least, we'd have a more
powerful, flexible, and easy to use override system than we have now (plus
we'd keep the older methods). We could even easily implement alternative
overrides which are fully independent of the template, unlike now.
To top it all off, for those that want to still use plugins on their own
sites to override classes (or whatever they are using them for now), they
theoretically still could. Furthermore, we can create plugin events for
before and after overriding to make it easier, if needed, for those that
want to do fancier things.
So does anyone see any problems with this approach?
Based on the comments so far, this looks like it could be realistically
done (especially learning that Magento has already done a similar approach
and that developers like it).
> The problem is that Magento has a different user profile than what
> Joomla! does. While that may work well for Magento which is a much
> more targeted application with a much more limited extension
> ecosystem. It is also aimed at a much more high end market, I don't
> think Joomla! has any extensions that cost $25k yet[1]. The
> fundamental problem is what happens when more than one extension
> wishes to override the same file.
> On Fri, Aug 17, 2012 at 4:31 PM, Roberto Segura <robe...@phproberto.com>
> wrote:
>> I think Nick talks about an automatic override system without requiring
>> plugins. The best override system that I've tested is in Magento. It's
>> exactly as Nick describes. Default code is at:
>> app/code/core
>> and overrides are at:
>> app/code/local
>> You can just copy a file from core folder to local and then
>> edit/customize
>> it. You don't need Classes have the same name in both.
>> Prestashop also uses the same override system. An override folder where
>> you
>> can copy/edit core files with the same folder structure.
>> El mi rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi :
>>> Hi everyone,
>>> I'm thinking about hiring a trusted developer (it's beyond my
>>> capabilities) to propose a feature patch for a more powerful overriding
>>> system (in addition to what we have now). I wanted to first to run my
>>> idea
>>> by you in case it wasn't worth pursuing.
>>> Joomla has a lot of great override abilities (template overrides,
>>> alternative layout overrides, etc), however why don't we create an
>>> override
>>> folder where admins can insert files with the same same paths to
>>> override
>>> the originals? The platform would just have to process those files
>>> first.
>>> If an override is found, there's no need to process the file being
>>> overridden.
>>> For example, if you wanted to override the following file (to change
>>> the
>>> Type attribute):
>>> /libraries/joomla/document/html/renderer/head.php
>>> You could just upload the override to:
>>> overrides/libraries/joomla/document/html/renderer/head.php
>>> without having to resort to all sorts of elaborate hacks.
>>> It's a very simple concept and I think it would be relatively easy to
>>> implement (for a capable developer). This wouldn't replace any of our
>>> current override capabilities, but just add an additional way to
>>> override.
>>> The current capabilities, although great, have limitations that this
>>> method
>>> would help resolve and would allow us to basically override almost
>>> every
>>> file easily.
>>> Kind regards,
>>> Nick
>> El mi rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi :
>>> Hi everyone,
>>> I'm thinking about hiring a trusted developer (it's beyond my
>>> capabilities) to propose a feature patch for a more powerful overriding
>>> system (in addition to what we have now). I wanted to first to run my
>>> idea
>>> by you in case it wasn't worth pursuing.
>>> Joomla has a lot of great override abilities (template overrides,
>>> alternative layout overrides, etc), however why don't we create an
>>> override
>>> folder where admins can insert files with the same same paths to
>>> override
>>> the originals? The platform would just have to process those files
>>> first.
>>> If an override is found, there's no need to process the file being
>>> overridden.
>>> For example, if you wanted to override the following file (to change
>>> the
>>> Type attribute):
>>> /libraries/joomla/document/html/renderer/head.php
>>> You could just upload the override to:
>>> overrides/libraries/joomla/document/html/renderer/head.php
>>> without having to resort to all sorts of elaborate hacks.
>>> It's a very simple concept and I think it would be relatively easy to
>>> implement (for a capable developer). This wouldn't replace any of our
>>> current override capabilities, but just add an additional way to
>>> override.
>>> The current capabilities, although great, have limitations that this
>>> method
>>> would help resolve and would allow us to basically override almost
>>> every
>>> file easily.
>>> Kind regards,
>>> Nick
>> El mi rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi :
>>> Hi everyone,
>>> I'm thinking about hiring a trusted developer (it's beyond my
>>> capabilities) to propose a feature patch for a more powerful overriding
>>> system (in addition to what we have now). I wanted to first to run my
>>> idea
>>> by you in case it wasn't worth pursuing.
>>> Joomla has a lot of great override abilities (template overrides,
>>> alternative layout overrides, etc), however why don't we create an
>>> override
>>> folder where admins can insert files with the same same paths to
>>> override
>>> the originals? The platform would just have to process those files
>>> first.
>>> If an override is found, there's no need to process the file being
>>> overridden.
>>> For example, if you wanted to override the following file (to change
>>> the
>>> Type attribute):
>>> /libraries/joomla/document/html/renderer/head.php
>>> You could just upload the override to:
>>> overrides/libraries/joomla/document/html/renderer/head.php
>>> without having to resort to all sorts of elaborate hacks.
>>> It's a very simple concept and I think it would be relatively easy to
>>> implement (for a capable developer). This wouldn't replace any of our
>>> current override capabilities, but just add an additional way to
>>> override.
>>> The current capabilities, although great, have limitations that this
>>> method
>>> would help resolve and would allow us to basically override almost
>>> every
>>> file easily.
>>> Kind regards,
>>> Nick
>> El mi rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi :
>>> Hi everyone,
>>> I'm thinking about hiring a trusted developer (it's beyond my
>>> capabilities) to propose a feature patch for a more powerful overriding
>>> system (in addition to what we have now). I wanted to first to run my
>>> idea
>>> by you in case it wasn't worth pursuing.
>>> Joomla has a lot of great override abilities (template overrides,
>>> alternative layout overrides, etc), however why don't we create an
>>> override
>>> folder where admins can insert files with the same same paths to
>>> override
>>> the originals? The platform would just have to process those files
>>> first.
>>> If an override is found, there's no need to process the file being
>>> overridden.
>>> For example, if you wanted to override the following file (to change
>>> the
>>> Type attribute):
>>> /libraries/joomla/document/html/renderer/head.php
>>> You could just upload the override to:
>>> overrides/libraries/joomla/document/html/renderer/head.php
>>> without having to resort to all sorts of elaborate hacks.
>>> It's a very simple concept and I think it would be relatively easy to
>>> implement (for a capable developer). This wouldn't replace any of our
>>> current override capabilities, but just add an additional way to
>>> override.
>>> The current capabilities, although great, have limitations that this
>>> method
>>> would help resolve and would allow us to basically override almost
>>> every
>>> file easily.
My only concern is the performance impact. In some profiling I did we already spend on simple requests (e.g. admin login) up to 20% of the time in the autoloader. For each folder we add for a given prefix we raise the number of calls to the file_system which are probably the slowest part of the autoloading (I didn't look into it that deeply).
That's not a deal breaker but I want to make sure people know that these things come with a cost even if not used.
Last but not least, why are we discussing this on jplatform? This seems like an application feature to me.
Best regards
Rouven
On 19.08.2012, at 00:41, "Nick Savov" <n...@iowawebcompany.com> wrote:
> Roberto's right. My suggestion is an automatic override system without
> requiring plugins. To override, simply copy the file over to the right
> directory and then modify to your liking :) This makes it very simple for
> even novice developers to override practically everything in their Joomla
> site if desired.
> It's the responsibility of the developer of the site to make sure their
> overrides don't break anything (as it is now with layout overrides and
> alternative overrides).
> In the same way, extensions shouldn't hack overridden core files. So in my
> opinion, namespacing is not an issue.
> I'm happy to take suggestions on how to implement namespacing in the
> project, however even without it, at the very least, we'd have a more
> powerful, flexible, and easy to use override system than we have now (plus
> we'd keep the older methods). We could even easily implement alternative
> overrides which are fully independent of the template, unlike now.
> To top it all off, for those that want to still use plugins on their own
> sites to override classes (or whatever they are using them for now), they
> theoretically still could. Furthermore, we can create plugin events for
> before and after overriding to make it easier, if needed, for those that
> want to do fancier things.
> So does anyone see any problems with this approach?
> Based on the comments so far, this looks like it could be realistically
> done (especially learning that Magento has already done a similar approach
> and that developers like it).
> Kind regards,
> Nick
>> The problem is that Magento has a different user profile than what
>> Joomla! does. While that may work well for Magento which is a much
>> more targeted application with a much more limited extension
>> ecosystem. It is also aimed at a much more high end market, I don't
>> think Joomla! has any extensions that cost $25k yet[1]. The
>> fundamental problem is what happens when more than one extension
>> wishes to override the same file.
>> On Fri, Aug 17, 2012 at 4:31 PM, Roberto Segura <robe...@phproberto.com>
>> wrote:
>>> I think Nick talks about an automatic override system without requiring
>>> plugins. The best override system that I've tested is in Magento. It's
>>> exactly as Nick describes. Default code is at:
>>> app/code/core
>>> and overrides are at:
>>> app/code/local
>>> You can just copy a file from core folder to local and then
>>> edit/customize
>>> it. You don't need Classes have the same name in both.
>>> Prestashop also uses the same override system. An override folder where
>>> you
>>> can copy/edit core files with the same folder structure.
>>> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>>>> Hi everyone,
>>>> I'm thinking about hiring a trusted developer (it's beyond my
>>>> capabilities) to propose a feature patch for a more powerful overriding
>>>> system (in addition to what we have now). I wanted to first to run my
>>>> idea
>>>> by you in case it wasn't worth pursuing.
>>>> Joomla has a lot of great override abilities (template overrides,
>>>> alternative layout overrides, etc), however why don't we create an
>>>> override
>>>> folder where admins can insert files with the same same paths to
>>>> override
>>>> the originals? The platform would just have to process those files
>>>> first.
>>>> If an override is found, there's no need to process the file being
>>>> overridden.
>>>> For example, if you wanted to override the following file (to change
>>>> the
>>>> Type attribute):
>>>> /libraries/joomla/document/html/renderer/head.php
>>>> You could just upload the override to:
>>>> overrides/libraries/joomla/document/html/renderer/head.php
>>>> without having to resort to all sorts of elaborate hacks.
>>>> It's a very simple concept and I think it would be relatively easy to
>>>> implement (for a capable developer). This wouldn't replace any of our
>>>> current override capabilities, but just add an additional way to
>>>> override.
>>>> The current capabilities, although great, have limitations that this
>>>> method
>>>> would help resolve and would allow us to basically override almost
>>>> every
>>>> file easily.
>>>> Kind regards,
>>>> Nick
>>> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>>>> Hi everyone,
>>>> I'm thinking about hiring a trusted developer (it's beyond my
>>>> capabilities) to propose a feature patch for a more powerful overriding
>>>> system (in addition to what we have now). I wanted to first to run my
>>>> idea
>>>> by you in case it wasn't worth pursuing.
>>>> Joomla has a lot of great override abilities (template overrides,
>>>> alternative layout overrides, etc), however why don't we create an
>>>> override
>>>> folder where admins can insert files with the same same paths to
>>>> override
>>>> the originals? The platform would just have to process those files
>>>> first.
>>>> If an override is found, there's no need to process the file being
>>>> overridden.
>>>> For example, if you wanted to override the following file (to change
>>>> the
>>>> Type attribute):
>>>> /libraries/joomla/document/html/renderer/head.php
>>>> You could just upload the override to:
>>>> overrides/libraries/joomla/document/html/renderer/head.php
>>>> without having to resort to all sorts of elaborate hacks.
>>>> It's a very simple concept and I think it would be relatively easy to
>>>> implement (for a capable developer). This wouldn't replace any of our
>>>> current override capabilities, but just add an additional way to
>>>> override.
>>>> The current capabilities, although great, have limitations that this
>>>> method
>>>> would help resolve and would allow us to basically override almost
>>>> every
>>>> file easily.
>>>> Kind regards,
>>>> Nick
>>> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>>>> Hi everyone,
>>>> I'm thinking about hiring a trusted developer (it's beyond my
>>>> capabilities) to propose a feature patch for a more powerful overriding
>>>> system (in addition to what we have now). I wanted to first to run my
>>>> idea
>>>> by you in case it wasn't worth pursuing.
>>>> Joomla has a lot of great override abilities (template overrides,
>>>> alternative layout overrides, etc), however why don't we create an
>>>> override
>>>> folder where admins can insert files with the same same paths to
>>>> override
>>>> the originals? The platform would just have to process those files
>>>> first.
>>>> If an override is found, there's no need to process the file being
>>>> overridden.
>>>> For example, if you wanted to override the following file (to change
>>>> the
>>>> Type attribute):
>>>> /libraries/joomla/document/html/renderer/head.php
>>>> You could just upload the override to:
>>>> overrides/libraries/joomla/document/html/renderer/head.php
>>>> without having to resort to all sorts of elaborate hacks.
>>>> It's a very simple concept and I think it would be relatively easy to
>>>> implement (for a capable developer). This wouldn't replace any of our
>>>> current override capabilities, but just add an additional way to
>>>> override.
>>>> The current capabilities, although great, have limitations that this
>>>> method
>>>> would help resolve and would allow us to basically override almost
>>>> every
>>>> file easily.
>>>> Kind regards,
>>>> Nick
>>> El miércoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribió:
>>>> Hi everyone,
>>>> I'm thinking about hiring a trusted developer (it's beyond my
>>>> capabilities) to propose a feature patch for a more powerful overriding
>>>> system (in addition to what we have now). I wanted to first to run my
>>>> idea
>>>> by you in case it wasn't worth pursuing.
>>>> Joomla has a lot of great override abilities (template overrides,
>>>> alternative layout overrides, etc), however why don't we create an
>>>> override
>>>> folder where admins can insert files with the same same paths to
>>>> override
>>>> the originals? The platform would just have to process those files
>>>> first.
>>>> If an override is found, there's no need to process the file being
>>>> overridden.
>>>> For example, if you wanted to override the following file (to change
>>>> the
>>>> Type attribute):
>>>> /libraries/joomla/document/html/renderer/head.php
>>>> You could just upload the override to:
>>>> overrides/libraries/joomla/document/html/renderer/head.php
It's part of the emerging PSR standard set that Andrew sits on for the J!
project. In fact, it's PSR-0, and it is fundamental to class loading and
touted as a vehicle for sharing components between projects.
http://phpmaster.com/autoloading-and-the-psr-0-standard/
Now, that's not to say I am hoping to discourage you from moving forward. I
am in favor of easier ways to override classes and have found others to
also view this as an "advanced developer" activity. I completely agree with
your point that it's the responsibility of the site builder to ensure all
software functions together. Making it easy to override core classes would
be good, IMO.
My point is just that the solution you design could be impacted by the
introduction of namespacing in Joomla and planning accordingly could extend
the life of your work.
Rouven - can't think of anything more platform than this but I do agree
that the performance impact should be a consideration.
On 19.08.2012, at 01:01, Amy Stephen <amystep...@gmail.com> wrote:
> Now, that's not to say I am hoping to discourage you from moving forward. I am in favor of easier ways to override classes and have found others to also view this as an "advanced developer" activity. I completely agree with your point that it's the responsibility of the site builder to ensure all software functions together. Making it easy to override core classes would be good, IMO.
I agree it needs to be possible to override classes for specific needs. But lets hope it stays a last resort option and we also follow Sam but making the existing classes more flexible.
> Rouven - can't think of anything more platform than this but I do agree that the performance impact should be a consideration.
My gut feeling is that this desire is very CMS specific. Since it most likely won't apply to all applications so it should be opt-in from a platform POV. There's nothing specific to do, all the code necessary exists in the platform, we're talking about adding a single line of code here. So I see the decision "do this or don't do this" as a CMS matter.
Magento is known for its low performance. In fact you need a customized server if you want an acceptable pageload. I have no data about it but as I said Prestashop uses the same override system and has a great pageload.
The Nick approach seems compatible to me with making classes more extendable as Sam suggests. We can even use a parameter to enable/disable the override system. If you require it and want to lose some performance you can do it.
Obviously extensions should not modify/use the overrides folder.
For templates/views the workflow can be as:
1.- template folder has a view override? use it 2-. override has a view override? use it 3.- no view overrides? use the default extension view
This will allow us to share views in all the templates but still allow us to customize each view per template.
On 19.08.2012, at 02:32, Roberto Segura <robe...@phproberto.com> wrote:
> Magento is known for its low performance. In fact you need a customized server if you want an acceptable pageload. I have no data about it but as I said Prestashop uses the same override system and has a great pageload.
Just to be clear, this won't have such a big impact that performance is suddenly gonna go notably down. In fact it's probably mostly relevant on simpler requests where time isn't as critical.
> The Nick approach seems compatible to me with making classes more extendable as Sam suggests.
I wasn't talking about software compatibility but mindshare. Overriding a class should always be a last resort, ideally we have classes that are flexible enough for 99% of uses.
> Obviously extensions should not modify/use the overrides folder.
> For templates/views the workflow can be as:
Do you mean views or layouts? You won't be able to override layouts with the proposed method.
I think this discussion has gotten into the philosophy of overrides, rather
than trying to solve the problem of providing a simple means of overriding
core classes.
There are a lot of different ways of looking at whether class overrides are
a good thing or not, and certainly there could be a debate on whether or
not the existing classes meet, or should meet, 99% of the need, but maybe
that isn't a very worthwhile discussion. While it's clear Magento appears
to have an "override what you want" attitude (and they must therefore feel
the flexibility is worth the possible problems in interoperability), in all
honesty, I don't understand what the Joomla platform team's philosophy is
on this but I do believe it would be helpful if that point of view were
more clear.
Meanwhile, maybe Rouven is right that Nick might be trying to solve real
(or perceived) problems with the CMS. Understanding the specific problems
or areas where functionality is lacking or flexibility is challenging could
help clarify where this discussion should take place.
On Sat, Aug 18, 2012 at 9:31 PM, Rouven Weßling <m...@rouvenwessling.de>wrote:
> On 19.08.2012, at 02:32, Roberto Segura <robe...@phproberto.com> wrote:
> > Magento is known for its low performance. In fact you need a customized
> server if you want an acceptable pageload. I have no data about it but as I
> said Prestashop uses the same override system and has a great pageload.
> Just to be clear, this won't have such a big impact that performance is
> suddenly gonna go notably down. In fact it's probably mostly relevant on
> simpler requests where time isn't as critical.
> > The Nick approach seems compatible to me with making classes more
> extendable as Sam suggests.
> I wasn't talking about software compatibility but mindshare. Overriding a
> class should always be a last resort, ideally we have classes that are
> flexible enough for 99% of uses.
> > Obviously extensions should not modify/use the overrides folder.
> > For templates/views the workflow can be as:
> Do you mean views or layouts? You won't be able to override layouts with
> the proposed method.
The way the naming conventions are now, I doubt that we'll ever be
able to comply with PSR-0 (not the end of the world); but that's a
conversation for another day.
And I agree with Rouven. While this conversation is interesting, it's
all application level stuff and there's not really anything the
platform needs to do. Anyone can override classes with an auto-loader
strategy (it does not get much simpler than that). One is provided by
the platform but you don't have it use it if you have something else
in mind. And even if you do use JLoader, you can override what the
platform set up for you (I do when required).
There are a number of valid use cases for overrides:
1) Testing slight changes to core classes that you need for a
production system and hope to contribute back.
An example of this would be to override JViewHtml to accept a
different extension for layouts.
2) Applying essentially "hacks" that you need for a bespoke system
where you just need to brute force a class into behaving the way you
want.
An example of this would be to add custom logging to the MySQLi driver
(that would be considered over-the-top ordinarily) to help diagnose
particular quirks in your application; or to provide extra diagnostics
for something like Zend Server.
Whether overrides are "good" or "bad" is neither here nor there (and
it also depends on if you are the owner of the application or not).
Auto-loading, as well as a number of other standard PHP features,
allows you to do it in the platform should it suit your needs to do
so. The responsibility of making it work rests with the application.
When that application allows you to interact with other applications
is where the fun begins (for example, the Joomla CMS having extensions
that could completely override everything), but that's out of our
hands as platform developers. As Sam indicates, you are to blame if
you upset compatibility within the community of users using the
application.
In terms of "view" overrides, that, again, is really a discussion for
the application (presumably the CMS). The new JViewHtml adds a
priority queue that would easily add "common" areas, but the
application has to apply that logic.
> It's part of the emerging PSR standard set that Andrew sits on for the J!
> project. In fact, it's PSR-0, and it is fundamental to class loading and
> touted as a vehicle for sharing components between projects.
> http://phpmaster.com/autoloading-and-the-psr-0-standard/
> Now, that's not to say I am hoping to discourage you from moving forward. I
> am in favor of easier ways to override classes and have found others to also
> view this as an "advanced developer" activity. I completely agree with your
> point that it's the responsibility of the site builder to ensure all
> software functions together. Making it easy to override core classes would
> be good, IMO.
> My point is just that the solution you design could be impacted by the
> introduction of namespacing in Joomla and planning accordingly could extend
> the life of your work.
> Rouven - can't think of anything more platform than this but I do agree that
> the performance impact should be a consideration.
I'm here to share my plugin idea.
I've implemented few methods on core classes and override.
The idea is implement methods to add include paths for modules, and
component parts.
We have a center class that you registry code pools(folders where you will
be able to override code).
Features:
- Override Controllers, Models, Views, Helpers from components.
Ps.: Helpers are overrided if components use $this->loadHelper() function.
- You can create new views/override from 3rd components (front and backend).
Ps.: views in frontend are added in menus
- You can override modules mod_name.php to change some logic as you wish
On Sun, Aug 19, 2012 at 8:13 AM, Andrew Eddie <mambob...@gmail.com> wrote:
> The way the naming conventions are now, I doubt that we'll ever be
> able to comply with PSR-0 (not the end of the world); but that's a
> conversation for another day.
> And I agree with Rouven. While this conversation is interesting, it's
> all application level stuff and there's not really anything the
> platform needs to do. Anyone can override classes with an auto-loader
> strategy (it does not get much simpler than that). One is provided by
> the platform but you don't have it use it if you have something else
> in mind. And even if you do use JLoader, you can override what the
> platform set up for you (I do when required).
> There are a number of valid use cases for overrides:
> 1) Testing slight changes to core classes that you need for a
> production system and hope to contribute back.
> An example of this would be to override JViewHtml to accept a
> different extension for layouts.
> 2) Applying essentially "hacks" that you need for a bespoke system
> where you just need to brute force a class into behaving the way you
> want.
> An example of this would be to add custom logging to the MySQLi driver
> (that would be considered over-the-top ordinarily) to help diagnose
> particular quirks in your application; or to provide extra diagnostics
> for something like Zend Server.
> Whether overrides are "good" or "bad" is neither here nor there (and
> it also depends on if you are the owner of the application or not).
> Auto-loading, as well as a number of other standard PHP features,
> allows you to do it in the platform should it suit your needs to do
> so. The responsibility of making it work rests with the application.
> When that application allows you to interact with other applications
> is where the fun begins (for example, the Joomla CMS having extensions
> that could completely override everything), but that's out of our
> hands as platform developers. As Sam indicates, you are to blame if
> you upset compatibility within the community of users using the
> application.
> In terms of "view" overrides, that, again, is really a discussion for
> the application (presumably the CMS). The new JViewHtml adds a
> priority queue that would easily add "common" areas, but the
> application has to apply that logic.
> On 19 August 2012 09:01, Amy Stephen <amystep...@gmail.com> wrote:
> > Namespacing is coming -- not sure when, but it's been on the roadmap and
> > many are clamoring for it.
> > https://github.com/joomla/joomla-platform/wiki/Roadmap
> > It's part of the emerging PSR standard set that Andrew sits on for the J!
> > project. In fact, it's PSR-0, and it is fundamental to class loading and
> > touted as a vehicle for sharing components between projects.
> > http://phpmaster.com/autoloading-and-the-psr-0-standard/
> > Now, that's not to say I am hoping to discourage you from moving
> forward. I
> > am in favor of easier ways to override classes and have found others to
> also
> > view this as an "advanced developer" activity. I completely agree with
> your
> > point that it's the responsibility of the site builder to ensure all
> > software functions together. Making it easy to override core classes
> would
> > be good, IMO.
> > My point is just that the solution you design could be impacted by the
> > introduction of namespacing in Joomla and planning accordingly could
> extend
> > the life of your work.
> > Rouven - can't think of anything more platform than this but I do agree
> that
> > the performance impact should be a consideration.
On Sunday, August 19, 2012 7:13:28 AM UTC-4, Andrew Eddie wrote:
> The way the naming conventions are now, I doubt that we'll ever be > able to comply with PSR-0 (not the end of the world); but that's a > conversation for another day.
> And I agree with Rouven. While this conversation is interesting, it's > all application level stuff and there's not really anything the > platform needs to do. Anyone can override classes with an auto-loader > strategy (it does not get much simpler than that). One is provided by > the platform but you don't have it use it if you have something else > in mind. And even if you do use JLoader, you can override what the > platform set up for you (I do when required).
> There are a number of valid use cases for overrides:
> 1) Testing slight changes to core classes that you need for a > production system and hope to contribute back.
> An example of this would be to override JViewHtml to accept a > different extension for layouts.
> 2) Applying essentially "hacks" that you need for a bespoke system > where you just need to brute force a class into behaving the way you > want.
> An example of this would be to add custom logging to the MySQLi driver > (that would be considered over-the-top ordinarily) to help diagnose > particular quirks in your application; or to provide extra diagnostics > for something like Zend Server.
> Whether overrides are "good" or "bad" is neither here nor there (and > it also depends on if you are the owner of the application or not). > Auto-loading, as well as a number of other standard PHP features, > allows you to do it in the platform should it suit your needs to do > so. The responsibility of making it work rests with the application. > When that application allows you to interact with other applications > is where the fun begins (for example, the Joomla CMS having extensions > that could completely override everything), but that's out of our > hands as platform developers. As Sam indicates, you are to blame if > you upset compatibility within the community of users using the > application.
> In terms of "view" overrides, that, again, is really a discussion for > the application (presumably the CMS). The new JViewHtml adds a > priority queue that would easily add "common" areas, but the > application has to apply that logic.
> On 19 August 2012 09:01, Amy Stephen <amyst...@gmail.com <javascript:>> > wrote: > > Namespacing is coming -- not sure when, but it's been on the roadmap and > > many are clamoring for it. > > https://github.com/joomla/joomla-platform/wiki/Roadmap
> > It's part of the emerging PSR standard set that Andrew sits on for the > J! > > project. In fact, it's PSR-0, and it is fundamental to class loading and > > touted as a vehicle for sharing components between projects. > > http://phpmaster.com/autoloading-and-the-psr-0-standard/
> > Now, that's not to say I am hoping to discourage you from moving > forward. I > > am in favor of easier ways to override classes and have found others to > also > > view this as an "advanced developer" activity. I completely agree with > your > > point that it's the responsibility of the site builder to ensure all > > software functions together. Making it easy to override core classes > would > > be good, IMO.
> > My point is just that the solution you design could be impacted by the > > introduction of namespacing in Joomla and planning accordingly could > extend > > the life of your work.
> > Rouven - can't think of anything more platform than this but I do agree > that > > the performance impact should be a consideration.
On Sun, Aug 19, 2012 at 6:13 AM, Andrew Eddie <mambob...@gmail.com> wrote:
> The way the naming conventions are now, I doubt that we'll ever be
> able to comply with PSR-0 (not the end of the world); but that's a
> conversation for another day.
When Joomla get to namespaces, I'll be interested in this discussion as I
do use Joomla framework with other project components.
> And I agree with Rouven. While this conversation is interesting, it's
> all application level stuff and there's not really anything the
> platform needs to do. Anyone can override classes with an auto-loader
> strategy (it does not get much simpler than that). One is provided by
> the platform but you don't have it use it if you have something else
> in mind. And even if you do use JLoader, you can override what the
> platform set up for you (I do when required).
