Magnolia

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.

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.

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.

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?

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

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

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.

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?

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.

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.

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.

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.

Updated description - thanks for the feedback everyone.

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