[
http://jira.magnolia.info/browse/MAGNOLIA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Joseph updated MAGNOLIA-2343:
-------------------------------------
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.
note: The original link of this issue to the "dots in user names" issue
remains, because they are indeed related, but the fixes for both issues will
not be. (i.e. we do not necessarily need to change the selectors implementation
to fix the dots in user names issue and vice-versa; it's just by investigating
the latter that we started discussing the selector issue)
was:
{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.
> 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.
> note: The original link of this issue to the "dots in user names" issue
> remains, because they are indeed related, but the fixes for both issues will
> not be. (i.e. we do not necessarily need to change the selectors
> implementation to fix the dots in user names issue and vice-versa; it's just
> by investigating the latter that we started discussing the selector issue)
--
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/
----------------------------------------------------------------
