Routing Ideas

[Alexander Obuhovich]

Routing is a way for application decide what content to show based on provided request data:

• url
• headers
• form data

It is implemented in one or another form in all major frameworks, like: Symphony, Zend Framework.

Right now in 5.1.x and 5.2.0-B3 we have rewrite listeners concept. It's a method inside event handler class, that knows how to build/parse urls.

There are several problems that needs to be solved in current implementation:

• small build/parse methods are located in usually big class (event handler) and just to build/parse url you create that class instance and eat lot of memory
• no way to create custom url caching key, since rewrite listeners don't put custom data into caching key
• rewrite listeners always create kModRewriteHelper class instance to use common function for url processing
• if you need to pass some custom parameter to rewrite builder to build a valid link (e.g. filename), then you need to create 2 copies of code
• in event handler: to ensure correct link after executing event on item detail page
• in tag processor: to ensure correct link when printing a list of items

I'm proposing to create base class kRouter with these methods:

1. build(...) - builds an url
2. parse(...) - parses an url
3. getLinkParams($object) - returns extra url parameters, extracted from object, that are required to successfully build a link
4. processParams(&$params) - get parameters, associated with given unit and remove it from global scope (like kModRewriteHelper::getProcessedParams method now)
5. patchCachingKey($caching_key) - get caching key as input and return patched version (allows to put header values into caching key, used to cache parsed url)

Then in unit config you can register router using this code:

'RouterClass' => Array ('class' => 'WidgetRouter', 'file' => 'widget_router.php', 'build_event' => 'OnBuild'),

And class, who right now processes all that stuff called kRewriteProcessor would be renamed to kRoutingManager (maybe not a first) to make it all sound good.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Hi Alex,

All sounds interesting, a few questions:

1. Are we keeping all current methods in the same kRewriteProcessor class after renaming it to kRoutingManager? I noticed there is bunch of URL/rewrite related stuff. Does it means renaming is just formality?

2. In new Widgets (example one) Router class we'll have these methods or something else?:

- WidgetRewriteListener

- WidgetRewriteBuilder

- WidgetRewriteParser

3. This sounds like changes for 5.3.x branch to me, you Alex?

DA

[Alexander Obuhovich]

1. Are we keeping all current methods in the same kRewriteProcessor class after renaming it to kRoutingManager? I noticed there is bunch of URL/rewrite related stuff. Does it means renaming is just formality?

Keeping at first, since there would be too much changes for first phase of this task.

2. In new Widgets (example one) Router class we'll have these methods or something else?:

- WidgetRewriteListener

- WidgetRewriteBuilder

- WidgetRewriteParser

We will create a separate class (for each router instead event handler) and move these methods there + rename them.

3. This sounds like changes for 5.3.x branch to me, you Alex?

Not that big changes actually to wait until 5.3.0.

[Dmitry A.]

Hi Alex,

Please create new Task for this discussion.

DA

[Dmitry A.]

PING

[Dmitry A.]

I am a little worrying that this great idea is going to vanish among other conversations.

Alex, it would great if you can file a new task for this sometime soon.

Cheers!

DA

[Alexander Obuhovich]

No worries. I've already marked discussions, that needs tasks to be created in my e-mail client.

[Alexander Obuhovich]

Here is the task: http://tracker.in-portal.org/view.php?id=1315 

[Dmitry A.]

I think it's time we put in this in In-Portal 5.3.0 release.

DA

[Alexander Obuhovich]

Task moved.