Routing JApplicationWeb

[Stefan Neculai]

Hey,

As a step in learning Joomla Platform, I was trying to understand how the router would work in JApplicationWeb. I am a little confused about the following 2 things:

I've noticed that in the old files, there was a method route in JApplication which was doing some of the routing part. Now the route should be implemented by the developers or there is another simpler way to do that?

Also, in JRouter::getInstance expects to get client as an argument. What should that be?

--

Thanks,

Stefan Neculai

[Louis Landry]

Hi Stefan,

JApplicationWeb isn't prescriptive about routing, and is certainly not built to work with the current implementation of JRouter.  The idea is that since JApplicationWeb is essentially the front controller for your application, you would put whatever routing logic is necessary in your doExecute() function or it would be called from that function.  I'd certainly be interested in looking at any ideas you have on how to make JRouter a bit simpler and generic so it could be used with the new application classes, but I just haven't gotten there yet.

- Louis

[Stefan Neculai]

Hi,

I am going to study it and come back with suggestions if I have ones. Honestly, I am just at the start of the road in learning how the platform works, but I am trying to catch up.

--

Stefan

[Louis Landry]

Welcome.

[Hannes Papenberg]

Hmm, when you are looking for a generic, simple and easy router, what is
wrong with the implementation that I've been proposing here for the last
year?

Hannes

Am 29.03.2012 20:43, schrieb Louis Landry:
> Hi Stefan,
>
> JApplicationWeb isn't prescriptive about routing, and is certainly not
> built to work with the current implementation of JRouter. The idea is
> that since JApplicationWeb is essentially the front controller for
> your application, you would put whatever routing logic is necessary in
> your doExecute() function or it would be called from that function.
> I'd certainly be interested in looking at any ideas you have on how
> to make JRouter a bit simpler and generic so it could be used with the
> new application classes, but I just haven't gotten there yet.
>
> - Louis
>
> On Thu, Mar 29, 2012 at 10:57 AM, Stefan Neculai
> <stefan....@gmail.com <mailto:stefan....@gmail.com>> wrote:
>
> Hey,
>
> As a step in learning Joomla Platform, I was trying to understand
> how the router would work in JApplicationWeb. I am a little
> confused about the following 2 things:
>

> I've noticed that in the old files, there was a method /route/ in

[Louis Landry]

I'm sure there was something I didn't like about it, but honestly I don't remember.  Perhaps it wasn't application agnostic enough, I really don't know.  If it works for you, use it.  Generic, simple, and easy aren't really words I tend to associate with your code though ;) ... you tend to take on complex things like JCategories.

Cheers.

- Louis

[Hannes Papenberg]

Since you don't remember the code, here is the old pull request:
https://github.com/joomla/joomla-platform/pull/354

Here is a more recent version in my repo regarding the platform:
https://github.com/Hackwar/joomla-platform/tree/jrouter

And here is how it could be used in the CMS:
https://github.com/Hackwar/joomla-cms/tree/jrouter

Since the platform changed so much in the last months, its not
completely working right now, but it should be enough to show you the
ideas. This is an idea that has matured over the last 1.5 years and that
has been up for debate for a year now. Feel free to look at it.

Hannes

> <mailto:stefan....@gmail.com

[Louis Landry]

Thanks Hannes.

To be clear, my last email wasn't a jab at you... I apologize if it came off that way.  I'll take a look at this stuff and maybe we can talk through a path forward.  Probably won't happen today, but it'd be nice to get ourselves into a comfortable place with the front controller routing.

Cheers.

Louis

[Andrew Eddie]

On 30 March 2012 06:31, Hannes Papenberg <hack...@googlemail.com> wrote:
> Here is a more recent version in my repo regarding the platform:
> https://github.com/Hackwar/joomla-platform/tree/jrouter

Have you got some examples for how to use that API?

Also, do you really think it's necessary to have a SEF mode and
non-SEF mode any more (shouldn't the router be for handling SEF url's
exclusively)?

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[Hannes Papenberg]

Short answer before I go to bed:
There is no SEF mode anymore, what you see in the code is simply for backwards compatibility reasons. For the API examples: Look in the CMS repository that I posted. There are the following parts involved:
- JRouter in the platform
- the changed JRoute::_()
- JComponentRouter in the platform
- The router plugin in the system folder
- The router.php in the includes folder
- the component routers

