Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-2343

Replace current implementation for selectors by a more flexible mechanism

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • None
    • core, templating

      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)

        Acceptance criteria

              Unassigned Unassigned
              gjoseph Magnolia International
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Task DoR