Better Overriding

[Nick Savov]

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

[Herman Peeren]

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

[Herman Peeren]

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

You bet I had fun playing around with this!

[Amy Stephen]

I've seen others do that eval approach. Interesting how many ways people have devised to come up with overrides for Joomla.

I have an example plugin that covers various options for overriding core classes http://joomlacode.org/gf/project/joomla_16_ex/frs/

Also, an example of how to override the View at runtime https://github.com/AmyStephen/Layout-Override-Plugin

Julio Pontes has documented on the Wiki approaches for overriding different parts of the MVC http://docs.joomla.org/How_to_override_the_component_mvc_from_the_Joomla!_core

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.

[Mark Dexter]

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

[Ian]

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-overrides-are-not-just-for-html.html for a discussion on this topic for Joomla 1.5, which for the most part also applies to Joomla 2.5.

Ian

[piotr_cz]

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.

On Aug 16, 3:38 am, Ian <ianlen...@gmail.com> wrote:
> 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...for

> 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.
>
> > > I have an example plugin that covers various options for overriding core

> > > classeshttp://joomlacode.org/gf/project/joomla_16_ex/frs/

>
> > > Also, an example of how to override the View at runtime
> > >https://github.com/AmyStephen/Layout-Override-Plugin
>
> > > Julio Pontes has documented on the Wiki approaches for overriding
> > different
> > > parts of the MVC
>

> >http://docs.joomla.org/How_to_override_the_component_mvc_from_the_Joo...

>
> > > 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:>>

[Beat]

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

Beat

http://www.joomlapolis.com/.

[Sam Moffatt]

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.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

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.

• https://github.com/joomla/joomla-platform/pull/1420
• https://github.com/joomla/joomla-platform/pull/1408

Might be good when we see PR's like this to get them posted so that they get attention from the Platform team.

[Sam Moffatt]

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.

Cheers,

Sam Moffatt
http://pasamio.id.au

[1] http://www.magentocommerce.com/magento-connect/catalogsearch/result/?id=&s=3&pl=0&te=0&xc=0&q=&t=0&p=1

On Fri, Aug 17, 2012 at 4:31 PM, Roberto Segura <rob...@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.

[Amy Stephen]

The bigger problem with Magento's approach is that it won't work with namespacing.  Wonder what they'll do when they cross that bridge?

[Andrew Eddie]

It's not a hack Beat. That's been designed deliberately and IS the official way to override classes. I doubt you'll find a more elegant way to do it. 

Regards

Andre Eddie 

--
Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Nick Savov]

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

As to extensions, I didn't envision namespacing as a requirement for this
project. To be included in the JED, extensions aren't allowed to hack core
files:
http://docs.joomla.org/index.php?title=JED_Entries_Submission_Checklist

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

>> El mi�rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi�:

>> El mi�rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi�:

>> El mi�rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi�:

>> El mi�rcoles, 15 de agosto de 2012 20:54:57 UTC+2, Nick Savov escribi�:

[Rouven Weßling]

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

[Amy Stephen]

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.

[Rouven Weßling]

On 19.08.2012, at 01:01, Amy Stephen <amyst...@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.

Best regards

Rouven

[Roberto Segura]

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.

[Rouven Weßling]

On 19.08.2012, at 02:32, Roberto Segura <rob...@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.

Best regards
Rouven

[Amy Stephen]

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.

[Andrew Eddie]

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.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Júlio Pontes]

Hi People,

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

https://github.com/juliopontes/joomla-mvc-override

This plugin works for 3.0 and 2.5.

[Elin Waring]

It would be great if someone would write up what Andrew just posted plus key points from elsewhere in the thread for the wiki.

Elin

[Amy Stephen]

On Sun, Aug 19, 2012 at 6:13 AM, Andrew Eddie <mamb...@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).

I understand now. Thanks.

Appreciate your response.

[Roberto Segura]

Nick what about opening this thread in the Joomla! CMS Development group?

I have created an article about how to create Joomla! overrides using the Julio Pontes override plugin:

goo.gl/QtH7r

[Júlio Pontes]

Roberto,

Awesome! :) Check your email.

