[
http://jira.magnolia.info/browse/MAGNOLIA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808#action_17808
]
Gregory Joseph commented on MAGNOLIA-2343:
------------------------------------------
Hi all,
{quote}Ralf Hirning - 09/Sep/08 09:34 AM
Greg, could you please describe what the impacts are if selectors are
deprecated?
{quote}
First off, and to make everything clear: if a feature is deprecated, it only
means its usage is "discouraged". If we deprecate something now, it will not be
removed in 3.6.2, and most probably not in 3.7 (although that would make our
lifes easier). 3.8 or 4.0 would be the target release for removal of a feature
we would deprecate now.
{quote}
For example we use the selector in an image gallery. In the standard view you
see all images. If you click on an image we generate an URL including the image
nonde name as selector. The URI looks like
/fotos/examples.preview-0_00.html.
As we display this page in Liferay portal using WSRP the window view will be
added to get
/fotos/examples.window-maximized.preview-0_00.html.
So we need the selector to add request data without the possibility to cache.
How can that be done using virtual URI mapping?
{quote}
Okay, so the selector as get it from Magnolia
({{AggregationState.getSelector()}}) is always one single string. From the
looks of your examples and the usages I found in some project indicate that
this string is split on dots, but in both your example, you'll start working
based on strings like {{preview-0_00}} or {{window-maximized.preview-0_00}},
right ?
Now, let's say you setup a virtual uri mapping:
{noformat}
class: info.magnolia.cms.beans.config.RegexpVirtualURIMapping
fromURI: /fotos/examples\.(.*)\.html
toURI: forward:/fotos/examples.html?selector=$1
{noformat}
The only thing to do is modify your templates so that instead of doing
{{AggregationState.getSelector()}} or {{Resource.getSelector()}}, you'll do
{{request.getParameter("selector")}}.
Note that:
* you don't have to define this virtualUriMapping specifically for
"/fotos/examples" and if you map {{/([a-zA-Z0-9_/-]+\.(.*)\.html}} to
{{/$1.html?selector=$2}} you'll essentially get the same behaviour as currently.
* the cache key will be the original URI (ie
{{/fotos/examples.preview-0_00.html}}), so there's no caching issue.
* you can define your own implementation of {{VirtualURIMapping}} which can
potentially do much more complex mappings. (but possibly simpler to configure)
{quote}Wolfgang Habicht - 09/Sep/08 09:48 AM
We also use selectors a lot in our projects.
I see still some more problems replacing selectors with URI mappings:
# assume the case having selectors and optional URL parameters: is this
possible with a regexp? (you need to add ?selector=... or &selector=...)
[Alternatively a new VirtualURIMapping class could be written...]
# to remove them internally might work - however I do not see any advantage
(see below)
# removing selectors also in URLs is much more than just search/replace; there
could be also some string operations concatenating URL-parts; potentially also
in Java Script.
{quote}
1. yes, I'd write a new VirtualURIMapping for this (I'm pretty sure a regex
would be feasible, but just thinking about it gives me headaches) - thanks for
pointing this out; if we reach an agreement here, we'll make sure to provide it
for replacement.
2. Advantage for Magnolia's code base: streamline/simplify both the filters and
the aggregation state-related classes. Advantage for templates: one way of
doing things instead of 2.
3. You wouldn't need to remove them from your pages' url: quite the contrary,
you'll want to keep them (nicer URLs, cacheable). The only place that needs to
change is where the selector is USED (i.e template/code)
{quote}
The question whether to remove selectors came from the idea to allow dots in
(only some?) node names. I didn't get the advantage of removing selectors in
the proposed way to achieve dots in names; they still exist in the URI - and
are "only" removed during processing.
{quote}
It's more that, while researching why dots in user name were currently not
allowed/working, Jan ran accross this and we realized that
* the selector mechanism prevented from accessing nodes with dots in their name
through a url.
* this was redundant wiuth the intentions, and less powerful than, the virtual
uri mappings.
{quote}If you remove them from the URI (as sent by the client) too, you run
into caching problems.
{quote}
Unless I missed something, no, see explanations above.
{quote}
If you have really good reasons to remove selectors, please do not do it in a
major release (i.e. Magnolia 4.0) as in my opinion this is a major change.
{quote}
It is indeed, which is why we wanted to deprecate it now, and as said above,
not remove it until a further major version.
{quote}
Giancarlo Berner - 09/Sep/08 10:12 AM
We also use selectors a lot, especially in combination with Base64 encoding.
One important reason is caching: While requests with parameters are not
returned from cache (e.g. Web servers), requests with selectors are. So if e.g.
a user iterates through an image gallery, these images would be cached.
{quote}
As mentioned above, the original request (i.e with the "selector" in the url)
will be cached.
{quote}
Another problem when removing selectors are the existing projects. It would
indeed be very cumbersome to rework each and every project.
{quote}
Well, two things, it seems I have to insist on:
* we're only *deprecating* it.
* is what I proposed above (replacing {{Resource.getSelector()}} by
{{request.getParameter("selector")}}) really cumbersome ?
Thanks for the feedback guys, I hope this shed some light on your fears. Let us
know what you think.
> Selectors can be deprecated, virtual uri mappings can do a better job
> ---------------------------------------------------------------------
>
> 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.6.2
>
> Attachments: Picture 1.png
>
>
--
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/
----------------------------------------------------------------
