"Antonio Petrelli" <[EMAIL PROTECTED]> wrote on 21/06/2007 14:12:37:
first of all, next time please write your messages in plain text.
Sorry for this… This is bloody Lotus Notes I'm forced to use here… I'll post my messages from the gmail account – it should be better….
> And then, while rendering an attribute, looking for a proper renderer? Mmm... The idea seems not too bad. For example, there could be an "attribute type" -> "attribute renderer" map in the container...
Or each renderer could have it turn and try to render a given attribute. This would allow for interceptor / decorator style of rendering. Just thinking aloud here…
> This should work fine, I guess. I only wonder what we should do with the enum for an attribute type. Drop it altogether? Probably yes... In fact, I added the enum simply because the "template, definition, string" types were always fixed in Struts-Tiles, and string-checking if much slower than a switch using enums. But maybe it's time to rethink it.
I must admit I was a little bit scared when I saw this enum for the first time: for me it was like removing a lot of flexibility from the very beginning. Were there other arguments, beside the speed of comparisons?
> - I also need to add other attr types, More? Oh no! :-) Seriously, what are they?
It's a long story… They are for including static HTML files from a disk, but with an algorithm for finding those files (each customer can upload his own set of files, and there is only one Tile definition file for all customers). Once again – EL support could be a solution here.
> - I couldn't make "/DynamicFooter.action" syntax work with Struts 2.0.8 + Tiles 2.0.3. I've spend some time debugging the code and it looks like this syntax would be equivalent to doing <jsp:include flush="true" page="/DynamicFooter.action" / in a JSP. In Tomcat it gives me "The requested resource (/[context name]/DynamicFooter. action) is not available > " error. That's odd. Did you try to call the action directly?
Yes, calling an action directly works fine. For me this is also confusing. I've just rechecked everything with a very simple example and still have the same error. I'll try to debug a little bit more later today and try to pinpoint a source of the problem. BTW: struts-tiles plugin is managed by the Struts2 team? Or the Tiles2 team?
The "pain" could be that of "average" users, that do not need too many types. But probably this is the best path to follow.
For an user relaying only on "default" attribute types we should register only "default" renderers. This should be default configuration of the BasicTilesContainer. The "complexity" would be visible only for the developers aiming to add new attributes. Cheers, Pawel
