In the last 3 weeks I have been working hard on refactoring the whole itemid handling in 1.5. Currently 75% of the work is done and the changes have been implemented in both the weblinks and the newsfeeds components. This thread is intended to inform you about the changes in itemid behavior and to answer questions.
Before diving into the changes and howto's let me show you what this baby can do. The new system is capable of producing links like :
1. http://localhost/joomla15/index.php/web ... oomla (link to weblink)
2. http://localhost/joomla15/index.php/the ... w/faq (submenu item)
3. http://localhost/joomla15/index.php/new ... -news (link to newsfeed)
These links are : unique, humanly readable, hierarchical and their creation doesn't require any overheat. Yep that's right, zip zero ovehead. Juts like we want it !
First of all, the changes are fully backwards compatible and shouldn't have any effect on older components. So far this is untested, but 1.5 is running components with the old style of url handling and the new style without any problems. In case you have a component that runs in legacy mode and cannot handle the new url routing system let me know so we can make sure everything is 100% BC.
Before diving into the specifics of what has been changed I would like to explain some of the concept changes. In Joomla! 1.0 we had something called SEF (search engine friendly URL's). A nice name but something like a SEF URL doesn't really exist. In accessibility terms we can talk about humanly readible URL's, or if we look at URL's on a system architecture level we can talk about routes. This is also what we will be calling them from now on : 'routes'.
If you pop open the hood of the latest SVN you will notice that we added and implemented a JRouter object. JRouter is a class that is responsible for building and parsing routes. You will also notice that we split up the JApplication::excecute function into a route and dispatch function.
Routing : Routing is the process of examining the request environment to determine which which component should receive the request. This component optional parameters are then set in the request object to be processed when the application is being dispatched.
Dispatching : Dispatching is the process of pulling the option from the request object and mapping them to a component. If the component do not exist, it handles determining a default component to dispatch.
The JApplication::route function is responsible to create the router object and parse the request URI. The router examines the request and tries to match the itemid based on the application route (part of the total route defined by the menu). The component route (remaining part) is passed on to the specific component router handling functions.
A component can handle it's own routing process by adding a router.php file and in this file defining a MycomponentParseRoute and MycomponentBuildRoute function.
1. Parse function
The parse function passes in an array that contains the different parts of the route. It's up to the component to decide how to interpret the information in this array and push or translate relevant into JRequest.
2. Build function
The build function passes in an array that contains the query part of the URL. It's up to the component to decide how to translate this information into a route.
If you would look at it from a decoder/encoder perspective, the build function is the encoder and the parse function the decoder. The component can decide for himself how to handlin the decoding/encoding process and doesn't need to rely on a plugin or external algoritm to do this.
In case the component decides not to handle the routing process JRouter will simply use the information in the query array to create a full query string. The component can also decide not to handle part of the query info and pass it back to JRouter in which case JRouter will append it to the and route as a URL query string. (a good example of this is com_search).
The changes also make creating routes alot easier. You don't need to specify the option and Itemid anymore in the sefRelToAbs function. This the following piece of code is valid :
Code: Select all
$link = sefRelToAbs( 'index.php?view=x&id=x);
These changes makes creating routes (URL's) in 1.5 alot easier and more straightforward. A nice side-effect is the fact that components don't need to know about $option and $Itemid anymore. It's only the application (JSite) who needs to know about both. This opens a whole new world of possibilities as a component is not tied anymore to it's own name.
I think it's best you have a look at com_weblinks and com_newsfeeds to see the changes in action. If you have any questions, which i'm sure you do, don't hesistate to ask them.
Note A : The new architecture has also been implemented in such a way that it can easily be decorated/extended. No more hacking of the core, solutions like OpenSEF can now truly focus on becoming URL management extensions. Which is what they are in the first place.
Note B : The changes are not fully complete yet. I still need to
- Implemented the changes in all other frontend components
- Sync the pathway with the router to improve the pathway handling
- Fix issues related to pagination
- Fix issues related to redirects