[Nick Savov]

Hi Herman,

Thank you very much for the valuable feedback and word of warning! Your
insight is greatly appreciated!

Kind regards,
Nick

> I have just that, but a bit more sophisticated: I *extend *the class I

> overridden in your theme. That works nice (but not as good as my *extended
> override*, hehe).

[Nick Savov]

Thanks for the feedback and resources, Amy! :)

[Nick Savov]

Thank you for this information, Ian! Wow, you really know your Joomla
API! :)

Options 1 and 4 look very appealing at this point.

For anyone else interested in option #1, check out:
http://developer.joomla.org/manual/ch01s04.html

Kind regards,
Nick

>> <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.
>> >
>> > I have an example plugin that covers various options for overriding
>> core
>> > classes http://joomlacode.org/gf/project/joomla_16_ex/frs/
>> >
>> > Also, an example of how to override the View at runtime
>> > https://github.com/AmyStephen/Layout-Override-Plugin
>> >
>> > Julio Pontes has documented on the Wiki approaches for overriding
>> different
>> > parts of the MVC
>> >
>> http://docs.joomla.org/How_to_override_the_component_mvc_from_the_Joomla!_core
>> >
>> > 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:>>

[Nick Savov]

Wow, a lot of people contributed to this discussion. Instead of going
through this individually, I'd like to say thank you to everyone for your
help! I've read each of your comments and they helped a ton!

At this point, I'd like to move forward with an implementation since this
would need to get in before Joomla 3 beta. If anyone would like to help,
I would greatly appreciate your help!

Roberto and J�lio, I've add you to Skype. If you have some time, let's
chat :)

Kind regards,
Nick

[Ravi Sanchala]

On Sat, Sep 1, 2012 at 10:08 AM, dilbert4life <dilber...@gmail.com> wrote:

This is what I do in order to override system classes. I wrote up a blog post explaining everything more clearly than what the code provides, but by blog got nuked and I'm still working on getting that back up. In the mean time:

https://gist.github.com/3237387

thnxx.. for reply...... sir.. 

[Nick Savov]

Júlio Pontes has proposed an override system in the following tracker item:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29031

Could you all take a look, test, and offer your thoughts on it?

Kind regards,

Nick

[Nick Savov]

Hi Alonzo,

Great! Glad you like the concept. It would be great if you could test the
plugin and add your comments to the feature tracker:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8549&tracker_item_id=29031

By the way, you can already have alternative menu items in Joomla 2.5:
http://docs.joomla.org/Layout_Overrides_in_Joomla_1.6#Alternative_Menu_Items

Kind regards,
Nick

> I'm very enamored of the proposal that Júlio put forth. It is mostly an
> extension of the template overrides that are currently allowed but
> expanding it out to encompass all code files for an extension. It's great
> because I can't tell you the number of times that a client has wanted to
> add just one parameter to an article that could be accessed in the layout.
> Using this approach I could simply override the XML form file, and edit
> the
> field entries in the params fields. I whole heartedly endorse this plan of
> action; it is magical in its simplicity.

[Andrew Eddie]

I think now that you are getting into the implementation as a CMS
plugin, it would be best to move the discussion to the CMS list.

Thanks.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Nick Savov]

OK, thanks Andrew!

> I think now that you are getting into the implementation as a CMS
> plugin, it would be best to move the discussion to the CMS list.
>
> Thanks.
>
> Regards,
> Andrew Eddie
> http://learn.theartofjoomla.com - training videos for Joomla developers
>
>
> On 3 September 2012 05:12, Nick Savov <ni...@iowawebcompany.com> wrote:
>> Hi Alonzo,
>>
>> Great! Glad you like the concept. It would be great if you could test
>> the
>> plugin and add your comments to the feature tracker:
>> http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8549&tracker_item_id=29031
>>
>> By the way, you can already have alternative menu items in Joomla 2.5:
>> http://docs.joomla.org/Layout_Overrides_in_Joomla_1.6#Alternative_Menu_Items
>>
>> Kind regards,
>> Nick
>>

>>> I'm very enamored of the proposal that J�lio put forth. It is mostly an