In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Type

Reproducibility

Date Submitted

Last Update

0001315

[In-Portal CMS] Front End

refactoring

N/A

2012-06-11 08:05

2012-10-20 06:23

Reporter

alex

View Status

public

Project Name

In-Portal CMS

Assigned To

Developer

Priority

normal

Resolution

open

Fixed in Version

Status

active

Product Version

5.1.3

Target Version

5.3.0

Time Estimate

No estimate

Summary

0001315: Routing Ideas

Description

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 5. 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.

Additional Information

Tags

No tags attached.

Reference

https://groups.google.com/d/topic/in-portal-dev/SRxO2pZSqJE/discussion

Change Log Message

Simplifies way how to work with rewrite-urls

Estimate Points

Attached Files

Relationships [ Relation Graph ] [ Dependency Graph ]

Notes
(0005240) alex (manager) 2012-10-20 06:23	Moving to 5.3.0 as proposed in associated discussion.

Issue History
Date Modified	Username	Field	Change
2012-10-20 06:23	alex	Note Added: 0005240
2012-10-20 06:23	alex	Target Version	Icebox => 5.3.0
2012-06-11 08:05	alex	New Issue
2012-06-11 08:05	alex	Reference	=> https://groups.google.com/d/topic/in-portal-dev/SRxO2pZSqJE/discussion
2012-06-11 08:05	alex	Change Log Message	=> Simplifies way how to work with rewrite-urls
2012-06-11 08:05	alex	Estimate Points	=> 2

Web Development by Intechnic

In-Portal Open Source CMS