[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: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Task DoR: |
Empty
|
||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||
| Description |
|
Warning This issue has been updated. The current implementation of selectors is unsatisfying in many levels:
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. |
| 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:
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 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 ] |
Escaping the dots would not really solve the issue since those would be decoded at the time when we extract selectors from the names. 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. 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 ] |
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,
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.
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:
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.
It's more that, while researching why dots in user name were currently not allowed/working, Jan ran accross this and we realized that
Unless I missed something, no, see explanations above.
It is indeed, which is why we wanted to deprecate it now, and as said above, not remove it until a further major version.
As mentioned above, the original request (i.e with the "selector" in the url) will be cached.
Well, two things, it seems I have to insist on:
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. 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:
|
| 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. |