The main idea for the platform is, that you have your class that either allows to attach rules via plugin (like you can see in the example plugin) or as methods of the class. For the CMS, the idea is, that you attach the rules to the component routers similarly and in the perfect world we would get the extremely complex rules working that I started, which dont require any real code from the component developer anymore.

I`m happy to describe this in more detail tomorrow.

[Andrew Eddie]

On 30 March 2012 07:10, Hannes Papenberg <hack...@googlemail.com> wrote:
> Short answer before I go to bed:
> There is no SEF mode anymore, what you see in the code is simply for
> backwards compatibility reasons.

OK

> For the API examples: Look in the CMS
> repository that I posted. There are the following parts involved:
> - JRouter in the platform
> - the changed JRoute::_()
> - JComponentRouter in the platform
> - The router plugin in the system folder
> - The router.php in the includes folder
> - the component routers
>

> I`m happy to describe this in more detail tomorrow.

Thanks. Just a hint when trying to sell an idea. Make it drop dead
easy for people to find the code they are supposed to be reviewing ;)
A link to the file you are using in the cms tree would be helpful.

[Amy Stephen]

Stefan - sorry to continue the hijacking of your thread, so briefly: since the files in the first link are named "Molajo router", I want to clarify that Molajo does not use this routing.

Not going into more detail on this since we really shouldn't continue to drive this thread off topic, but I fully support a much simplier approach to routing that involves the death of the ItemID - in new iterations of JRouter. I like Symfony and Lithium's approach to routing. I like the abstracted proposal for cache. https://gist.github.com/1329827 All of those approaches, IMO, head in good directions.

But, maybe further discussion on possible router improvements should be done in a new thread. That way, others who use JWebApplication and have ideas for Stefan on routing could respond.

[Andrew Eddie]

On 30 March 2012 09:02, Amy Stephen <amyst...@gmail.com> wrote:
> Not going into more detail on this since we really shouldn't continue to
> drive this thread off topic, but I fully support a much simplier approach to
> routing that involves the death of the ItemID

Well, you can still put it in if you want <rimshot>, but that should
be at the application level (above JApplciationWeb).

> - in new iterations of
> JRouter. I like Symfony and Lithium's approach to routing.

That's the mindset I think we should take too (gosh, we are agreeing
again, hehe) in as much as the router's job is to select a controller.

[Andrew Eddie]

On 30 March 2012 07:10, Hannes Papenberg <hack...@googlemail.com> wrote:

> Short answer before I go to bed:
> There is no SEF mode anymore, what you see in the code is simply for
> backwards compatibility reasons

Just a thought for these cases. There's nothing stopping us from
moving the old router into the legacy tree, and doing a fresh new (but
possibly backward incompatible version) in the main joomla tree. In
this way, battleship apps like the CMS can upgrade at their leisure
but those of us wanting to build new, clean hydrofoil-destroyer
applications (without "ItemID" baggage) can do so.

[Hannes Papenberg]

Here comes the long explanation:

The platform - application logic:
This is the main part of the new routing and the easiest of it at the
same time. The code can be found in
/libraries/joomla/application/router.php and in the code of JRoute::_().
The idea is, that these two parts provide a standardized interface for
routing rules. At the one side, with JRoute::_(), you can either push a
URL string in (for stuff like URL parsing in articles for example) or
you hand over an associative array with the URL parameters. This saves
us the hassle of retieving the data into a datastructure, then
concatenating that into a string and then parsing it again in the
router. (Right now we are even concatenating it in the router again and
then parsing it ... again) With something like array_intersect_key(), we
could have an array of keys and then later simply do something like
JRoute::_(array_intersect_key($article, $url_params)); to generate the
URL for an article.

The other end of the chain is JRouter, which provides an interface to
register function-calls, which get a JURI object as parameter and an
instance of the current router. This keeps all the logic for the routing
to the application specific code. If you need routing at all, you simply
extend the class and for example attach methods from this child class to
the router to process the URLs.

The CMS logic:
The router for the CMS does not implement its own rules in order to stay
as flexible as possible. Instead it relies on plugins to add the
necessary rules, which can be easily switched. The router can be found
in /includes/router.php and the plugin in /plugins/system/router.php. In
the onAfterInitialise Event, that plugin adds the application router
rules, which right now basically do what the old router is doing.

