2011/10/10 Kai <[email protected]> > Am 10.10.2011 15:12, schrieb Antonio Petrelli: > > Do you suggest to define an additional attribute in the specialised >>> definition, which holds the path to the template and then inject that >>> attribute to the template-attribute of the<t:insertAttribute>-Tag? >>> >>> >> No. As I understand, you have two choices: >> * defining several definitions using list.jsp as a template page, in which >> the "dynamic" attribute is redefined each time (but probably this is what >> you are trying to avoid, or not?); >> > No, I am only trying to define several versions of the template list.jsp, > which only differ in the <t:insertAttribute template="dynamic-X.jsp">-** > part. > > Indead, defining several definitions using list.jsp as a template is > exactly, what I am trying to do. I only don't know, how to feed in the > dynamicly "computed" picture-instance, which is only accessible in the > forEach-Loop! > > > * using a view preparer for the definition that computes the attribute to >> put as "dynamic" attribute. >> >> This might be the best way. > But on a quick glance at the ViewPreparer-Interface ant its two arguments > TilesRequestContext and AttributeContext, I couldn't figure out, how I > counld access the picture-instance, which lives inside the nested scope of > the forEach-Loop, from there... > > Sorry but probably I said something in one of my first emails in this thread that I thought it was obvious. The idea is to iterate the list of items (in your case pictures) and pass them as attributes to the underlying attribute. Therefore, when you do: <t:insertAttribute name="dynamic"> <t:putAttribute name="picture" value="${iteratedPicture}" /> </t:insertAttribute> you are passing the iterated picture as an attribute. In the inserted JSP pages you do a t:importAttribute first, then you use it as you usually do.
Antonio > > > But in my view, it would be a really nice feature, if it would work how I >>> had it expected to. It would ease the understandig of how the >>> EL-Expressions >>> in definitions work and it would hugely widen the applicability of >>> EL-Expressions in definitions. >>> >> [..] > > >> I think that it would be confusing the way you are interpreting use of EL >> in >> Tiles. After all, Tiles is<jsp:include> on steroids and usually it >> behaves >> as<jsp:include> behaves. And anyway, I doubt that it is even feasible. >> However, Tiles has already a well-done scope management for attributes, in >> which attributes in one included page are not visible outside (the >> implementation is essentially a stack) with the exception of cascaded >> attributes. Something like this is not available in EL out-of-the-box, >> because it relies on the 4 standard scopes (page, request, session, >> application). IIRC there is a way to create additional scopes but, >> sincerely, I don't know how. >> >> Yeah, you are right. > > Meanwhile, I debugged a little more around in the <t:insertAttribute> and I > noticed the jsp:include-style there. I wasn't aware of that before... > > > > Greetings kai >
