Routing: Discover Itemid in Router for com_content

[Hackwar]

This change moves the code that discovers the right Itemid for this content item from the ContentHelperRoute class into the component router. This means that also URLs in the content get the right Itemid and we don't need to pre-calculate them during the time the article was written. It also means that all URLs are treated correctly and not just those going through ContentHelperRoute. At the same time, this also fixes the Itemid discovery for form views in com_content. If you have a menu item that points to a create article view, this menu item is taken for editing articles in the frontend instead of the homepage.

This makes ContentHelperRoute obsolete, but I did not change that class yet, since that would interfer with PR #5140. So #5140 should be merged first in order to test this one properly. That means that also #5264 and #5276 should be merged before this one.

This only touches com_content for the moment. Further components can be done at a later stage. I also wanted to keep it testable, since no one could be expected to test all components at once.

It should be made clear that this ultimately changes the behavior of ContentHelperRoute in the way that it removes the Itemid from its output. For a sane developer that would not be a problem, since he would not mess with the output any further, but I have the gut feeling that there are developers out there, that take an article, let ContentHelperRoute calculate the right Itemid and then parse that Itemid back from the URL that is returned by ContentHelperRoute. The question is, how far we are going to go to prevent people from shooting themselfs in the foot... (Read: Doing the above described thing would be Homer-Simpson-stabs-himself-with-a-knife-in-the-hand-stupid)

To give you a little insight into the future: In one of the next steps, this code will be moved into a component router rule, which is generalized and where one code works for all components. At that point, this code is removed again from the component routers.

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

[dgrammatiko]

this code will be moved into a component router rule, which is generalized and where one code works for all components. At that point, this code is removed again from the component routers.

Hannes instead of moving this code block around (deprecating it twice, i guess) why don’t you directly put them in the rules (deprecating only the ContentHelperRoute)?

[dgrammatiko]

this code will be moved into a component router rule, which is generalized and where one code works for all components. At that point, this code is removed again from the component routers.

Hannes instead of moving this code block around (deprecating it twice, i guess) why don’t you directly put them in the rules (deprecating only the ContentHelperRoute)?

[Hackwar]

The new code would not need to be deprecated, since the preprocess method will still be present in the later version and still do the same work, just in a base class. I'm simply providing this, since I will need more time to get the router rule done correctly. It is not so much about the code to be written, but to write it in a way that will be sane and not cause us grieve in the future. I've got the code ready, but I'm simply not 100% sure that the way I'm going there is the right one. I hope that this could be merged into 3.4 already.

[Hackwar]

The new code would not need to be deprecated, since the preprocess method will still be present in the later version and still do the same work, just in a base class. I'm simply providing this, since I will need more time to get the router rule done correctly. It is not so much about the code to be written, but to write it in a way that will be sane and not cause us grieve in the future. I've got the code ready, but I'm simply not 100% sure that the way I'm going there is the right one. I hope that this could be merged into 3.4 already.

[Hackwar]

I've decided to implement the ContentHelperRoute changes, too, in order to make the testing realistic. In worst case, I have to update the other PR and solve the conflicts there...

[Hackwar]

I've decided to implement the ContentHelperRoute changes, too, in order to make the testing realistic. In worst case, I have to update the other PR and solve the conflicts there...

[Hackwar]

Oh, and I also declared the findItem() method as private. That means that we can drop the method as soon as the component router rule is ready.

[Hackwar]

Oh, and I also declared the findItem() method as private. That means that we can drop the method as soon as the component router rule is ready.

[johanjanssens]

@Hackwar Good work. Couple points of feedback.

1. findItem() : I would consider calling the method findItemId(). Additionally wouldn't it make sense to move this method to JComponentRouterBase so each router has access to it ?
2. preprocess() : I would consider renaming that to addItemid() as that is exactly what the function does.

Thoughts ?

[johanjanssens]

@Hackwar Good work. Couple points of feedback.

1. findItem() : I would consider calling the method findItemId(). Additionally wouldn't it make sense to move this method to JComponentRouterBase so each router has access to it ?
2. preprocess() : I would consider renaming that to addItemid() as that is exactly what the function does.

Thoughts ?

[Hackwar]