One of those rules is the one that handles the component specific
routers. These have to implement the JComponentRouterInterface interface
and can also extend the JComponentRouter class, which provides a
simplified version of the JRouter concept. Instead of a whole JURI
object, we simply hand in an associative array with the remaining URL
parameters and in return we get an array of URL paths. JComponentRouter
can be found in /libraries/joomla/application/component/router.php.

The quickest way for now would be to implement the component routers as
classes that implement the above mentioned interface and to simply copy
over the old router logic from the functions. For legacy routers, there
is a dummy class that is invoked for components without a router or with
legacy ones, which handles the old routers. When we decide to drop the
old routers at one point in time, we would simply drop that dummy class.

The benefit for the component routers would be, that we could extend the
component routers from other classes, potentially reducing the necessary
code. In the CMS repository that I mentioned earlier, you can see the
extreme of that, where the component routers simply register their views
in the constructor of their respective router class and the complete
logic is outsourced into rules in the router plugin. That means that you
need one line of code per view that you want to provide SEF URLs to and
Joomla does the rest. Admittedly, that generic rule currently does not
work the way that I want it to work and when Louis talks about me
writing complicated code, he definitely means something like that. This
is really nasty. If there is interest in abstracting this this much, I'd
be happy to invest more time into this, but I doubt that the code will
get any better.

The above described system does not require ContentHelperRoute classes
anymore, since this is all included in the component routers now, which
also means that URLs in content can not expire, but will always be built
correctly. Last but not least, the performance improved by about 10%
overall, making this 20% when the complicated component router logic is
disabled and instead the old routers are used.

Do you need specific code lines? Is this understandable?

Hannes

[Hannes Papenberg]

Is there anything new regarding this?

[Louis Landry]

Haven't forgotten about you, just been slammed with prior obligations this week.

L

Sent from my iPhone

[Hannes Papenberg]

Thank You!

Hannes

[Hannes Papenberg]

Something that I forgot and wanted to add: This routing code would
remove the coupling of the components to use Itemid in the URL. The
component would not have any URL (or any code for that matter) that
reads or creates the Itemid. Adding an Itemid and finding the right one,
would be a rule that could be added or removed. So in theory we could
replace the complete menu system and find a new, clever way to implement
this, without changing the component.

Hannes

Am 04.04.2012 18:28, schrieb Louis Landry:

[brian teeman]

If you remove that coupling how do you assign modules and templates?

[Hannes Papenberg]

I'm not removing the Itemid from the whole system, I'm just saying that
it would remove the need for the component developer to even think about
Itemids in his component. You wont need "&Itemid=42" or
ContentHelperRoute::getArticleRoute() anymore in your code to have the
URL route to the correct menu item. That would be done by the system.
Since you can get the current parameter set via
JComponentHelper::getParams(), you wouldn't even come in contact with
the whole menu system. All of this would be handled by Joomla. And if we
at one point find a replacement for the whole Itemid thing, we can
replace it at the platform/CMS level, and would not have to rewrite each
and every component. Regardless of the system: How templates and modules
are assigned, is an issue of the platform/CMS, not from the specific
component. Since right now you as a developer have to remember to
implement the proper logic for the right Itemid to be selected, it is
actually not seperated and we have an undesirable coupling between
component and assigning templates and modules.

Basically, questions like the one regarding the correct Weblinks Itemid
from joomla-dev-general would simply not arise anymore, since there is
no visible itemid for the extension developer anymore that he has to
care about.

Hannes

Am 06.04.2012 11:41, schrieb brian teeman:
> If you remove that coupling how do you assign modules and templates?
>
> On Friday, 6 April 2012 10:33:22 UTC+1, Hannes Papenberg wrote:
>
> Something that I forgot and wanted to add: This routing code would
> remove the coupling of the components to use Itemid in the URL. The
> component would not have any URL (or any code for that matter) that
> reads or creates the Itemid. Adding an Itemid and finding the
> right one,
> would be a rule that could be added or removed. So in theory we could
> replace the complete menu system and find a new, clever way to
> implement
> this, without changing the component.
>
> Hannes
>
> Am 04.04.2012 18:28, schrieb Louis Landry:
> > Haven't forgotten about you, just been slammed with prior
> obligations this week.
> >
> > L
> >
> > Sent from my iPhone
> >
> > On Apr 4, 2012, at 7:57 AM, Hannes Papenberg