DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33752>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33752 ------- Additional Comments From [EMAIL PROTECTED] 2005-03-20 04:29 ------- Hi Gary ... sorry it took so long for me to get to this. I've been on the road WAY too much lately, and the "day job" work doesn't stop piling up just because I'm travelling :-). I've got several thoughts to share about this proposal, with numbered bullet points in the comments below. Feel free to discuss them here, or on the Struts developer list (which might be more convenient for wide-ranging discussions). (1) Minor nit -- in widgets.jsp, you used an "id" attribute value of "pages$widgets" for the third button. This violates the specified rules for component ids (see UICompoennt.setId()), which the JSF RI enforces but MyFaces does not. (2) The term "subview" means something specific in JSF, and I don't think we should really be trying to overload it for something that is as different as this concept (the Shale version of "subview" is just like the JSF version, but merely adds the view controller lifecycle processing for each subview). The name "tiles" would fit nicely, but it's taken :-). So, we're going to need a different name. My assumption for the remainder of these comments is that we might call it "subtree" instead, although I'm certainly open to other ideas. (3) The requirement to explicitly list all the xxx-config.xml files in a web.xml file is going to get very tiresome on a large application. It would be better to find a strategy that does not require this. (4) In addition, I suspect most developers will find it more comfortable to include the source documents defining their subtrees under WEB-INF (perhaps in a WEB-INF/subtrees) directory, where they can be loaded as needed. (5) The relationship between a JSP page (widgets.jsp) and a corresponding configuration document (widgets-config.xml) is a little puzzling to me. That seems to imply that the subtrees defined in that configuration document are not reusable on different JSP pages. Wouldn't we really want a more global mechanism to define reusable subtrees (like what Tiles does with tiles definitions separated from the pages using them)? (6) As currently implemented, all the "magic" is embedded in the tag handler for the <sh:xsubview> tag. That works, but seems to constrain this technology to use only when JSP pages are the view mechanism. It would be very interesting to embed the functionality in a component itself, so that any desired view technology could be used. (7) Putting some of the above thoughts into a little bit of virtual scribbling on a whiteboard, consider some sort of reusable definition of a round button (as in your widgets example) that was like what you've got in widgets-config.xml). But the *use* of this subtree definition could look like this: <sh:subtree id="button1" subtreeId="googleLoveWidget"/> or be customized (in the "using" JSP page) like this: <sh:subtree id="button1" subtreeId="googleLoveWidget"> <sh:element renderId="5" elementId="outputLink"> <sh:attribute name="value" value="http://www.google.com/search"/> </sh:element> </sh:subtree> In other words, you could do one-off uses of reusable subtrees directly, without having to define one separately. For something like this to be generalized, element and attribute would probably need to be components as well, but they wouldn't have any actual rendering of their own -- they would merely be the configuration mechanism for the changes to be applied to the subtree selected by the <sh:subtree> component. What do you think? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
