DO NOT REPLY [Bug 33752] - [Shale] Enhancement to the Shale subview tag library component.

[bu...@apache.org]

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 craig.mcclanahan@sun.com  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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org