New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Routing: Discover Itemid in Router for com_content #5285

Closed
wants to merge 7 commits into
base: staging
from

Conversation

Projects
None yet
4 participants
@Hackwar
Member

Hackwar commented Dec 2, 2014

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 comment has been minimized.

Contributor

dgrammatiko commented Dec 2, 2014

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

This comment has been minimized.

Member

Hackwar commented Dec 2, 2014

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 added some commits Dec 2, 2014

@Hackwar

This comment has been minimized.

Member

Hackwar commented Dec 2, 2014

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

This comment has been minimized.

Member

Hackwar commented Dec 2, 2014

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

This comment has been minimized.

johanjanssens commented on 0dad43d Dec 3, 2014

@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 ?

This comment has been minimized.

Owner

Hackwar replied Dec 3, 2014

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.

This comment has been minimized.

johanjanssens replied Dec 3, 2014

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

This comment has been minimized.

johanjanssens commented on components/com_content/router.php in c971f4c Dec 3, 2014

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.

Owner

Hackwar replied Dec 3, 2014

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.

johanjanssens replied Dec 3, 2014

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

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.

Owner

Hackwar replied Dec 3, 2014

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.

johanjanssens replied Dec 3, 2014

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.

Owner

Hackwar replied Dec 3, 2014

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.

johanjanssens replied Dec 3, 2014

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

This comment has been minimized.

Member

Hackwar commented Dec 30, 2014

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

@Hackwar Hackwar closed this Dec 30, 2014

@Hackwar Hackwar deleted the Hackwar:ItemidInRouter branch Dec 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment