We discussed this in the JBS and I was told to remove the constructor.

Setting this RTC on review as Hannes states it was going to be new to Joomla 3.4 so no b/c implications and the code isn't being used anywhere

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5234.

@Hackwar Why does JComponentRouterRulesInterface also have a build() and parse() method ? If it uses the same interface as the router you can argue that it is a router, or that it should extend from the JComponentRouterInterface ?

You are right, I will have to think about this one a bit.

I see where you are going with this. Instead of implementing a rules object that needs to be injected. You could consider using a pub/sub approach ('Don't call use we will call you') for the router and routing rules. The router would need to trigger 4 events :

• onBeforeBuildRoute
• onAfterBuildRoute
• onBeforeParseRoute
• onAfterParseRoute

You could consider using Joomla plugin system and add a 'router' plugin group that developers can leverage to extend the routing in Joomla.

To make everything fully backwards compatible triggering of the events could be done by injecting callbacks. Technically you could inject 4 closure into the router to handle this. Presto, pluggable routing out of the box that would run along side the current system. You would be augmenting the API this way without breaking anything.

-- Just an off the bat idea.

I decided against using the Plugin system since attaching callback rules seems more lightweight to me than invoking the complete plugin management stack here. You will already be able to attach your own rules to the component router via a plugin and onAfterInitialise. Likewise will you be able to remove rules from a component router at that point, in case we decide to force a set of default rules. I'm not 100% sure on that part yet.

You can see that a little bit in the language filter plugin in #5140, where I only attach the rule to remove the &lang= query part when SEF URLs are enabled and with non-SEF URLs it replaces the lang ISO code with the lang SEF code instead.

Hi Hannes, callbacks are more lightweight indeed. Joomla however isn't about being the fastest. Latest changed to the event system already make it faster then in the 1.5 days. I'm not too worried about speed here. The cleaner the API the easier for developers to extend the code. Extendability always brings a performance tradeoff.

Looking at the language filter plugin this is actually a very good example of a routing plugin and it could benefit from an event driven approach. The system plugin approach works but is a more crude solution.