Routing: JComponentRouterRulesMenu to find right Itemid

[Hackwar]

This rule implements finding the right Itemid as a generic rule for all component routers that extend from JComponentRouterView. It makes most of the parts of the *HelperRoute classes obsolete.

How to test

• Apply this change
• Change the router of com_content by replacing

class ContentRouter extends JComponentRouterBase
{

with

class ContentRouter extends JComponentRouterView
{
    function __construct($app = null, $menu = null) {

        $categories = new JComponentRouterViewconfiguration('categories');
        $categories->setKey('id');
        $this->registerView($categories);
        $category = new JComponentRouterViewconfiguration('category');
        $category->setKey('id')->setParent($categories, 'id')->setNestable()->addLayout('blog');
        $this->registerView($category);
        $article = new JComponentRouterViewconfiguration('article');
        $article->setKey('id')->setParent($category, 'catid');
        $this->registerView($article);
        $this->registerView(new JComponentRouterViewconfiguration('archive'));
        $this->registerView(new JComponentRouterViewconfiguration('featured'));
        $this->registerView(new JComponentRouterViewconfiguration('form'));

        parent::__construct($app, $menu);
        $this->attachRule(new JComponentRouterRulesMenu($this));
    }

    public function getCategorySegment($id, $query)
    {
        $category = JCategories::getInstance($this->getName())->get($id);
        if ($category)
        {
            return array_reverse($category->getPath());
        }

        return array();
    }

    public function getCategoriesSegment($id, $query)
    {
        return $this->getCategorySegment($id, $query);
    }

