[MAGNOLIA-2343] Replace current implementation for selectors by a more flexible mechanism Created: 29/Aug/08  Updated: 19/Dec/16  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia
Component/s: core, templating
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Magnolia International Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: concept, toreview
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Picture 1.png    
Issue Links:
Relates
relates to MAGNOLIA-5712 farFutureCaching and Resource files w... Closed
relates to MGNLRES-152 Generate links to resources, and use ... Closed
dependency
is depended upon by MAGNOLIA-2003 User names with dots not possible Closed
relation
is related to MAGNOLIA-2580 node names: allow dots Closed
is related to MAGNOLIA-3341 Setting defaultExtension to '' breaks... Closed
is related to MAGNOLIA-2861 content resolving, virtual urls: intr... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

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

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)



 Comments   
Comment by Ralf Hirning [ 31/Aug/08 ]

How do you judge that selectors can be deprecated?

We use selectors intensively in the projects and I do not see how to get the same results with virtual URI mappings.

Comment by Magnolia International [ 03/Sep/08 ]

See demoauthor modules/adminInterface/virtualURIMappings/messages. See attached screenshot.

Basically you'd forward and add what's in your selector as a request parameter.
Cache isn't an issue, as the original uri is used as cache key.
A fairly simple search/replace would then be needed to update your templates.

Comment by Magnolia International [ 08/Sep/08 ]

Ralf, could you let us know if this works for you? The intention is to streamline/simplify both the filters and the aggregation state-related classes.

Comment by Ralf Hirning [ 09/Sep/08 ]

Greg, could you please describe what the impacts are if selectors are deprecated?

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?

Comment by Wolfgang Habicht [ 09/Sep/08 ]

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.

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.
If you remove them from the URI (as sent by the client) too, you run into caching problems.

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.

(off topic: to achieve dots in user names why not escape/encode the dot character for transmission? Such an URL may not be nicely readable, however the basic problem is solved. It is up to an admin if he will be using dots.)

Comment by Jan Haderka [ 09/Sep/08 ]

(off topic: to achieve dots in user names why not escape/encode the dot character for transmission? Such an URL may not be nicely readable, however the basic problem is solved. It is up to an admin if he will be using dots.)

Escaping the dots would not really solve the issue since those would be decoded at the time when we extract selectors from the names.
As for the "dots in names" issue, we can work around the selectors by recombining the selector with remainder of the name back together, reason why it was not done is because we thought selectors can be replaced by virtual uri mapping and would go away.

Another reason why to favour virtual uri mapping rather then selectors is the simplicity of use and coding. Virtual URIs are feature nicely visible and easily configurable in the admin central at runtime, while selectors (as handy and easy to use as they are) are somewhat hidden inside of magnolia and not so well and easily understood by someone just starting with Magnolia.

Comment by Giancarlo Berner [ 09/Sep/08 ]

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.
Another problem when removing selectors are the existing projects. It would indeed be very cumbersome to rework each and every project.

As Ralf and Wolfgang are asking, I am very curious too to get the idea why you want to remove selectors.

Comment by Jan Haderka [ 09/Sep/08 ]

One important reason is caching: While requests with parameters are not returned from cache (e.g. Web servers), requests with selectors are.

If your only reason to use selectors is to make request cached, would not it be cleaner to add parameter "cachable=true" to the request you are making, and to modify cache filter to check for existence of such parameter and when found cache the whole query including the parameters?

Comment by Magnolia International [ 09/Sep/08 ]

Hi all,

Ralf Hirning - 09/Sep/08 09:34 AM
Greg, could you please describe what the impacts are if selectors are deprecated?

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.

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?

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:

  class: info.magnolia.cms.beans.config.RegexpVirtualURIMapping
fromURI: /fotos/examples\.(.*)\.html
  toURI: forward:/fotos/examples.html?selector=$1

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)

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:

  1. 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...]
  2. to remove them internally might work - however I do not see any advantage (see below)
  3. 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.

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)

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.

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.

If you remove them from the URI (as sent by the client) too, you run into caching problems.

