Hi folks, right after JGrid, here another proposal.
Some of you might have seen my router plugin "Molajo Router", which is a proof of concept of an improved routing system in Joomla. You can download the plugin from here: http://www.joomlager.de/molajorouter.zip (The plugin currently is not fully functional and the title is just a working title)
As is described in the pull request, the changes to the framework are actually not that big, the changes to the CMS are a lot bigger.
The benefits: 1. Routing is a tiny bit faster 2. The routing is more flexible and does not impose some pre-defined rules that can not be switched off. 3. Writing a component router is now object oriented and if we want to implement the full feature set of the plugin, its also just one line of code per view and you are done. 4. Helper classes like ContentHelperRoute are not necessary anymore and the related bugs are automatically fixed. 5. URLs are always the same, regardless of them being sent through ContentHelperRoute or just through JRouter. 6. You can hand over a URL string or an associative array of URL parameters to JRoute 7. URLs can be changed simply by switching the rules by which they are build without touching the component router
The downsides: 1. Most of the SEF extensions that touch URLs wont really work anymore (most likely)
However, the system is backwards compatible for all components and their router.
I'd like to get this into 2.5 and would like to get approval for this and instructions how to proceed.
Hannes, I think this type of change is better suited for 3.0 than for 2.5. Version 2.5 is the LTS release and we don't want to introduce big changes that create backward-compatibility issue in this version. That is my .02. Mark
On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg <hackwa...@googlemail.com
> wrote: > Hi folks, > right after JGrid, here another proposal.
> Some of you might have seen my router plugin "Molajo Router", which is a > proof of concept of an improved routing system in Joomla. You can > download the plugin from here: http://www.joomlager.de/molajorouter.zip > (The plugin currently is not fully functional and the title is just a > working title)
> As is described in the pull request, the changes to the framework are > actually not that big, the changes to the CMS are a lot bigger.
> The benefits: > 1. Routing is a tiny bit faster > 2. The routing is more flexible and does not impose some pre-defined > rules that can not be switched off. > 3. Writing a component router is now object oriented and if we want to > implement the full feature set of the plugin, its also just one line of > code per view and you are done. > 4. Helper classes like ContentHelperRoute are not necessary anymore and > the related bugs are automatically fixed. > 5. URLs are always the same, regardless of them being sent through > ContentHelperRoute or just through JRouter. > 6. You can hand over a URL string or an associative array of URL > parameters to JRoute > 7. URLs can be changed simply by switching the rules by which they are > build without touching the component router
> The downsides: > 1. Most of the SEF extensions that touch URLs wont really work anymore > (most likely)
> However, the system is backwards compatible for all components and their > router.
> I'd like to get this into 2.5 and would like to get approval for this > and instructions how to proceed.
> Hannes
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
It would be a pitty to have to postpone this, considering that most likely most people will switch to 2.5 and then wait for 3.5 for their next big move. Especially since it fixes so many issues with the routing...
> Hannes, I think this type of change is better suited for 3.0 than for > 2.5. Version 2.5 is the LTS release and we don't want to introduce big > changes that create backward-compatibility issue in this version. That > is my .02. Mark
> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> Hi folks, > right after JGrid, here another proposal.
> Some of you might have seen my router plugin "Molajo Router", > which is a > proof of concept of an improved routing system in Joomla. You can > download the plugin from here: > http://www.joomlager.de/molajorouter.zip > (The plugin currently is not fully functional and the title is just a > working title)
> As is described in the pull request, the changes to the framework are > actually not that big, the changes to the CMS are a lot bigger.
> The benefits: > 1. Routing is a tiny bit faster > 2. The routing is more flexible and does not impose some pre-defined > rules that can not be switched off. > 3. Writing a component router is now object oriented and if we want to > implement the full feature set of the plugin, its also just one > line of > code per view and you are done. > 4. Helper classes like ContentHelperRoute are not necessary > anymore and > the related bugs are automatically fixed. > 5. URLs are always the same, regardless of them being sent through > ContentHelperRoute or just through JRouter. > 6. You can hand over a URL string or an associative array of URL > parameters to JRoute > 7. URLs can be changed simply by switching the rules by which they are > build without touching the component router
> The downsides: > 1. Most of the SEF extensions that touch URLs wont really work anymore > (most likely)
> However, the system is backwards compatible for all components and > their > router.
> I'd like to get this into 2.5 and would like to get approval for this > and instructions how to proceed.
> Hannes
> -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To post to this group, send an email to > joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com > <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
The biggest issue that I see is the issue of ContentHelperRoute. As long as you don't send your URL for com_content through that class, you will always get a URL like this: /component/content/article/23-alias instead of /products/fancystuff/23-alias. This is not a big problem if you are inside of code (although its a hazzle to always remember to add the call AND use the correct class for this) but when you have a URL in your content, that class is not present, which means that we can't find out the Itemid and as a result get the wrong URL. You can see this for example if you use the article linker plugin below the editor, which creates wrong URLs in 1.6/1.7
Besides that, I regard the hard coded rules how the URLs are treated as a bug and the big issues in writing your own component router as bugs. Writing a component router is still regarded as being black magic and very few people understand the system and how to use and code for it properly, resulting in either no router at all or very simple routers that don't create the result that we are looking for.
> Can you outline the " issues with the routing" that this addresses and > how it does it. -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To view this discussion on the web, visit > https://groups.google.com/d/msg/joomla-dev-cms/-/euiedlLnkRcJ. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I'm not sure what you mean with the second issue. If you mean the hard coded rules:
The system that I developed in the plugin is based on the idea that every change to the URL is a rule and rules are actually nothing more than function callbacks. So for the default Joomla behavior, there is a plugin that, when enabled, registers a bunch of functions in a special order, which do all the processing. If you want to change the behavior, you write your own plugin and add your own rule (=function callback) to the router. In the extreme case, you could deactivate the Joomla plugin and replace all the rules with your own without any changes to the core files, without any overrides and without any compatibility issues. With a little bit of standardization, we could even change the URLs to a date based scheme, which I normally refer to as Wordpress Style URLs. You can see an example how that would be done with this plugin: http://www.joomlager.de/molajowp.zip Another possibility is the stub for a REST interface, which you can see here: http://www.joomlager.de/molajorest.zip
If you mean the easy to write component routers:
First of all: We only need routes to views. Every other task than "display" should do its thing and then redirect us to the display task again. So that reduces the number of combinations that we have. Then we have a hierarchy on the different views. A categories view is the parent of a category view and a category view is the parent of an article view. The idea of my component router now is that you only have to register the dependencies between different views and the ID variables that are used based on the view that you use. The specific details that we have to register are: 1. unique name for the view in the component 2. name of the view (for example "article") 3. name of the ID variable if present (for example "id") 4. name of the parent view if present (for example "category") 5. name of the parent views ID variable if present (for example "catid") 6. is the view nestable (can I navigate from this view to the same view again? for example from a parent category to a child category) 7. if I'm navigating to this view (with this specific name (you can use the same view more than once in the path of your child and parent views)) I should be using this layout Everything except #1 and #2 are optional and in the last 8 months I haven't come across a structure that could not be mapped by this. Now, the component router is made a class in this new system and in the constructor this data is registered. (If you want to add more views by a plugin or something, that is possible, too) The class extends a JComponentRouter class (not yet part of the pull request to the platform project) which again can register rules (=function callbacks) to be used on a component level and which can then build and parse the URLs based on the information given above. With all this in place, the complete router for com_content could look like this:
> 1. I never use the article linker so haven't seen those links as I > always use JCE but I take your point
> 2. Can you explain how you are resolving the second issue you described > -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To view this discussion on the web, visit > https://groups.google.com/d/msg/joomla-dev-cms/-/jvRntpgpnIUJ. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I would suggest that the only downside would be perceived by those who
make the components. I for one, would love it if I never had to touch
shSEF ever again as it's the most temperamental piece of software I
tend to install.
On Sep 21, 6:00 pm, Hannes Papenberg <hackwa...@googlemail.com> wrote:
> Besides that, I regard the hard coded rules how the URLs are treated as > a bug and the big issues in writing your own component router as bugs. > Writing a component router is still regarded as being black magic and > very few people understand the system and how to use and code for it > properly, resulting in either no router at all or very simple routers > that don't create the result that we are looking for.
I don't quite understand this one, the routers create an array of strings which get appended together to create the url, or in reverse take an array of strings and reverses them.
While all the routers that come with components are simplistic, it's not that difficult to customize a router to use specific rules for different sections of content[I've done that quite frequently where sobi or adsmanager needed different url structures depending on the category of the item].
It's not really that difficult to go from that to having a customizable router for a component where you can set different rules.
If instead of just using a set of rules, you added in the ability to set the rule "traditional joomla routing" - and if that is chosen run the traditional routing mechanism functions, then your backwards compatible along with new features.
In any case, 2.5 is already going to include a new search function which may not be backward compatible, I see no reason not to improve the router since the router is just about universally not used in favor of installing very complicated alternatives. The current router works great for coders who can create custom routers for every component they use, but it's not so good for end users.
run before and after converting a url to SEF, and run before and after Decoding. Before decoding or SEF give it a chance to change the order of the rules, disable rules, enable rules. After give it a chance to modify the result.
In addition to that, on the CMS side add a router component to give access to the overall rules settings, and to modify the rules for a specific component. I'd also add a few events there: routerGetRules routerConfigureRule
So any component can include a plugin which adds additional rules[either universal rules or rules limited to a specific component] and the router component can use the GetRules event to find all those rules and display them for configuration. A rule should likely be contained in an array including the component(s), the rule name, and configuration parameters. Either those parameters need to be stored by the router component itself...or sent to the component plugin via routerConfigureRule event and allow the component to store that data.
Hello Gary, I was not talking about hard coded rules in the component routers. Those can of course be changed by each component developer to suit his or her needs. I was rather talking about the hard coded rules in JRouter itself, which for example force the menu system behavior or replace the first "-" in a string to ":", eventhough that might not even be necessary. Regarding the "traditional Joomla behavior": The system as it is in the proof of concept mentioned in my first post is behaving exactly like the routing in Joomla 1.5/1.6/1.7, but the big benefit is, that you can easily replace or amend to it with your own rules. So yes, its backwards compatible.
>> Besides that, I regard the hard coded rules how the URLs are treated as >> a bug and the big issues in writing your own component router as bugs. >> Writing a component router is still regarded as being black magic and >> very few people understand the system and how to use and code for it >> properly, resulting in either no router at all or very simple routers >> that don't create the result that we are looking for.
> I don't quite understand this one, the routers create an array of > strings which get appended together to create the url, or in reverse > take an array of strings and reverses them.
> While all the routers that come with components are simplistic, it's > not that difficult to customize a router to use specific rules for > different sections of content[I've done that quite frequently where > sobi or adsmanager needed different url structures depending on the > category of the item].
> It's not really that difficult to go from that to having a > customizable router for a component where you can set different rules.
> If instead of just using a set of rules, you added in the ability to > set the rule "traditional joomla routing" - and if that is chosen run > the traditional routing mechanism functions, then your backwards > compatible along with new features.
> In any case, 2.5 is already going to include a new search function > which may not be backward compatible, I see no reason not to improve > the router since the router is just about universally not used in > favor of installing very complicated alternatives. The current router > works great for coders who can create custom routers for every > component they use, but it's not so good for end users.
Hi Gary, I don't see the reason in adding the 4 events that you mention below. These events are already covered by the rule system itself. Besides that, it would be quite costly in terms of performance to invoke all those events on each URL conversion. The rest of your proposals are already in my proposal, albeit implemented differently.
> run before and after converting a url to SEF, and run before and after > Decoding. Before decoding or SEF give it a chance to change the order > of the rules, disable rules, enable rules. After give it a chance to > modify the result.
> In addition to that, on the CMS side add a router component to give > access to the overall rules settings, and to modify the rules for a > specific component. I'd also add a few events there: > routerGetRules > routerConfigureRule
> So any component can include a plugin which adds additional > rules[either universal rules or rules limited to a specific component] > and the router component can use the GetRules event to find all those > rules and display them for configuration. A rule should likely be > contained in an array including the component(s), the rule name, and > configuration parameters. Either those parameters need to be stored > by the router component itself...or sent to the component plugin via > routerConfigureRule event and allow the component to store that data.
As I already wrote in the JGrid thread, I had some issues with getting a Joomlacode account, so I created a branch for these changes on github. You can find the implemented router changes here: https://github.com/Hackwar/joomla-cms/tree/jrouter
Its completely installable and works. (I've seen a tiny bug with the URLs, but otherwise...) For now, the language files and comments in the code are missing, but the rest should already be fine.
I would be happy if people could take a look at this and maybe test it with one of their own components. I would also be very happy if the PLT could (re-)consider this change for 2.5. Thank you
> Hannes, I think this type of change is better suited for 3.0 than for > 2.5. Version 2.5 is the LTS release and we don't want to introduce big > changes that create backward-compatibility issue in this version. That > is my .02. Mark
> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> Hi folks, > right after JGrid, here another proposal.
> Some of you might have seen my router plugin "Molajo Router", > which is a > proof of concept of an improved routing system in Joomla. You can > download the plugin from here: > http://www.joomlager.de/molajorouter.zip > (The plugin currently is not fully functional and the title is just a > working title)
> As is described in the pull request, the changes to the framework are > actually not that big, the changes to the CMS are a lot bigger.
> The benefits: > 1. Routing is a tiny bit faster > 2. The routing is more flexible and does not impose some pre-defined > rules that can not be switched off. > 3. Writing a component router is now object oriented and if we want to > implement the full feature set of the plugin, its also just one > line of > code per view and you are done. > 4. Helper classes like ContentHelperRoute are not necessary > anymore and > the related bugs are automatically fixed. > 5. URLs are always the same, regardless of them being sent through > ContentHelperRoute or just through JRouter. > 6. You can hand over a URL string or an associative array of URL > parameters to JRoute > 7. URLs can be changed simply by switching the rules by which they are > build without touching the component router
> The downsides: > 1. Most of the SEF extensions that touch URLs wont really work anymore > (most likely)
> However, the system is backwards compatible for all components and > their > router.
> I'd like to get this into 2.5 and would like to get approval for this > and instructions how to proceed.
> Hannes
> -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To post to this group, send an email to > joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com > <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> I would also be very happy if the PLT > could (re-)consider this change for 2.5.
Can this be implemented in 2.5 as a checkbox in Global Configuration similar, next to the core SEF settings? By default 'legacy mode' is 'on' the old router code is active and all SEF extensions still work and backwards compatibility is maintained, but a User can flip it on as extensions become '2.5 native'. In 3.0 the checkbox goes away with the legacy router.
----- Original Message ----- From: "Hannes Papenberg" <hackwa...@googlemail.com> To: <joomla-dev-cms@googlegroups.com> Sent: Monday, October 03, 2011 3:36 AM Subject: Re: [jcms] Routing in Joomla
> As I already wrote in the JGrid thread, I had some issues with getting a > Joomlacode account, so I created a branch for these changes on github. > You can find the implemented router changes here: > https://github.com/Hackwar/joomla-cms/tree/jrouter
> Its completely installable and works. (I've seen a tiny bug with the > URLs, but otherwise...) For now, the language files and comments in the > code are missing, but the rest should already be fine.
> I would be happy if people could take a look at this and maybe test it > with one of their own components. I would also be very happy if the PLT > could (re-)consider this change for 2.5. Thank you
> Hannes
> Am 21.09.2011 19:09, schrieb Mark Dexter: >> Hannes, I think this type of change is better suited for 3.0 than for >> 2.5. Version 2.5 is the LTS release and we don't want to introduce big >> changes that create backward-compatibility issue in this version. That >> is my .02. Mark
>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg >> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
>> Hi folks, >> right after JGrid, here another proposal.
>> Some of you might have seen my router plugin "Molajo Router", >> which is a >> proof of concept of an improved routing system in Joomla. You can >> download the plugin from here: >> http://www.joomlager.de/molajorouter.zip >> (The plugin currently is not fully functional and the title is just a >> working title)
>> As is described in the pull request, the changes to the framework are >> actually not that big, the changes to the CMS are a lot bigger.
>> The benefits: >> 1. Routing is a tiny bit faster >> 2. The routing is more flexible and does not impose some pre-defined >> rules that can not be switched off. >> 3. Writing a component router is now object oriented and if we want >> to >> implement the full feature set of the plugin, its also just one >> line of >> code per view and you are done. >> 4. Helper classes like ContentHelperRoute are not necessary >> anymore and >> the related bugs are automatically fixed. >> 5. URLs are always the same, regardless of them being sent through >> ContentHelperRoute or just through JRouter. >> 6. You can hand over a URL string or an associative array of URL >> parameters to JRoute >> 7. URLs can be changed simply by switching the rules by which they >> are >> build without touching the component router
>> The downsides: >> 1. Most of the SEF extensions that touch URLs wont really work >> anymore >> (most likely)
>> However, the system is backwards compatible for all components and >> their >> router.
>> I'd like to get this into 2.5 and would like to get approval for this >> and instructions how to proceed.
>> Hannes
>> -- >> You received this message because you are subscribed to the Google >> Groups "Joomla! CMS Development" group. >> To post to this group, send an email to >> joomla-dev-cms@googlegroups.com >> <mailto:joomla-dev-cms@googlegroups.com>. >> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com >> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> -- >> You received this message because you are subscribed to the Google >> Groups "Joomla! CMS Development" group. >> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
No, I don't think that it is possible to implement this in such a backwards compatible manner, since it would more or less require a complete seperate routing system next to this solution. On the other hand, its not breaking the common extensions, most likely only those that heavily modify the URLs, which would not really be necessary anymore anyway. This system is much more powerfull.
>> I would also be very happy if the PLT >> could (re-)consider this change for 2.5.
> Can this be implemented in 2.5 as a checkbox in Global Configuration > similar, next to the core SEF settings? > By default 'legacy mode' is 'on' the old router code is active and all > SEF extensions still work and backwards > compatibility is maintained, but a User can flip it on as extensions > become '2.5 native'. > In 3.0 the checkbox goes away with the legacy router.
> Just a thought.
> ----- Original Message ----- From: "Hannes Papenberg" > <hackwa...@googlemail.com> > To: <joomla-dev-cms@googlegroups.com> > Sent: Monday, October 03, 2011 3:36 AM > Subject: Re: [jcms] Routing in Joomla
>> As I already wrote in the JGrid thread, I had some issues with getting a >> Joomlacode account, so I created a branch for these changes on github. >> You can find the implemented router changes here: >> https://github.com/Hackwar/joomla-cms/tree/jrouter
>> Its completely installable and works. (I've seen a tiny bug with the >> URLs, but otherwise...) For now, the language files and comments in the >> code are missing, but the rest should already be fine.
>> I would be happy if people could take a look at this and maybe test it >> with one of their own components. I would also be very happy if the PLT >> could (re-)consider this change for 2.5. Thank you
>> Hannes
>> Am 21.09.2011 19:09, schrieb Mark Dexter: >>> Hannes, I think this type of change is better suited for 3.0 than for >>> 2.5. Version 2.5 is the LTS release and we don't want to introduce big >>> changes that create backward-compatibility issue in this version. That >>> is my .02. Mark
>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg >>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
>>> Hi folks, >>> right after JGrid, here another proposal.
>>> Some of you might have seen my router plugin "Molajo Router", >>> which is a >>> proof of concept of an improved routing system in Joomla. You can >>> download the plugin from here: >>> http://www.joomlager.de/molajorouter.zip >>> (The plugin currently is not fully functional and the title is >>> just a >>> working title)
>>> As is described in the pull request, the changes to the >>> framework are >>> actually not that big, the changes to the CMS are a lot bigger.
>>> The benefits: >>> 1. Routing is a tiny bit faster >>> 2. The routing is more flexible and does not impose some >>> pre-defined >>> rules that can not be switched off. >>> 3. Writing a component router is now object oriented and if we >>> want to >>> implement the full feature set of the plugin, its also just one >>> line of >>> code per view and you are done. >>> 4. Helper classes like ContentHelperRoute are not necessary >>> anymore and >>> the related bugs are automatically fixed. >>> 5. URLs are always the same, regardless of them being sent through >>> ContentHelperRoute or just through JRouter. >>> 6. You can hand over a URL string or an associative array of URL >>> parameters to JRoute >>> 7. URLs can be changed simply by switching the rules by which >>> they are >>> build without touching the component router
>>> The downsides: >>> 1. Most of the SEF extensions that touch URLs wont really work >>> anymore >>> (most likely)
>>> However, the system is backwards compatible for all components and >>> their >>> router.
>>> I'd like to get this into 2.5 and would like to get approval for >>> this >>> and instructions how to proceed.
>>> Hannes
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Joomla! CMS Development" group. >>> To post to this group, send an email to >>> joomla-dev-cms@googlegroups.com >>> <mailto:joomla-dev-cms@googlegroups.com>. >>> To unsubscribe from this group, send email to >>> joomla-dev-cms+unsubscribe@googlegroups.com >>> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. >>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Joomla! CMS Development" group. >>> To post to this group, send an email to >>> joomla-dev-cms@googlegroups.com. >>> To unsubscribe from this group, send email to >>> joomla-dev-cms+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> -- >> You received this message because you are subscribed to the Google >> Groups "Joomla! CMS Development" group. >> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >> To unsubscribe from this group, send email to >> joomla-dev-cms+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I had a play with this new routing functionality not too long ago and I have to say, it is the only router implementation i've ever looked at (in my test component) without wanting to jump off a bridge. If it really is fully backwards-compatible I would very much like to see it in 2.5 as we do indeed have at least 3 months of time to test it.
Routers are one of the very last bastions of black magic left and I would consider it a major improvement to the CMS as a whole.
<hackwa...@googlemail.com> wrote: > No, I don't think that it is possible to implement this in such a > backwards compatible manner, since it would more or less require a > complete seperate routing system next to this solution. On the other > hand, its not breaking the common extensions, most likely only those > that heavily modify the URLs, which would not really be necessary > anymore anyway. This system is much more powerfull.
> Hannes
> Am 03.10.2011 22:46, schrieb G. D. Speer: >>> I would also be very happy if the PLT >>> could (re-)consider this change for 2.5.
>> Can this be implemented in 2.5 as a checkbox in Global Configuration >> similar, next to the core SEF settings? >> By default 'legacy mode' is 'on' the old router code is active and all >> SEF extensions still work and backwards >> compatibility is maintained, but a User can flip it on as extensions >> become '2.5 native'. >> In 3.0 the checkbox goes away with the legacy router.
>> Just a thought.
>> ----- Original Message ----- From: "Hannes Papenberg" >> <hackwa...@googlemail.com> >> To: <joomla-dev-cms@googlegroups.com> >> Sent: Monday, October 03, 2011 3:36 AM >> Subject: Re: [jcms] Routing in Joomla
>>> As I already wrote in the JGrid thread, I had some issues with getting a >>> Joomlacode account, so I created a branch for these changes on github. >>> You can find the implemented router changes here: >>> https://github.com/Hackwar/joomla-cms/tree/jrouter
>>> Its completely installable and works. (I've seen a tiny bug with the >>> URLs, but otherwise...) For now, the language files and comments in the >>> code are missing, but the rest should already be fine.
>>> I would be happy if people could take a look at this and maybe test it >>> with one of their own components. I would also be very happy if the PLT >>> could (re-)consider this change for 2.5. Thank you
>>> Hannes
>>> Am 21.09.2011 19:09, schrieb Mark Dexter: >>>> Hannes, I think this type of change is better suited for 3.0 than for >>>> 2.5. Version 2.5 is the LTS release and we don't want to introduce big >>>> changes that create backward-compatibility issue in this version. That >>>> is my .02. Mark
>>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg >>>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
>>>> Hi folks, >>>> right after JGrid, here another proposal.
>>>> Some of you might have seen my router plugin "Molajo Router", >>>> which is a >>>> proof of concept of an improved routing system in Joomla. You can >>>> download the plugin from here: >>>> http://www.joomlager.de/molajorouter.zip >>>> (The plugin currently is not fully functional and the title is >>>> just a >>>> working title)
>>>> As is described in the pull request, the changes to the >>>> framework are >>>> actually not that big, the changes to the CMS are a lot bigger.
>>>> The benefits: >>>> 1. Routing is a tiny bit faster >>>> 2. The routing is more flexible and does not impose some >>>> pre-defined >>>> rules that can not be switched off. >>>> 3. Writing a component router is now object oriented and if we >>>> want to >>>> implement the full feature set of the plugin, its also just one >>>> line of >>>> code per view and you are done. >>>> 4. Helper classes like ContentHelperRoute are not necessary >>>> anymore and >>>> the related bugs are automatically fixed. >>>> 5. URLs are always the same, regardless of them being sent through >>>> ContentHelperRoute or just through JRouter. >>>> 6. You can hand over a URL string or an associative array of URL >>>> parameters to JRoute >>>> 7. URLs can be changed simply by switching the rules by which >>>> they are >>>> build without touching the component router
>>>> The downsides: >>>> 1. Most of the SEF extensions that touch URLs wont really work >>>> anymore >>>> (most likely)
>>>> However, the system is backwards compatible for all components and >>>> their >>>> router.
>>>> I'd like to get this into 2.5 and would like to get approval for >>>> this >>>> and instructions how to proceed.
>>>> Hannes
>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Joomla! CMS Development" group. >>>> To post to this group, send an email to >>>> joomla-dev-cms@googlegroups.com >>>> <mailto:joomla-dev-cms@googlegroups.com>. >>>> To unsubscribe from this group, send email to >>>> joomla-dev-cms+unsubscribe@googlegroups.com >>>> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. >>>> For more options, visit this group at >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Joomla! CMS Development" group. >>>> To post to this group, send an email to >>>> joomla-dev-cms@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> joomla-dev-cms+unsubscribe@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Joomla! CMS Development" group. >>> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >>> To unsubscribe from this group, send email to >>> joomla-dev-cms+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
I've been in contact with Matias Griese from the Kunena Team and we added several small speed improvements to the system. JRouterSite and the rules belonging to that router have been optimized quite a lot. JComponentRouter and its rules have also been worked on a bit, however I discovered a design bug in there, which will require me to rewrite quite a bit of the rules and JComponentRouter. The idea was, that you could register a view under different names with different layouts, so that you could have a different behavior for different layouts. Unfortunately I totally messed that up, but I didn't notice it, because that feature is not used in the core components... I will look into making that work in the coming days.
One big improvement was the removal of the legacy mode in the actual router and instead providing a default router that handles the legacy mode if necessary. That means that all component routers now use the class method, but in case that the component uses legacy routers (=the functions instead of a class) a router "JDefaultRouter" is registered, which either calls the legacy routers or provides a router (that does nothing) for extensions that don't have a router. We also implemented an interface that every new router class has to implement in order to be recognized as a new router to prevent legacy issues. (Specifically Kunena already had a class named KunenaRouter, which would collide with this implementation)
The general gain by this new router seems to be about 50% on my system, Matias had even extremely larger gains of 400% and more. Since our measuring methods differ a bit and since the actual performance also depends on the use cases, you can't really compare the results, but the tendency is clear that the code is quite a lot faster.
Now, what do we have to do to get this (or parts of it) into 2.5?
> I had a play with this new routing functionality not too long ago and > I have to say, it is the only router implementation i've ever looked > at (in my test component) without wanting to jump off a bridge. If it > really is fully backwards-compatible I would very much like to see it > in 2.5 as we do indeed have at least 3 months of time to test it.
> Routers are one of the very last bastions of black magic left and I > would consider it a major improvement to the CMS as a whole.
> - Rune
> On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > <hackwa...@googlemail.com> wrote: >> No, I don't think that it is possible to implement this in such a >> backwards compatible manner, since it would more or less require a >> complete seperate routing system next to this solution. On the other >> hand, its not breaking the common extensions, most likely only those >> that heavily modify the URLs, which would not really be necessary >> anymore anyway. This system is much more powerfull.
>> Hannes
>> Am 03.10.2011 22:46, schrieb G. D. Speer: >>>> I would also be very happy if the PLT >>>> could (re-)consider this change for 2.5. >>> Can this be implemented in 2.5 as a checkbox in Global Configuration >>> similar, next to the core SEF settings? >>> By default 'legacy mode' is 'on' the old router code is active and all >>> SEF extensions still work and backwards >>> compatibility is maintained, but a User can flip it on as extensions >>> become '2.5 native'. >>> In 3.0 the checkbox goes away with the legacy router.
>>> Just a thought.
>>> ----- Original Message ----- From: "Hannes Papenberg" >>> <hackwa...@googlemail.com> >>> To: <joomla-dev-cms@googlegroups.com> >>> Sent: Monday, October 03, 2011 3:36 AM >>> Subject: Re: [jcms] Routing in Joomla
>>>> As I already wrote in the JGrid thread, I had some issues with getting a >>>> Joomlacode account, so I created a branch for these changes on github. >>>> You can find the implemented router changes here: >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
>>>> Its completely installable and works. (I've seen a tiny bug with the >>>> URLs, but otherwise...) For now, the language files and comments in the >>>> code are missing, but the rest should already be fine.
>>>> I would be happy if people could take a look at this and maybe test it >>>> with one of their own components. I would also be very happy if the PLT >>>> could (re-)consider this change for 2.5. Thank you
>>>> Hannes
>>>> Am 21.09.2011 19:09, schrieb Mark Dexter: >>>>> Hannes, I think this type of change is better suited for 3.0 than for >>>>> 2.5. Version 2.5 is the LTS release and we don't want to introduce big >>>>> changes that create backward-compatibility issue in this version. That >>>>> is my .02. Mark
>>>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg >>>>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
>>>>> Hi folks, >>>>> right after JGrid, here another proposal.
>>>>> Some of you might have seen my router plugin "Molajo Router", >>>>> which is a >>>>> proof of concept of an improved routing system in Joomla. You can >>>>> download the plugin from here: >>>>> http://www.joomlager.de/molajorouter.zip >>>>> (The plugin currently is not fully functional and the title is >>>>> just a >>>>> working title)
>>>>> As is described in the pull request, the changes to the >>>>> framework are >>>>> actually not that big, the changes to the CMS are a lot bigger.
>>>>> The benefits: >>>>> 1. Routing is a tiny bit faster >>>>> 2. The routing is more flexible and does not impose some >>>>> pre-defined >>>>> rules that can not be switched off. >>>>> 3. Writing a component router is now object oriented and if we >>>>> want to >>>>> implement the full feature set of the plugin, its also just one >>>>> line of >>>>> code per view and you are done. >>>>> 4. Helper classes like ContentHelperRoute are not necessary >>>>> anymore and >>>>> the related bugs are automatically fixed. >>>>> 5. URLs are always the same, regardless of them being sent through >>>>> ContentHelperRoute or just through JRouter. >>>>> 6. You can hand over a URL string or an associative array of URL >>>>> parameters to JRoute >>>>> 7. URLs can be changed simply by switching the rules by which >>>>> they are >>>>> build without touching the component router
>>>>> The downsides: >>>>> 1. Most of the SEF extensions that touch URLs wont really work >>>>> anymore >>>>> (most likely)
>>>>> However, the system is backwards compatible for all components and >>>>> their >>>>> router.
>>>>> I'd like to get this into 2.5 and would like to get approval for >>>>> this >>>>> and instructions how to proceed.
>>>>> Hannes
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Joomla! CMS Development" group. >>>>> To post to this group, send an email to >>>>> joomla-dev-cms@googlegroups.com >>>>> <mailto:joomla-dev-cms@googlegroups.com>. >>>>> To unsubscribe from this group, send email to >>>>> joomla-dev-cms+unsubscribe@googlegroups.com >>>>> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Joomla! CMS Development" group. >>>>> To post to this group, send an email to >>>>> joomla-dev-cms@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> joomla-dev-cms+unsubscribe@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Joomla! CMS Development" group. >>>> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> joomla-dev-cms+unsubscribe@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>> -- >> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group. >> To post to this group, send an email to joomla-dev-cms@googlegroups.com. >> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> I've been in contact with Matias Griese from the Kunena Team and we > added several small speed improvements to the system. JRouterSite and > the rules belonging to that router have been optimized quite a lot. > JComponentRouter and its rules have also been worked on a bit, however I > discovered a design bug in there, which will require me to rewrite quite > a bit of the rules and JComponentRouter. The idea was, that you could > register a view under different names with different layouts, so that > you could have a different behavior for different layouts. Unfortunately > I totally messed that up, but I didn't notice it, because that feature > is not used in the core components... I will look into making that work > in the coming days.
> One big improvement was the removal of the legacy mode in the actual > router and instead providing a default router that handles the legacy > mode if necessary. That means that all component routers now use the > class method, but in case that the component uses legacy routers (=the > functions instead of a class) a router "JDefaultRouter" is registered, > which either calls the legacy routers or provides a router (that does > nothing) for extensions that don't have a router. We also implemented an > interface that every new router class has to implement in order to be > recognized as a new router to prevent legacy issues. (Specifically > Kunena already had a class named KunenaRouter, which would collide with > this implementation)
> The general gain by this new router seems to be about 50% on my system, > Matias had even extremely larger gains of 400% and more. Since our > measuring methods differ a bit and since the actual performance also > depends on the use cases, you can't really compare the results, but the > tendency is clear that the code is quite a lot faster.
> Now, what do we have to do to get this (or parts of it) into 2.5?
> Hannes
> Am 04.10.2011 12:56, schrieb Rune V. Sjøen: > > I had a play with this new routing functionality not too long ago and > > I have to say, it is the only router implementation i've ever looked > > at (in my test component) without wanting to jump off a bridge. If it > > really is fully backwards-compatible I would very much like to see it > > in 2.5 as we do indeed have at least 3 months of time to test it.
> > Routers are one of the very last bastions of black magic left and I > > would consider it a major improvement to the CMS as a whole.
> > - Rune
> > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > <hackwa...@googlemail.com> wrote: > >> No, I don't think that it is possible to implement this in such a > >> backwards compatible manner, since it would more or less require a > >> complete seperate routing system next to this solution. On the other > >> hand, its not breaking the common extensions, most likely only those > >> that heavily modify the URLs, which would not really be necessary > >> anymore anyway. This system is much more powerfull.
> >> Hannes
> >> Am 03.10.2011 22:46, schrieb G. D. Speer: > >>>> I would also be very happy if the PLT > >>>> could (re-)consider this change for 2.5. > >>> Can this be implemented in 2.5 as a checkbox in Global Configuration > >>> similar, next to the core SEF settings? > >>> By default 'legacy mode' is 'on' the old router code is active and all > >>> SEF extensions still work and backwards > >>> compatibility is maintained, but a User can flip it on as extensions > >>> become '2.5 native'. > >>> In 3.0 the checkbox goes away with the legacy router.
> >>> Just a thought.
> >>> ----- Original Message ----- From: "Hannes Papenberg" > >>> <hackwa...@googlemail.com> > >>> To: <joomla-dev-cms@googlegroups.com> > >>> Sent: Monday, October 03, 2011 3:36 AM > >>> Subject: Re: [jcms] Routing in Joomla
> >>>> As I already wrote in the JGrid thread, I had some issues with getting > a > >>>> Joomlacode account, so I created a branch for these changes on github. > >>>> You can find the implemented router changes here: > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> >>>> Its completely installable and works. (I've seen a tiny bug with the > >>>> URLs, but otherwise...) For now, the language files and comments in > the > >>>> code are missing, but the rest should already be fine.
> >>>> I would be happy if people could take a look at this and maybe test it > >>>> with one of their own components. I would also be very happy if the > PLT > >>>> could (re-)consider this change for 2.5. Thank you
> >>>> Hannes
> >>>> Am 21.09.2011 19:09, schrieb Mark Dexter: > >>>>> Hannes, I think this type of change is better suited for 3.0 than for > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to introduce > big > >>>>> changes that create backward-compatibility issue in this version. > That > >>>>> is my .02. Mark
> >>>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg > >>>>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> >>>>> Hi folks, > >>>>> right after JGrid, here another proposal.
> >>>>> Some of you might have seen my router plugin "Molajo Router", > >>>>> which is a > >>>>> proof of concept of an improved routing system in Joomla. You can > >>>>> download the plugin from here: > >>>>> http://www.joomlager.de/molajorouter.zip > >>>>> (The plugin currently is not fully functional and the title is > >>>>> just a > >>>>> working title)
> >>>>> As is described in the pull request, the changes to the > >>>>> framework are > >>>>> actually not that big, the changes to the CMS are a lot bigger.
> >>>>> The benefits: > >>>>> 1. Routing is a tiny bit faster > >>>>> 2. The routing is more flexible and does not impose some > >>>>> pre-defined > >>>>> rules that can not be switched off. > >>>>> 3. Writing a component router is now object oriented and if we > >>>>> want to > >>>>> implement the full feature set of the plugin, its also just one > >>>>> line of > >>>>> code per view and you are done. > >>>>> 4. Helper classes like ContentHelperRoute are not necessary > >>>>> anymore and > >>>>> the related bugs are automatically fixed. > >>>>> 5. URLs are always the same, regardless of them being sent > through > >>>>> ContentHelperRoute or just through JRouter. > >>>>> 6. You can hand over a URL string or an associative array of URL > >>>>> parameters to JRoute > >>>>> 7. URLs can be changed simply by switching the rules by which > >>>>> they are > >>>>> build without touching the component router
> >>>>> The downsides: > >>>>> 1. Most of the SEF extensions that touch URLs wont really work > >>>>> anymore > >>>>> (most likely)
> >>>>> However, the system is backwards compatible for all components > and > >>>>> their > >>>>> router.
> >>>>> I'd like to get this into 2.5 and would like to get approval for > >>>>> this > >>>>> and instructions how to proceed.
> >>>>> Hannes
> >>>>> -- > >>>>> You received this message because you are subscribed to the > Google > >>>>> Groups "Joomla! CMS Development" group. > >>>>> To post to this group, send an email to > >>>>> joomla-dev-cms@googlegroups.com > >>>>> <mailto:joomla-dev-cms@googlegroups.com>. > >>>>> To unsubscribe from this group, send email to > >>>>> joomla-dev-cms+unsubscribe@googlegroups.com > >>>>> <mailto:joomla-dev-cms%2Bunsubscribe@googlegroups.com>. > >>>>> For more options, visit this group at > >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "Joomla! CMS Development" group. > >>>>> To post to this group, send an email to > >>>>> joomla-dev-cms@googlegroups.com. > >>>>> To unsubscribe from this group, send email to > >>>>> joomla-dev-cms+unsubscribe@googlegroups.com. > >>>>> For more options, visit this group at > >>>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB. > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "Joomla! CMS Development" group. > >>>> To post to this group, send an email to > joomla-dev-cms@googlegroups.com. > >>>> To unsubscribe from this group, send email to > >>>> joomla-dev-cms+unsubscribe@googlegroups.com. > >>>> For more options, visit this group at > >>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> >> -- > >> You received this message because you are subscribed to the Google > Groups "Joomla! CMS Development" group. > >> To post to this group, send an email to joomla-dev-cms@googlegroups.com > . > >> To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > >> For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
> -- > You received this message because you are subscribed to the Google Groups > "Joomla! CMS Development" group. > To post to this group, send an email to joomla-dev-cms@googlegroups.com. > To unsubscribe from this group, send email to > joomla-dev-cms+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
Hi Mark, I prepared a branch that shows the changes to the application- and platform-router and introduces the important parts of the new system. It is missing the component routers, as they still have some issues in the design (like I wrote earlier), but they can be added later. These changes would already be a big gain for all of us, both in performance as in flexibility. I don't know if they pass all systemtests, since my system is not set up to run those tests, but since they create the same URLs like before, I would vouch for this system.
I would be happy if the PLT could accept this proposal and as soon as I have the issues of the component routers worked out, I would be even happier if you would accept those changes, too. I'm working hard to make this possible for Joomla 2.5.
> Hi Hannes. Do you have a working branch that passes all of the system > tests? Mark
> On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> I've been in contact with Matias Griese from the Kunena Team and we > added several small speed improvements to the system. JRouterSite and > the rules belonging to that router have been optimized quite a lot. > JComponentRouter and its rules have also been worked on a bit, > however I > discovered a design bug in there, which will require me to rewrite > quite > a bit of the rules and JComponentRouter. The idea was, that you could > register a view under different names with different layouts, so that > you could have a different behavior for different layouts. > Unfortunately > I totally messed that up, but I didn't notice it, because that feature > is not used in the core components... I will look into making that > work > in the coming days.
> One big improvement was the removal of the legacy mode in the actual > router and instead providing a default router that handles the legacy > mode if necessary. That means that all component routers now use the > class method, but in case that the component uses legacy routers (=the > functions instead of a class) a router "JDefaultRouter" is registered, > which either calls the legacy routers or provides a router (that does > nothing) for extensions that don't have a router. We also > implemented an > interface that every new router class has to implement in order to be > recognized as a new router to prevent legacy issues. (Specifically > Kunena already had a class named KunenaRouter, which would collide > with > this implementation)
> The general gain by this new router seems to be about 50% on my > system, > Matias had even extremely larger gains of 400% and more. Since our > measuring methods differ a bit and since the actual performance also > depends on the use cases, you can't really compare the results, > but the > tendency is clear that the code is quite a lot faster.
> Now, what do we have to do to get this (or parts of it) into 2.5?
> Hannes
> Am 04.10.2011 12:56, schrieb Rune V. Sj en: > > I had a play with this new routing functionality not too long > ago and > > I have to say, it is the only router implementation i've ever looked > > at (in my test component) without wanting to jump off a bridge. > If it > > really is fully backwards-compatible I would very much like to > see it > > in 2.5 as we do indeed have at least 3 months of time to test it.
> > Routers are one of the very last bastions of black magic left and I > > would consider it a major improvement to the CMS as a whole.
> > - Rune
> > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote: > >> No, I don't think that it is possible to implement this in such a > >> backwards compatible manner, since it would more or less require a > >> complete seperate routing system next to this solution. On the > other > >> hand, its not breaking the common extensions, most likely only > those > >> that heavily modify the URLs, which would not really be necessary > >> anymore anyway. This system is much more powerfull.
> >> Hannes
> >> Am 03.10.2011 22:46, schrieb G. D. Speer: > >>>> I would also be very happy if the PLT > >>>> could (re-)consider this change for 2.5. > >>> Can this be implemented in 2.5 as a checkbox in Global > Configuration > >>> similar, next to the core SEF settings? > >>> By default 'legacy mode' is 'on' the old router code is active > and all > >>> SEF extensions still work and backwards > >>> compatibility is maintained, but a User can flip it on as > extensions > >>> become '2.5 native'. > >>> In 3.0 the checkbox goes away with the legacy router.
> >>> Just a thought.
> >>> ----- Original Message ----- From: "Hannes Papenberg" > >>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> > >>> To: <joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>> > >>> Sent: Monday, October 03, 2011 3:36 AM > >>> Subject: Re: [jcms] Routing in Joomla
> >>>> As I already wrote in the JGrid thread, I had some issues > with getting a > >>>> Joomlacode account, so I created a branch for these changes > on github. > >>>> You can find the implemented router changes here: > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> >>>> Its completely installable and works. (I've seen a tiny bug > with the > >>>> URLs, but otherwise...) For now, the language files and > comments in the > >>>> code are missing, but the rest should already be fine.
> >>>> I would be happy if people could take a look at this and > maybe test it > >>>> with one of their own components. I would also be very happy > if the PLT > >>>> could (re-)consider this change for 2.5. Thank you
> >>>> Hannes
> >>>> Am 21.09.2011 19 <tel:21.09.2011%2019>:09, schrieb Mark Dexter: > >>>>> Hannes, I think this type of change is better suited for 3.0 > than for > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to > introduce big > >>>>> changes that create backward-compatibility issue in this > version. That > >>>>> is my .02. Mark
> >>>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg > >>>>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> > <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> wrote:
> >>>>> Hi folks, > >>>>> right after JGrid, here another proposal.
> >>>>> Some of you might have seen my router plugin "Molajo > Router", > >>>>> which is a > >>>>> proof of concept of an improved routing system in > Joomla. You can > >>>>> download the plugin from here: > >>>>> http://www.joomlager.de/molajorouter.zip > >>>>> (The plugin currently is not fully functional and the > title is > >>>>> just a > >>>>> working title)
> >>>>> As is described in the pull request, the changes to the > >>>>> framework are > >>>>> actually not that big, the changes to the CMS are a lot > bigger.
> >>>>> The benefits: > >>>>> 1. Routing is a tiny bit faster > >>>>> 2. The routing is more flexible and does not impose some > >>>>> pre-defined > >>>>> rules that can not be switched off. > >>>>> 3. Writing a component router is now object oriented and > if we > >>>>> want to > >>>>> implement the full feature set of the plugin, its also > just one > >>>>> line of > >>>>> code per view and you are done. > >>>>> 4. Helper classes like ContentHelperRoute are not necessary > >>>>> anymore and > >>>>> the related bugs are automatically fixed. > >>>>> 5. URLs are always the same, regardless of them being > sent through > >>>>> ContentHelperRoute or just through JRouter. > >>>>> 6. You can hand over a URL string or an associative > array of URL > >>>>> parameters to JRoute > >>>>> 7. URLs can be changed simply by switching the rules by > which > >>>>> they are > >>>>> build without touching the component router
> >>>>> The downsides: > >>>>> 1. Most of the SEF extensions that touch URLs wont > really work > >>>>> anymore > >>>>> (most likely)
> >>>>> However, the system is backwards compatible for all > components and > >>>>> their > >>>>> router.
> >>>>> I'd like to get this into 2.5 and would like to get > approval for > >>>>> this > >>>>> and instructions how to proceed.
> >>>>> Hannes
> >>>>> -- > >>>>> You received this message because you are subscribed to > the Google > >>>>> Groups "Joomla! CMS Development" group. > >>>>> To post to this group, send an email to > >>>>> joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com> > >>>>> <mailto:joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>>.
Hi Hannes. I suggest you open a tracker issue in the Feature Tracker and then people can test and comment on the feature. Someone needs to make sure that the system tests run correctly. To be considered for 2.5, we have to make sure we have good backward compatibility. Mark
On Sun, Oct 9, 2011 at 7:15 AM, Hannes Papenberg <hackwa...@googlemail.com>wrote:
> Hi Mark, > I prepared a branch that shows the changes to the application- and > platform-router and introduces the important parts of the new system. It > is missing the component routers, as they still have some issues in the > design (like I wrote earlier), but they can be added later. These > changes would already be a big gain for all of us, both in performance > as in flexibility. I don't know if they pass all systemtests, since my > system is not set up to run those tests, but since they create the same > URLs like before, I would vouch for this system.
> I would be happy if the PLT could accept this proposal and as soon as I > have the issues of the component routers worked out, I would be even > happier if you would accept those changes, too. I'm working hard to make > this possible for Joomla 2.5.
> Hannes
> Am 09.10.2011 15:30, schrieb Mark Dexter: > > Hi Hannes. Do you have a working branch that passes all of the system > > tests? Mark
> > On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> > I've been in contact with Matias Griese from the Kunena Team and we > > added several small speed improvements to the system. JRouterSite and > > the rules belonging to that router have been optimized quite a lot. > > JComponentRouter and its rules have also been worked on a bit, > > however I > > discovered a design bug in there, which will require me to rewrite > > quite > > a bit of the rules and JComponentRouter. The idea was, that you could > > register a view under different names with different layouts, so that > > you could have a different behavior for different layouts. > > Unfortunately > > I totally messed that up, but I didn't notice it, because that > feature > > is not used in the core components... I will look into making that > > work > > in the coming days.
> > One big improvement was the removal of the legacy mode in the actual > > router and instead providing a default router that handles the legacy > > mode if necessary. That means that all component routers now use the > > class method, but in case that the component uses legacy routers > (=the > > functions instead of a class) a router "JDefaultRouter" is > registered, > > which either calls the legacy routers or provides a router (that does > > nothing) for extensions that don't have a router. We also > > implemented an > > interface that every new router class has to implement in order to be > > recognized as a new router to prevent legacy issues. (Specifically > > Kunena already had a class named KunenaRouter, which would collide > > with > > this implementation)
> > The general gain by this new router seems to be about 50% on my > > system, > > Matias had even extremely larger gains of 400% and more. Since our > > measuring methods differ a bit and since the actual performance also > > depends on the use cases, you can't really compare the results, > > but the > > tendency is clear that the code is quite a lot faster.
> > Now, what do we have to do to get this (or parts of it) into 2.5?
> > Hannes
> > Am 04.10.2011 12:56, schrieb Rune V. Sjøen: > > > I had a play with this new routing functionality not too long > > ago and > > > I have to say, it is the only router implementation i've ever > looked > > > at (in my test component) without wanting to jump off a bridge. > > If it > > > really is fully backwards-compatible I would very much like to > > see it > > > in 2.5 as we do indeed have at least 3 months of time to test it.
> > > Routers are one of the very last bastions of black magic left and I > > > would consider it a major improvement to the CMS as a whole.
> > > - Rune
> > > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> > wrote: > > >> No, I don't think that it is possible to implement this in such a > > >> backwards compatible manner, since it would more or less require a > > >> complete seperate routing system next to this solution. On the > > other > > >> hand, its not breaking the common extensions, most likely only > > those > > >> that heavily modify the URLs, which would not really be necessary > > >> anymore anyway. This system is much more powerfull.
> > >> Hannes
> > >> Am 03.10.2011 22:46, schrieb G. D. Speer: > > >>>> I would also be very happy if the PLT > > >>>> could (re-)consider this change for 2.5. > > >>> Can this be implemented in 2.5 as a checkbox in Global > > Configuration > > >>> similar, next to the core SEF settings? > > >>> By default 'legacy mode' is 'on' the old router code is active > > and all > > >>> SEF extensions still work and backwards > > >>> compatibility is maintained, but a User can flip it on as > > extensions > > >>> become '2.5 native'. > > >>> In 3.0 the checkbox goes away with the legacy router.
> > >>> Just a thought.
> > >>> ----- Original Message ----- From: "Hannes Papenberg" > > >>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> > > >>> To: <joomla-dev-cms@googlegroups.com > > <mailto:joomla-dev-cms@googlegroups.com>> > > >>> Sent: Monday, October 03, 2011 3:36 AM > > >>> Subject: Re: [jcms] Routing in Joomla
> > >>>> As I already wrote in the JGrid thread, I had some issues > > with getting a > > >>>> Joomlacode account, so I created a branch for these changes > > on github. > > >>>> You can find the implemented router changes here: > > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> > >>>> Its completely installable and works. (I've seen a tiny bug > > with the > > >>>> URLs, but otherwise...) For now, the language files and > > comments in the > > >>>> code are missing, but the rest should already be fine.
> > >>>> I would be happy if people could take a look at this and > > maybe test it > > >>>> with one of their own components. I would also be very happy > > if the PLT > > >>>> could (re-)consider this change for 2.5. Thank you
> > >>>> Hannes
> > >>>> Am 21.09.2011 19 <tel:21.09.2011%2019>:09, schrieb Mark Dexter: > > >>>>> Hannes, I think this type of change is better suited for 3.0 > > than for > > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to > > introduce big > > >>>>> changes that create backward-compatibility issue in this > > version. That > > >>>>> is my .02. Mark
> > >>>>> On Wed, Sep 21, 2011 at 10:00 AM, Hannes Papenberg > > >>>>> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> > > <mailto:hackwa...@googlemail.com > > <mailto:hackwa...@googlemail.com>>> wrote:
> > >>>>> Hi folks, > > >>>>> right after JGrid, here another proposal.
> > >>>>> Some of you might have seen my router plugin "Molajo > > Router", > > >>>>> which is a > > >>>>> proof of concept of an improved routing system in > > Joomla. You can > > >>>>> download the plugin from here: > > >>>>> http://www.joomlager.de/molajorouter.zip > > >>>>> (The plugin currently is not fully functional and the > > title is > > >>>>> just a > > >>>>> working title)
> > >>>>> I'd like to introduce this feature into Joomla and have > > started > > >>>>> with a > > >>>>> pull request for a revised JRouter class: > > >>>>> https://github.com/joomla/joomla-platform/pull/354
> > >>>>> As is described in the pull request, the changes to the > > >>>>> framework are > > >>>>> actually not that big, the changes to the CMS are a lot > > bigger.
> > >>>>> The benefits: > > >>>>> 1. Routing is a tiny bit faster > > >>>>> 2. The routing is more flexible and does not impose some > > >>>>> pre-defined > > >>>>> rules that can not be switched off. > > >>>>> 3. Writing a component router is now object oriented and > > if we > > >>>>> want to > > >>>>> implement the full feature set of the plugin, its also > > just one > > >>>>> line of > > >>>>> code per view and you are done. > > >>>>> 4. Helper classes like ContentHelperRoute are not necessary > > >>>>> anymore and > > >>>>> the related bugs are automatically fixed. > > >>>>> 5. URLs are always the same, regardless of them being > > sent through > > >>>>> ContentHelperRoute or just through JRouter. > > >>>>> 6. You can hand over a URL string or an associative > > array of URL > > >>>>> parameters to JRoute > > >>>>> 7. URLs can be changed simply by switching the rules by > > which > > >>>>> they are > > >>>>> build without touching the component router
> > >>>>> The downsides: > > >>>>> 1. Most of the SEF extensions that touch URLs wont > > really work > > >>>>> anymore > > >>>>> (most likely)
> Hi Hannes. I suggest you open a tracker issue in the Feature Tracker > and then people can test and comment on the feature. Someone needs to > make sure that the system tests run correctly. To be considered for > 2.5, we have to make sure we have good backward compatibility. Mark
> On Sun, Oct 9, 2011 at 7:15 AM, Hannes Papenberg > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> Hi Mark, > I prepared a branch that shows the changes to the application- and > platform-router and introduces the important parts of the new > system. It > is missing the component routers, as they still have some issues > in the > design (like I wrote earlier), but they can be added later. These > changes would already be a big gain for all of us, both in performance > as in flexibility. I don't know if they pass all systemtests, since my > system is not set up to run those tests, but since they create the > same > URLs like before, I would vouch for this system.
> I would be happy if the PLT could accept this proposal and as soon > as I > have the issues of the component routers worked out, I would be even > happier if you would accept those changes, too. I'm working hard > to make > this possible for Joomla 2.5.
> Hannes
> Am 09.10.2011 15:30, schrieb Mark Dexter: > > Hi Hannes. Do you have a working branch that passes all of the > system > > tests? Mark
> > On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> > <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> wrote:
> > I've been in contact with Matias Griese from the Kunena Team > and we > > added several small speed improvements to the system. > JRouterSite and > > the rules belonging to that router have been optimized quite > a lot. > > JComponentRouter and its rules have also been worked on a bit, > > however I > > discovered a design bug in there, which will require me to > rewrite > > quite > > a bit of the rules and JComponentRouter. The idea was, that > you could > > register a view under different names with different > layouts, so that > > you could have a different behavior for different layouts. > > Unfortunately > > I totally messed that up, but I didn't notice it, because > that feature > > is not used in the core components... I will look into > making that > > work > > in the coming days.
> > One big improvement was the removal of the legacy mode in > the actual > > router and instead providing a default router that handles > the legacy > > mode if necessary. That means that all component routers now > use the > > class method, but in case that the component uses legacy > routers (=the > > functions instead of a class) a router "JDefaultRouter" is > registered, > > which either calls the legacy routers or provides a router > (that does > > nothing) for extensions that don't have a router. We also > > implemented an > > interface that every new router class has to implement in > order to be > > recognized as a new router to prevent legacy issues. > (Specifically > > Kunena already had a class named KunenaRouter, which would > collide > > with > > this implementation)
> > The general gain by this new router seems to be about 50% on my > > system, > > Matias had even extremely larger gains of 400% and more. > Since our > > measuring methods differ a bit and since the actual > performance also > > depends on the use cases, you can't really compare the results, > > but the > > tendency is clear that the code is quite a lot faster.
> > Now, what do we have to do to get this (or parts of it) into > 2.5?
> > Hannes
> > Am 04.10.2011 12:56, schrieb Rune V. Sj en: > > > I had a play with this new routing functionality not too long > > ago and > > > I have to say, it is the only router implementation i've > ever looked > > > at (in my test component) without wanting to jump off a > bridge. > > If it > > > really is fully backwards-compatible I would very much like to > > see it > > > in 2.5 as we do indeed have at least 3 months of time to > test it.
> > > Routers are one of the very last bastions of black magic > left and I > > > would consider it a major improvement to the CMS as a whole.
> > > - Rune
> > > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > > <hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> wrote: > > >> No, I don't think that it is possible to implement this > in such a > > >> backwards compatible manner, since it would more or less > require a > > >> complete seperate routing system next to this solution. > On the > > other > > >> hand, its not breaking the common extensions, most likely > only > > those > > >> that heavily modify the URLs, which would not really be > necessary > > >> anymore anyway. This system is much more powerfull.
> > >> Hannes
> > >> Am 03.10.2011 22:46, schrieb G. D. Speer: > > >>>> I would also be very happy if the PLT > > >>>> could (re-)consider this change for 2.5. > > >>> Can this be implemented in 2.5 as a checkbox in Global > > Configuration > > >>> similar, next to the core SEF settings? > > >>> By default 'legacy mode' is 'on' the old router code is > active > > and all > > >>> SEF extensions still work and backwards > > >>> compatibility is maintained, but a User can flip it on as > > extensions > > >>> become '2.5 native'. > > >>> In 3.0 the checkbox goes away with the legacy router.
> > >>> Just a thought.
> > >>> ----- Original Message ----- From: "Hannes Papenberg" > > >>> <hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> > > >>> To: <joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com> > > <mailto:joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>>> > > >>> Sent: Monday, October 03, 2011 3:36 AM > > >>> Subject: Re: [jcms] Routing in Joomla
> > >>>> As I already wrote in the JGrid thread, I had some issues > > with getting a > > >>>> Joomlacode account, so I created a branch for these changes > > on github. > > >>>> You can find the implemented router changes here: > > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> > >>>> Its completely installable and works. (I've seen a tiny bug > > with the > > >>>> URLs, but otherwise...) For now, the language files and > > comments in the > > >>>> code are missing, but the rest should already be fine.
> > >>>> I would be happy if people could take a look at this and > > maybe test it > > >>>> with one of their own components. I would also be very > happy > > if the PLT > > >>>> could (re-)consider this change for 2.5. Thank you
> > >>>> Hannes
> > >>>> Am 21.09.2011 19 <tel:21.09.2011%2019> > <tel:21.09.2011%2019>:09, schrieb Mark Dexter: > > >>>>> Hannes, I think this type of change is better suited > for 3.0 > > than for > > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to > > introduce big > > >>>>> changes that create backward-compatibility issue in this > > version. That > > >>>>> is my .02. Mark
> > >>>>> Hi folks, > > >>>>> right after JGrid, here another proposal.
> > >>>>> Some of you might have seen my router plugin "Molajo > > Router", > > >>>>> which is a > > >>>>> proof of concept of an improved routing system in > > Joomla. You can > > >>>>> download the plugin from here:
Hi folks, its been a while and so far I wasn't able to find the time to fix the component routers the way that I'd like them to be. However, I'd like to propose the current status of my branch for inclusion into 2.5. This change rewrites JRouter and makes it a lot faster and more flexible. It also allows component routers to be classes instead of just simple functions, but it does not force this. For components, this change is completely backwards compatible, its just the SEF components that interact with the Joomla routing that will have to be changed.
I'd love to deliver the full package including the component routers, but since time is of the essence, I'd like to propose this reduced version of the router-rewrite. Maybe I find the time to get the component routers fixed, too, but it would be a shame if this change could not be implemented now because of this delay.
The code in the branch is final, can be tested and merged into trunk. If the CMS approves of these changes, Andrew said he would look favourably onto adopting this code for the platform. In that case I will create a new pull request. So please test and hopefully approve. :-)
> Hi Hannes. I suggest you open a tracker issue in the Feature Tracker > and then people can test and comment on the feature. Someone needs to > make sure that the system tests run correctly. To be considered for > 2.5, we have to make sure we have good backward compatibility. Mark
> On Sun, Oct 9, 2011 at 7:15 AM, Hannes Papenberg > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> Hi Mark, > I prepared a branch that shows the changes to the application- and > platform-router and introduces the important parts of the new > system. It > is missing the component routers, as they still have some issues > in the > design (like I wrote earlier), but they can be added later. These > changes would already be a big gain for all of us, both in performance > as in flexibility. I don't know if they pass all systemtests, since my > system is not set up to run those tests, but since they create the > same > URLs like before, I would vouch for this system.
> I would be happy if the PLT could accept this proposal and as soon > as I > have the issues of the component routers worked out, I would be even > happier if you would accept those changes, too. I'm working hard > to make > this possible for Joomla 2.5.
> Hannes
> Am 09.10.2011 15:30, schrieb Mark Dexter: > > Hi Hannes. Do you have a working branch that passes all of the > system > > tests? Mark
> > On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> > <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> wrote:
> > I've been in contact with Matias Griese from the Kunena Team > and we > > added several small speed improvements to the system. > JRouterSite and > > the rules belonging to that router have been optimized quite > a lot. > > JComponentRouter and its rules have also been worked on a bit, > > however I > > discovered a design bug in there, which will require me to > rewrite > > quite > > a bit of the rules and JComponentRouter. The idea was, that > you could > > register a view under different names with different > layouts, so that > > you could have a different behavior for different layouts. > > Unfortunately > > I totally messed that up, but I didn't notice it, because > that feature > > is not used in the core components... I will look into > making that > > work > > in the coming days.
> > One big improvement was the removal of the legacy mode in > the actual > > router and instead providing a default router that handles > the legacy > > mode if necessary. That means that all component routers now > use the > > class method, but in case that the component uses legacy > routers (=the > > functions instead of a class) a router "JDefaultRouter" is > registered, > > which either calls the legacy routers or provides a router > (that does > > nothing) for extensions that don't have a router. We also > > implemented an > > interface that every new router class has to implement in > order to be > > recognized as a new router to prevent legacy issues. > (Specifically > > Kunena already had a class named KunenaRouter, which would > collide > > with > > this implementation)
> > The general gain by this new router seems to be about 50% on my > > system, > > Matias had even extremely larger gains of 400% and more. > Since our > > measuring methods differ a bit and since the actual > performance also > > depends on the use cases, you can't really compare the results, > > but the > > tendency is clear that the code is quite a lot faster.
> > Now, what do we have to do to get this (or parts of it) into > 2.5?
> > Hannes
> > Am 04.10.2011 12:56, schrieb Rune V. Sjᅵen: > > > I had a play with this new routing functionality not too long > > ago and > > > I have to say, it is the only router implementation i've > ever looked > > > at (in my test component) without wanting to jump off a > bridge. > > If it > > > really is fully backwards-compatible I would very much like to > > see it > > > in 2.5 as we do indeed have at least 3 months of time to > test it.
> > > Routers are one of the very last bastions of black magic > left and I > > > would consider it a major improvement to the CMS as a whole.
> > > - Rune
> > > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > > <hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> wrote: > > >> No, I don't think that it is possible to implement this > in such a > > >> backwards compatible manner, since it would more or less > require a > > >> complete seperate routing system next to this solution. > On the > > other > > >> hand, its not breaking the common extensions, most likely > only > > those > > >> that heavily modify the URLs, which would not really be > necessary > > >> anymore anyway. This system is much more powerfull.
> > >> Hannes
> > >> Am 03.10.2011 22:46, schrieb G. D. Speer: > > >>>> I would also be very happy if the PLT > > >>>> could (re-)consider this change for 2.5. > > >>> Can this be implemented in 2.5 as a checkbox in Global > > Configuration > > >>> similar, next to the core SEF settings? > > >>> By default 'legacy mode' is 'on' the old router code is > active > > and all > > >>> SEF extensions still work and backwards > > >>> compatibility is maintained, but a User can flip it on as > > extensions > > >>> become '2.5 native'. > > >>> In 3.0 the checkbox goes away with the legacy router.
> > >>> Just a thought.
> > >>> ----- Original Message ----- From: "Hannes Papenberg" > > >>> <hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com > <mailto:hackwa...@googlemail.com>>> > > >>> To: <joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com> > > <mailto:joomla-dev-cms@googlegroups.com > <mailto:joomla-dev-cms@googlegroups.com>>> > > >>> Sent: Monday, October 03, 2011 3:36 AM > > >>> Subject: Re: [jcms] Routing in Joomla
> > >>>> As I already wrote in the JGrid thread, I had some issues > > with getting a > > >>>> Joomlacode account, so I created a branch for these changes > > on github. > > >>>> You can find the implemented router changes here: > > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> > >>>> Its completely installable and works. (I've seen a tiny bug > > with the > > >>>> URLs, but otherwise...) For now, the language files and > > comments in the > > >>>> code are missing, but the rest should already be fine.
> > >>>> I would be happy if people could take a look at this and > > maybe test it > > >>>> with one of their own components. I would also be very > happy > > if the PLT > > >>>> could (re-)consider this change for 2.5. Thank you
> > >>>> Hannes
> > >>>> Am 21.09.2011 19 <tel:21.09.2011%2019> > <tel:21.09.2011%2019>:09, schrieb Mark Dexter: > > >>>>> Hannes, I think this type of change is better suited > for 3.0 > > than for > > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to > > introduce big > > >>>>> changes that create backward-compatibility issue in
> Hi folks, > its been a while and so far I wasn't able to find the time to fix the > component routers the way that I'd like them to be. However, I'd like to > propose the current status of my branch for inclusion into 2.5. This > change rewrites JRouter and makes it a lot faster and more flexible. It > also allows component routers to be classes instead of just simple > functions, but it does not force this. For components, this change is > completely backwards compatible, its just the SEF components that > interact with the Joomla routing that will have to be changed.
> I'd love to deliver the full package including the component routers, > but since time is of the essence, I'd like to propose this reduced > version of the router-rewrite. Maybe I find the time to get the > component routers fixed, too, but it would be a shame if this change > could not be implemented now because of this delay.
> The code in the branch is final, can be tested and merged into trunk. If > the CMS approves of these changes, Andrew said he would look favourably > onto adopting this code for the platform. In that case I will create a > new pull request. So please test and hopefully approve. :-)
> Hannes
> Am 09.10.2011 19:05, schrieb Mark Dexter: >> Hi Hannes. I suggest you open a tracker issue in the Feature Tracker >> and then people can test and comment on the feature. Someone needs to >> make sure that the system tests run correctly. To be considered for >> 2.5, we have to make sure we have good backward compatibility. Mark
>> On Sun, Oct 9, 2011 at 7:15 AM, Hannes Papenberg >> <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
>> Hi Mark, >> I prepared a branch that shows the changes to the application- and >> platform-router and introduces the important parts of the new >> system. It >> is missing the component routers, as they still have some issues >> in the >> design (like I wrote earlier), but they can be added later. These >> changes would already be a big gain for all of us, both in performance >> as in flexibility. I don't know if they pass all systemtests, since my >> system is not set up to run those tests, but since they create the >> same >> URLs like before, I would vouch for this system.
>> I would be happy if the PLT could accept this proposal and as soon >> as I >> have the issues of the component routers worked out, I would be even >> happier if you would accept those changes, too. I'm working hard >> to make >> this possible for Joomla 2.5.
>> Hannes
>> Am 09.10.2011 15:30, schrieb Mark Dexter: >> > Hi Hannes. Do you have a working branch that passes all of the >> system >> > tests? Mark
>> > On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg >> > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> >> <mailto:hackwa...@googlemail.com >> <mailto:hackwa...@googlemail.com>>> wrote:
>> > I've been in contact with Matias Griese from the Kunena Team >> and we >> > added several small speed improvements to the system. >> JRouterSite and >> > the rules belonging to that router have been optimized quite >> a lot. >> > JComponentRouter and its rules have also been worked on a bit, >> > however I >> > discovered a design bug in there, which will require me to >> rewrite >> > quite >> > a bit of the rules and JComponentRouter. The idea was, that >> you could >> > register a view under different names with different >> layouts, so that >> > you could have a different behavior for different layouts. >> > Unfortunately >> > I totally messed that up, but I didn't notice it, because >> that feature >> > is not used in the core components... I will look into >> making that >> > work >> > in the coming days.
>> > One big improvement was the removal of the legacy mode in >> the actual >> > router and instead providing a default router that handles >> the legacy >> > mode if necessary. That means that all component routers now >> use the >> > class method, but in case that the component uses legacy >> routers (=the >> > functions instead of a class) a router "JDefaultRouter" is >> registered, >> > which either calls the legacy routers or provides a router >> (that does >> > nothing) for extensions that don't have a router. We also >> > implemented an >> > interface that every new router class has to implement in >> order to be >> > recognized as a new router to prevent legacy issues. >> (Specifically >> > Kunena already had a class named KunenaRouter, which would >> collide >> > with >> > this implementation)
>> > The general gain by this new router seems to be about 50% on my >> > system, >> > Matias had even extremely larger gains of 400% and more. >> Since our >> > measuring methods differ a bit and since the actual >> performance also >> > depends on the use cases, you can't really compare the results, >> > but the >> > tendency is clear that the code is quite a lot faster.
>> > Now, what do we have to do to get this (or parts of it) into >> 2.5?
>> > Hannes
>> > Am 04.10.2011 12:56, schrieb Rune V. Sj en: >> > > I had a play with this new routing functionality not too long >> > ago and >> > > I have to say, it is the only router implementation i've >> ever looked >> > > at (in my test component) without wanting to jump off a >> bridge. >> > If it >> > > really is fully backwards-compatible I would very much like to >> > see it >> > > in 2.5 as we do indeed have at least 3 months of time to >> test it.
>> > > Routers are one of the very last bastions of black magic >> left and I >> > > would consider it a major improvement to the CMS as a whole.
>> > > - Rune
>> > > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg >> > > <hackwa...@googlemail.com >> <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com >> <mailto:hackwa...@googlemail.com>>> wrote: >> > >> No, I don't think that it is possible to implement this >> in such a >> > >> backwards compatible manner, since it would more or less >> require a >> > >> complete seperate routing system next to this solution. >> On the >> > other >> > >> hand, its not breaking the common extensions, most likely >> only >> > those >> > >> that heavily modify the URLs, which would not really be >> necessary >> > >> anymore anyway. This system is much more powerfull.
>> > >> Hannes
>> > >> Am 03.10.2011 22:46, schrieb G. D. Speer: >> > >>>> I would also be very happy if the PLT >> > >>>> could (re-)consider this change for 2.5. >> > >>> Can this be implemented in 2.5 as a checkbox in Global >> > Configuration >> > >>> similar, next to the core SEF settings? >> > >>> By default 'legacy mode' is 'on' the old router code is >> active >> > and all >> > >>> SEF extensions still work and backwards >> > >>> compatibility is maintained, but a User can flip it on as >> > extensions >> > >>> become '2.5 native'. >> > >>> In 3.0 the checkbox goes away with the legacy router.
>> > >>> Just a thought.
>> > >>> ----- Original Message ----- From: "Hannes Papenberg" >> > >>> <hackwa...@googlemail.com >> <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com >> <mailto:hackwa...@googlemail.com>>> >> > >>> To: <joomla-dev-cms@googlegroups.com >> <mailto:joomla-dev-cms@googlegroups.com> >> > <mailto:joomla-dev-cms@googlegroups.com >> <mailto:joomla-dev-cms@googlegroups.com>>> >> > >>> Sent: Monday, October 03, 2011 3:36 AM >> > >>> Subject: Re: [jcms] Routing in Joomla
>> > >>>> As I already wrote in the JGrid thread, I had some issues >> > with getting a >> > >>>> Joomlacode account, so I created a branch for these changes >> > on github. >> > >>>> You can find the implemented router changes here: >> > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
>> > >>>> Its completely installable and works. (I've seen a tiny bug >> > with the >> > >>>> URLs, but otherwise...) For now, the language files and >> > comments in the >> > >>>> code are missing, but the rest should already be fine.
>> > >>>> I would be happy if people could take a look at this and >> > maybe test it >> > >>>> with one of their own components. I would also be very >> happy >> > if the PLT >> > >>>> could (re-)consider this change for 2.5. Thank you
Hannes, first of all, no one has documented anything on that tracker item. It is premature for any decision until some people have tested it out. Second, as mentioned before, version 2.5 is a LTS and I am not in favor of anything that might cause b/c issues or new bugs. That's my .02. Mark
On Sun, Oct 9, 2011 at 10:52 AM, Hannes Papenberg <hackwa...@googlemail.com>wrote:
> Am 09.10.2011 19:05, schrieb Mark Dexter: > > Hi Hannes. I suggest you open a tracker issue in the Feature Tracker > > and then people can test and comment on the feature. Someone needs to > > make sure that the system tests run correctly. To be considered for > > 2.5, we have to make sure we have good backward compatibility. Mark
> > On Sun, Oct 9, 2011 at 7:15 AM, Hannes Papenberg > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com>> wrote:
> > Hi Mark, > > I prepared a branch that shows the changes to the application- and > > platform-router and introduces the important parts of the new > > system. It > > is missing the component routers, as they still have some issues > > in the > > design (like I wrote earlier), but they can be added later. These > > changes would already be a big gain for all of us, both in > performance > > as in flexibility. I don't know if they pass all systemtests, since > my > > system is not set up to run those tests, but since they create the > > same > > URLs like before, I would vouch for this system.
> > I would be happy if the PLT could accept this proposal and as soon > > as I > > have the issues of the component routers worked out, I would be even > > happier if you would accept those changes, too. I'm working hard > > to make > > this possible for Joomla 2.5.
> > Hannes
> > Am 09.10.2011 15:30, schrieb Mark Dexter: > > > Hi Hannes. Do you have a working branch that passes all of the > > system > > > tests? Mark
> > > On Sun, Oct 9, 2011 at 4:10 AM, Hannes Papenberg > > > <hackwa...@googlemail.com <mailto:hackwa...@googlemail.com> > > <mailto:hackwa...@googlemail.com > > <mailto:hackwa...@googlemail.com>>> wrote:
> > > I've been in contact with Matias Griese from the Kunena Team > > and we > > > added several small speed improvements to the system. > > JRouterSite and > > > the rules belonging to that router have been optimized quite > > a lot. > > > JComponentRouter and its rules have also been worked on a bit, > > > however I > > > discovered a design bug in there, which will require me to > > rewrite > > > quite > > > a bit of the rules and JComponentRouter. The idea was, that > > you could > > > register a view under different names with different > > layouts, so that > > > you could have a different behavior for different layouts. > > > Unfortunately > > > I totally messed that up, but I didn't notice it, because > > that feature > > > is not used in the core components... I will look into > > making that > > > work > > > in the coming days.
> > > One big improvement was the removal of the legacy mode in > > the actual > > > router and instead providing a default router that handles > > the legacy > > > mode if necessary. That means that all component routers now > > use the > > > class method, but in case that the component uses legacy > > routers (=the > > > functions instead of a class) a router "JDefaultRouter" is > > registered, > > > which either calls the legacy routers or provides a router > > (that does > > > nothing) for extensions that don't have a router. We also > > > implemented an > > > interface that every new router class has to implement in > > order to be > > > recognized as a new router to prevent legacy issues. > > (Specifically > > > Kunena already had a class named KunenaRouter, which would > > collide > > > with > > > this implementation)
> > > The general gain by this new router seems to be about 50% on my > > > system, > > > Matias had even extremely larger gains of 400% and more. > > Since our > > > measuring methods differ a bit and since the actual > > performance also > > > depends on the use cases, you can't really compare the results, > > > but the > > > tendency is clear that the code is quite a lot faster.
> > > Now, what do we have to do to get this (or parts of it) into > > 2.5?
> > > Hannes
> > > Am 04.10.2011 12:56, schrieb Rune V. Sjøen: > > > > I had a play with this new routing functionality not too long > > > ago and > > > > I have to say, it is the only router implementation i've > > ever looked > > > > at (in my test component) without wanting to jump off a > > bridge. > > > If it > > > > really is fully backwards-compatible I would very much like > to > > > see it > > > > in 2.5 as we do indeed have at least 3 months of time to > > test it.
> > > > Routers are one of the very last bastions of black magic > > left and I > > > > would consider it a major improvement to the CMS as a whole.
> > > > - Rune
> > > > On Tue, Oct 4, 2011 at 8:37 AM, Hannes Papenberg > > > > <hackwa...@googlemail.com > > <mailto:hackwa...@googlemail.com> <mailto:hackwa...@googlemail.com > > <mailto:hackwa...@googlemail.com>>> wrote: > > > >> No, I don't think that it is possible to implement this > > in such a > > > >> backwards compatible manner, since it would more or less > > require a > > > >> complete seperate routing system next to this solution. > > On the > > > other > > > >> hand, its not breaking the common extensions, most likely > > only > > > those > > > >> that heavily modify the URLs, which would not really be > > necessary > > > >> anymore anyway. This system is much more powerfull.
> > > >> Hannes
> > > >> Am 03.10.2011 22:46, schrieb G. D. Speer: > > > >>>> I would also be very happy if the PLT > > > >>>> could (re-)consider this change for 2.5. > > > >>> Can this be implemented in 2.5 as a checkbox in Global > > > Configuration > > > >>> similar, next to the core SEF settings? > > > >>> By default 'legacy mode' is 'on' the old router code is > > active > > > and all > > > >>> SEF extensions still work and backwards > > > >>> compatibility is maintained, but a User can flip it on as > > > extensions > > > >>> become '2.5 native'. > > > >>> In 3.0 the checkbox goes away with the legacy router.
> > > >>>> As I already wrote in the JGrid thread, I had some issues > > > with getting a > > > >>>> Joomlacode account, so I created a branch for these > changes > > > on github. > > > >>>> You can find the implemented router changes here: > > > >>>> https://github.com/Hackwar/joomla-cms/tree/jrouter
> > > >>>> Its completely installable and works. (I've seen a tiny > bug > > > with the > > > >>>> URLs, but otherwise...) For now, the language files and > > > comments in the > > > >>>> code are missing, but the rest should already be fine.
> > > >>>> I would be happy if people could take a look at this and > > > maybe test it > > > >>>> with one of their own components. I would also be very > > happy > > > if the PLT > > > >>>> could (re-)consider this change for 2.5. Thank you
> > > >>>> Hannes
> > > >>>> Am 21.09.2011 19 <tel:21.09.2011%2019> > > <tel:21.09.2011%2019>:09, schrieb Mark Dexter: > > > >>>>> Hannes, I think this type of change is better suited > > for 3.0 > > > than for > > > >>>>> 2.5. Version 2.5 is the LTS release and we don't want to > > > introduce big > > > >>>>> changes that create backward-compatibility issue in this > > > version. That > > > >>>>> is my .02. Mark