[
http://jira.magnolia.info/browse/MAGNOLIA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Joseph updated MAGNOLIA-2343:
-------------------------------------
Summary: Replace current implementation for selectors by a more
flexible mechanism (was: Selectors can be deprecated, virtual uri mappings can
do a better job)
Labels: toreview concept (was: )
Fix Version/s: 3.7
(was: 3.6.2)
Description:
{panel:title=Warning}
This issue has been updated.
Its title used to be "selectors can be deprecated, virtual uri mappings can do
a better job", and this was a very misleading title, which led to the comments
below. We hear your concerns, they are totally valid, so we'll try to come up
with something better :)
As from 2008-09-11, we've renamed, re-described and postponed this issue.
{panel}
The current implementation of selectors is unsatisfying in many levels:
* it is redundant with what can be (at least partly) achieved with virtual uri
mappings ({{/foo.bar.html}} -->forward--> {{/foo.html?selector=bar}}, and does
not allow other elegant solutions for nice urls ({{/archives/2008/09}})
* it is does not allow naming of parameters or generally more flexible
mappings: the knowledge of how to treat the complete selector string is coded
in the template. (For a URI like "/archives.2008.09.html", the template gets a
"2008.09" string, and he has to know the exact order of these 2 elements in the
string)
* there are many possible places where a template could get its "dynamic"
information from (request parameters, request attributes, context attributes,
uri in itself, ...) and this is just adding to the confusion.
* it is completely hard-wired in the filter chain and the API of Magnolia: it
can't be disabled, and it adds "complexity" to the API for something that
should not be imposed on users. (it *is* useful, but people should be free to
use it or not and/or to use other mechanisms for similar purposes)
For these reasons, we'd like to replace it. Replacing it with the current
implemenation of virtual uri mappings isn't exactly the best solution, which is
why we're postponing this. I'll try to come up with a small document describing
a possible solution shortly.
Updated description - thanks for the feedback everyone.
> Replace current implementation for selectors by a more flexible mechanism
> -------------------------------------------------------------------------
>
> Key: MAGNOLIA-2343
> URL: http://jira.magnolia.info/browse/MAGNOLIA-2343
> Project: Magnolia
> Issue Type: Task
> Components: core, templating
> Reporter: Gregory Joseph
> Assignee: Gregory Joseph
> Fix For: 3.7
>
> Attachments: Picture 1.png
>
>
> {panel:title=Warning}
> This issue has been updated.
> Its title used to be "selectors can be deprecated, virtual uri mappings can
> do a better job", and this was a very misleading title, which led to the
> comments below. We hear your concerns, they are totally valid, so we'll try
> to come up with something better :)
> As from 2008-09-11, we've renamed, re-described and postponed this issue.
> {panel}
> The current implementation of selectors is unsatisfying in many levels:
> * it is redundant with what can be (at least partly) achieved with virtual
> uri mappings ({{/foo.bar.html}} -->forward--> {{/foo.html?selector=bar}}, and
> does not allow other elegant solutions for nice urls ({{/archives/2008/09}})
> * it is does not allow naming of parameters or generally more flexible
> mappings: the knowledge of how to treat the complete selector string is coded
> in the template. (For a URI like "/archives.2008.09.html", the template gets
> a "2008.09" string, and he has to know the exact order of these 2 elements in
> the string)
> * there are many possible places where a template could get its "dynamic"
> information from (request parameters, request attributes, context attributes,
> uri in itself, ...) and this is just adding to the confusion.
> * it is completely hard-wired in the filter chain and the API of Magnolia: it
> can't be disabled, and it adds "complexity" to the API for something that
> should not be imposed on users. (it *is* useful, but people should be free to
> use it or not and/or to use other mechanisms for similar purposes)
> For these reasons, we'd like to replace it. Replacing it with the current
> implemenation of virtual uri mappings isn't exactly the best solution, which
> is why we're postponing this. I'll try to come up with a small document
> describing a possible solution shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia.info/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