Unless I missed something, no, see explanations above.

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.

It is indeed, which is why we wanted to deprecate it now, and as said above, not remove it until a further major version.

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.

As mentioned above, the original request (i.e with the "selector" in the url) will be cached.

Another problem when removing selectors are the existing projects. It would indeed be very cumbersome to rework each and every project.

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.

Comment by Ralf Hirning [ 09/Sep/08 ]

Hi Greg,

I try to understand what you wrote and try to compile this with just a few words...

Did I get it right that "deprecate" just means that the usage of Resource.getSelector() is deprecated, but we still can use selectors in the URIs? So instead of using Resource.getSelector() we just could write our own method MyProject.getSelector() to get the selector from the original URI. And everything works as before. Then I do not have any problems with the deprecation.

But anyway, I do not see the impact of the usage/deprecation of Resource.getSelector() on the future of Magnolia.

Comment by Wolfgang Habicht [ 10/Sep/08 ]

The change from Resource.getSelector() to request.getParameter("selector") does not seem to be problematic for me.
But for me it is a step in the direction of complete removal of selectors and that makes me worring a bit.

You wrote, you would like to streamline the code.

Between a selector and an URL parameter is a slight semantic difference: the selector is a part of the URL (i.e. www.somehost.com/hello/world.large.html for a large-font version of world.html) whereas a parameter is some additional "information" (i.e. blog.html?elements=5 for showing the last 5 blog entries).

In my opinion using a VirtualURIMapping to convert selectors to URL-parameters is - from a developer using Magnolia point of view - more complicate (it's not just the actual call, also the needed VirtualURIMapping and to know what's happening) and less intuitive. Keeping the actual selector handling also reduces the risk, that some other change breaks the selector functionality. If you allow at some point of time to have dots in node-names, selectors will no longer work. As EE-customer we need to know in advance if we can relay on this feature or not.

To bring it to the point:

  • if you leave the working selector-code as is, selectors are still supported.
  • if you mark Resource.getSelector() as deprecated, I must regard selectors as whole as deprecated and possibly soon to be no longer supported.
Comment by Magnolia International [ 10/Sep/08 ]

I see your concerns. Ours is that virtual uri mappings basically permit the same thing selectors do, just in a more powerful and flexible way, and the two are somewhat redundant.

However: the whole issue is, generally, about how to map a URL to a node in the repository. Virtual uri mappings could be improved so that one wouldn't have to necessarily forward the request with added parameters (it could for instance add these to the current state instead). And it could possibly be merged with URI2RepositoryMapping, which also do something similar.

Wolfgang, the semantic difference is very discussable, especially since we all love "nice" URLs. My typical exemple is /archive/?month=09&year=2008 vs /archive/2008/09 : the latter is obviously better, although obviously, whichever you use, you're probably only going to have one "concrete" end point (page) in your application ("/archive")

Deprecation: does not mean the concept is forgotten about. We're just talking about the API here.

From a developer point of view, I am not convinced using request parameters would be more complicated: in fact, that gives the templater one less possible point of input. The configuration on the other hand might be a little more complex. Maybe a page displaying a complete list of mappings would help.

IF we end up removing this feature at some later point in time, we will ensure there is a replacement. The current deprecation is only a warning (like there are tons in the current codebase) that this might change at some point in the future. It will not go away without more warnings (i.e explanations in release notes) AND we will definitely provide replacing functionality (for instance a global mapping that gives you the selectors but no dots in URLs, which you can turn on/off depending on your needs)

Again, one more time: deprecation does not mean immediate removal. We might even end up de-deprecate it, who knows? For us, it's more of a reminder that "hey, we need to improve things in this area" than anything else.

Comment by Magnolia International [ 11/Sep/08 ]

Updated description - thanks for the feedback everyone.

Comment by Magnolia International [ 09/Sep/09 ]

some more ideas/thoughts can be found at http://wiki.magnolia-cms.com/display/DEV/Proposal+-+merging+of+URI2RepositoryMapping+and+VirtualURIMappings

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:35:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.