Routing: Discover Itemid in Router for com_content #5285
Conversation
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)? |
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. |
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... |
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. |
This comment has been minimized.
This comment has been minimized.
@Hackwar Good work. Couple points of feedback.
Thoughts ? |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Thanks Hannes :
|
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Ah got it, i was looking at the wrong file. Moved my comment up. About this method. I would consider adding it to a |
This comment has been minimized.
This comment has been minimized.
@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. |
This comment has been minimized.
This comment has been minimized.
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 joomla#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 |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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. |
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