Tiles
  1. Tiles
  2. TILES-363

Attaching global preparer to a <tiles-definitions> list

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.1.2
    • Fix Version/s: 2.2.x
    • Component/s: tiles-core
    • Labels:
      None
    • Environment:

      Using Tiles 2.1.2

      Description

      CONTEXT: one of the definitions file I am working on has 500+ definitions, and all of them require the same preparer.

      REQUEST: The XML would be much lighter and cleaner if it were possible to attach a preparer to the single <tiles-definitions> element (that would apply to all nested definitions) instead of to each <tiles-definition> element.

        Activity

        Hide
        Antonio Petrelli added a comment -

        Can you write about your use case in the Tiles Users mailing list?
        http://tiles.apache.org/mail.html
        I suppose that there is another way to do what you need.

        Show
        Antonio Petrelli added a comment - Can you write about your use case in the Tiles Users mailing list? http://tiles.apache.org/mail.html I suppose that there is another way to do what you need.
        Hide
        Antonio Petrelli added a comment -

        The reporter does not follow up his request.

        Show
        Antonio Petrelli added a comment - The reporter does not follow up his request.
        Hide
        Sylvain Pedneault added a comment -

        It seems I misunderstood your request, as I thought you were referring to my CONTEXT and not my REQUEST. The context I described (500+ definitions) is unavoidable in our project (transitioning from legacy code, and having very specific functional requirements), and so that context cannot change. The preparer we are using on all these tiles is required to add a kind of smart logic to determine how to apply (or not) a tile attribute's default value for each request (thus avoiding the need to add that logic code to the underlying JSP files).

        So, my request for enhancement is really only about adding a way of specifying "global" preparers within a definitions file. Much like it is possible to define default interceptors and global results in Struts2.

        Thank you!

        Show
        Sylvain Pedneault added a comment - It seems I misunderstood your request, as I thought you were referring to my CONTEXT and not my REQUEST. The context I described (500+ definitions) is unavoidable in our project (transitioning from legacy code, and having very specific functional requirements), and so that context cannot change. The preparer we are using on all these tiles is required to add a kind of smart logic to determine how to apply (or not) a tile attribute's default value for each request (thus avoiding the need to add that logic code to the underlying JSP files). So, my request for enhancement is really only about adding a way of specifying "global" preparers within a definitions file. Much like it is possible to define default interceptors and global results in Struts2. Thank you!
        Hide
        Antonio Petrelli added a comment -

        Probably I understood your question.
        You have several definition files, but only one of these files needs a "default preparer". So you want to define it once for every definition.
        It should be some sort of "shortcut", right?
        In this case I like it. Would you write a patch for it?

        Show
        Antonio Petrelli added a comment - Probably I understood your question. You have several definition files, but only one of these files needs a "default preparer". So you want to define it once for every definition. It should be some sort of "shortcut", right? In this case I like it. Would you write a patch for it?
        Hide
        Antonio Petrelli added a comment -

        No follow up, no patch, no implementation.
        I close it as "won't fix". It seems bad, but since I am the only active developer and I don't care about this implementation and no one writes a patch, well...

        Show
        Antonio Petrelli added a comment - No follow up, no patch, no implementation. I close it as "won't fix". It seems bad, but since I am the only active developer and I don't care about this implementation and no one writes a patch, well...

          People

          • Assignee:
            Unassigned
            Reporter:
            Sylvain Pedneault
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development