Hi @johanjanssens, thanks for your input. The method findItem() is, as I described, just a placeholder until I implemented the generalized rule properly. When that will be the case, the base class of the core components will also be changed to a new class named JComponentRouterAdvanced, which allows to provide a lot less code for a standard component router and do the whole thing with the rule system that I talked about all the time. That is also why I declared it private. That way we can remove that method again as soon as the other solution is ready.
Regarding preprocess(): That method is not only meant to be used for the Itemid. Its one of the main uses, but it would also allow you to prepare the component query in general, add data to it where necessary. For example adding the right slug if its not present for an article. That is why I called it preprocess. Preprocess is also called regardless of SEF or non-SEF URLs.
Renaming that method now will be very difficult, since it was already in the release of Joomla 3.3 and thus is out in the wild.

[johanjanssens]

Thanks Hannes :

1. findItem() agreed. Still not a bad idea to call it findItemid() no ? It reflects better what the method does. You can keep it private for now until you found the best way to resolve this. If not the method could also be made public and added to the interface later. I agree this is nothing something to be solved right now.
2. Agreed. Was unaware this method already existed. I see it also part of the interface so all good there. 👍

[johanjanssens]

Not sure you should change the visibility to private here. You can consider this a breaking API change. Would mark the whole class or only this function as deprecated for 4.0.

[johanjanssens]

Not sure you should change the visibility to private here. You can consider this a breaking API change. Would mark the whole class or only this function as deprecated for 4.0.

[Hackwar]

This method is new and has not been in a release so far. That allows us to do this change here. I've been marking this as private, since it allows us to drop this method as soon as the generalized code is ready.

[johanjanssens]

Ah got it, i was looking at the wrong file. Moved my comment up.

About this method. I would consider adding it to a JComponentRouterInterface and renaming to findItemId() making it public. Getting the Itemid is a integral part of the routing process and of the router. Having the method in the interface will communicate this to the developer implementing his/her own router.

[johanjanssens]

@Hackwar : Wouldn't it make sense to keep this method and deprecate it instead ? The method is protected which means that if anyone extends from this helper the method could be used. Instead of removing it could keep it and either make it return nothing or make it call the router instead. Calling the router would mean you need to make the method in the router public.

[johanjanssens]

@Hackwar : Wouldn't it make sense to keep this method and deprecate it instead ? The method is protected which means that if anyone extends from this helper the method could be used. Instead of removing it could keep it and either make it return nothing or make it call the router instead. Calling the router would mean you need to make the method in the router public.

[Hackwar]

You might be right that we need to deprecate this and clear it out otherwise. The idea for the later router is, that you have a component specific router, which implements the JComponentRouterAdvanced class, which registers a bunch of rules for the component router to use and one of those rules will detect the right Itemid for you. I might be misunderstanding you here, but it seems as if you want some sort of cross-calling, that the router should use this method. That is where I strongly disagree. In general, the ContentHelperRoute class should be deprecated as soon as possible, which mainly depends on #5140. If that is accepted and this one is accepted, this class is simply a replacement for 'index.php?option=com_content&view=article&id='.$article->slug.'&catid='.$article->catid.'&lang='.$article->language

[johanjanssens]

Hi Hannes, I agree that these helpers classes need to be deprecated as soon as possible. My only concern here is BC. By removing the method you break the API.

You are moving this logic into the component routers where they should be. Why not simply keep this method intact ? No harm in having it and deprecating it.

If you do want to save some code you could make it return NULL, but that could have unwanted side effects none the less.

[Hackwar]

The problem is, that even these findItem() methods are broken. They do not correctly route to form views for example. At the same time, I wont search the Itemid if it is already in the query. So if I'm generating a URL via this class, it will return the wrong Itemid in a few cases. I'd rather have the method return NULL and then do a proper lookup in my code.

[johanjanssens]

Agreed. In that case returning NULL would offer the best solution. Would include a doc header for the function to explain that the behaviour of the method has changed and it now always returns NULL.

[Hackwar]

Since this is now superseded by #5444, #5446 and #5501, I'm closing this one.

[Hackwar]

Since this is now superseded by #5444, #5446 and #5501, I'm closing this one.