    public function getArticleSegment($id, $query)
    {
        return array($id);
    }

• Comment line 62 and 111 from /components/com_content/helpers/route.php to disable the lookup of the Itemid there.
• See that the right menu items are still found for the items

This was updated on May 22nd 2015. All discussions prior to that point have either been integrated or are obsolete.

This was made possible through the generous donation of the people mentioned in the following link via an Indiegogo campaign: http://joomlager.de/crowdfunding/5-contributors

[johanjanssens]

@Hackwar By having this method your are coupling the categories implementation to the routing API. Do we need to have a this method here ? Wouldn't this be something either for a more specialised router that understands categories, or for a specific implementation in a component router ?

[johanjanssens]

@Hackwar Would consider calling this method registerView() instead of register to better declare it's purpose. All other view related methods in the proposed API also have 'View' in their name which makes it easier to see the correlation between the methods.

[johanjanssens]

@Hackwar see my other comment about the getCategory() method. If you don't add it you also don't need to add the getName() method. Additionally you could ask yourself if this method has use outside of the implementation as proposed in getCategory(). If not it might be better to remove this and implement the logic in getCategory().

[johanjanssens]

@Hackwar By making the property public you are allowing it to be changed from the outside. Is that intentional ? Couldn't this result in unwanted side effects ?

[johanjanssens]

@Hackwar Bit of a code smell here. You should try to check against and interface and not an implementation. This gives developers more flexibility, Eg would be better if it would be

public function __construct(JComponentRouterAdvancedInterface $router)

[johanjanssens]

@Hackwar Do you want to allow this ? By letting any Itemid being passed in a developer can hijack a route. Connecting a component to any random Itemid. Shouldn't that be prevented ?

[johanjanssens]

@Hackwar As commented before. If the you need dummy methods here you can ask yourself if you really need those methods in the interface at all ?

[johanjanssens]

@Hackwar As commented before. If the you need dummy methods here you can ask yourself if you really need those methods in the interface at all ?

[johanjanssens]

@Hackwar Since you are using the result of buildLookup() in this code block I would make buildLookup() return the lookup array. It can still cache it but it makes sense it returns it for use in the code block here.

[johanjanssens]

@Hackwar Not sure about the proposed function name here. getMenuItemMap() might be a better name to reflect what this method is doing. I would also not make it return void but return the result instead. The result could be filtered by the language passed in through the method parameter.

[johanjanssens]

@Hackwar Getting the active menu item is a common operation in a router. Could consider adding a getActiveMenuItem() method to return this.

[johanjanssens]

@Hackwar Getting the default menu item is a common operation in a router. Could consider adding a getDefaultMenuItem() method to return this.

[johanjanssens]

@Hackwar Does this need to be accessible from object scope ? If not might consider making it private to prevent developers for using it directly ?

[johanjanssens]

@Hackwar Did a first pass of the proposed code and added inline comments. I like the simplicity that is being proposed.

[weeblr-dev]

Hi Hannes,

How can 3rd party extensions disable/bypass those rules that could be added by components, or even if they make their way int Joomla core pre-4.0? or at least are you storing the original request somewhere so that we can revert any change made by those rules, as discussed in #5264?

"By letting any Itemid being passed in a developer can hijack a route. Connecting a component to any random Itemid. Shouldn't that be prevented ? ": Not random, but manually selected by user - as allowed by most SEF extensions, yes, absolutely.

Cheers

[Hackwar]

I guess JComponentRouterAdvanced will get a "removeRule()" method, that takes a rule that you can first find with a "getRules()" method and remove that from the rules to process again. Remember that you will have the buildpreprocess() step, where you can attach yourself already to, to for example add your stuff to the query.

[weeblr-dev]

This is not about attaching things to the query. This is about being able to undo things that other rules have attached, or any change they might have done to the original query. In other words not being trapped again in the problems the language filter plugins rules have created (not by themselves, but by being set in stone and unmodifiable)
getRules() and removeRules() sound good, as long as we have an event we can use to be reasonably sure all rules have been attached (so we can also be sure to remove them all). Too bad there isn't an onBeforeRoute...
I guess even if we use onAfterInitialise, we can rely on the plugins ordering so we should be good in most cases.

[Hackwar]

For the time being, I would add all rules in the component routers constructors, so when you cycle through all components and then use JRouterSite::getComponentRouter() and do your own stuff by adding/removing rules again in onAfterInitialise, you would be good. Since I would like to have more than one set of component rules, I could also see us having a -1 option that disables all the rule-adding in the constructor and you can do your magic.

Regarding the language filter plugin: I hope that it is a lot saner now when #5140 is merged. I can't really think of anything else that you could want in that regard...

[weeblr-dev]

Hi Hannes,
Let me clear that up first: I have no problem with the language filter rules, how they were working or whatever. The only issue was that we couldn't bypass them, or even know what the actual original request was and what the language filter rules had done to it. The same would apply to any extension adding rules, whether for parsing or building.
It was a bit more difficult with the language filter because its parse rule is always executed first, regardless of the actual system plugins ordering set by user or otherwise.

As for adding/removing rules on onAfterInitialise, I can request users to be sure my system plugin is the last one in order (and I can check that periodically) and thus be sure to remove all rules that may have been added by other extensions. An onBeforeRoute event would be more secure, but maybe not worth the added perf cost I guess. I'll make sure to do some trials in due time.

[johanjanssens]

@Hackwar About setName/setViewName() I missed those changes. Looking much better indeed API wise.

About JComponentRouterViewconfiguration vs JComponentRouterView. I understand, still not 100% happy with JComponentRouterViewconfiguration, any alternatives ? JComponentRouterConfig maybe, or JComponentRouterContext ?

[johanjanssens]

@Hackwar Oki, fair comments. Additional feedback :

• I still don't feel category handling should be in the this router. It would make more sense to me that this router is part of the categories component. It could be an abstract router one can extend from. By the chosen implementation you are tightly coupling categorie handling with routing.
• I would consider renaming JComponentRouterAdvanced to JComponentRouterView. Advanced isn't a very concrete name. This router deals specifically with component routing based on registering views. Would make sense the name reflect this, this also matches with the JComponentRouterViewconfigurationObject.

[Hackwar]

I've updated this PR to work with the changed JComponentRouterView class. Please test.

[dgrammatiko]

@Hackwar what shall we look for the output urls? just B/C or something more/else?

[Hackwar]

simply B/C. This should not change the URLs.

[Hackwar]

I've combined the changes from this and all other routing related PRs into a new PR: #7615 Please review and comment in the new PR. I'm closing this one, so that we can focuse on the new PR.