Uploaded image for project: 'Blossom'
  1. Blossom
  2. BLOSSOM-177

Accessibility of container component models intended?

    XMLWordPrintable

Details

    • Task
    • Resolution: Not an issue
    • Neutral
    • None
    • None
    • None
    • None

    Description

      Hi Tobias,

      this request is neither clearly a bug nor clearly a task nor clearly a question, I just don't know what it is (that's kind of the question itself). Since I have a login to this Jira but not for the forum, please accept it here.

      I have noticed if you put components on a page or you nest components in each other, the JSP rendering one inner component can access the model(s) of the outer component(s) and the container page, simply by writing ${outercomponentmodelattribute} as if this were a "native" model attribute to the component itself. As I found this quite surprising at first, I investigated further (long ago) and discovered something like that it results from the fact that the model is made accessible to the JSP by means of request attributes, and when reading request attributes nested requests traverse up the chain until they find a match. Something like this, I don't remember the details exactly. I remember there was some copying functionality involved at some point, and I believe to remember that it was Blossom code, not Spring code.

      As such I believe this behavior wasn't intended by you (and might even be still unknown to you), it's more a side effect of how other things in your framework are working.

      Now, the reason why I'm writing: I'm making use of this behavior at a couple of places in my code in different projects already, very gratefully by the way, because if this side effect wasn't there, I don't think there would be anything even nearly as elegant to make components context-sensitive.

      On the other hand, ... relying on a side effect is a little dangerous. That's the reason why I'm asking: Could you make the fact that request.getAttribute("[anything]") returns a model attribute of an outer component or page (if it exists under that name) documented behaviour so that we can safely rely on it? Otherwise I'd always be scared that several projects could suddenly be broken if they switch to a later version of Blossom, knowing that this would not be trivial to fix.

      If it already IS documented and I've missed that, then please forgive me.

      Thanks a lot.

      Torsten

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              tmattsson Tobias Mattsson
              tln TLN
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Checklists

                  Task DoR