Re: [Shale] Enhancement to the Shale subview tag library component.

[gv...@comcast.net]

> Craig wrote:
>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.

Oops, I didn't know that. I was originally using the "mbeanMnemonic" attribute on my subview to define the bean name that would be substituted within the bindings defined in the XML config files. The value of this attribute would be substituted for the literal "managed-bean-name" before the expression was bound. For example, the expression "#{managed-bean-name.next}" might resolve to "#{widgets.next}". When extending the shale subview, I used the Id attribute because I thought the ideas where very similar. I wanted to override the method to get the ViewController name but I believe it was private. Maybe a separate attribute would be better in case several of these subview components were placed in the same JSP and they all needed to bind to the same backed bean - to avoid name collisions. 

>(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.

I agree that might be too confusing. I like subtree but it's not something as easy to associate with like tiles, a house hold item . What about "clay"? It's soft, pliable but when compacted together by pressure it can make building bricks - in nature Shale. Kind of corny? 

>(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.

Could these file be registered to the application like faces components? The base definition placed in an XML file in the META-INF folder of the shale jar where all the standard and Shale components could be defined by default? 

>(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.

The reason that I placed the configuration files under the source directory was that I didn't want to couple the loading of these files with the ServletContext, and I didn't have a FacesContext yet. I also wondered, if an Application subclass would be a better cache than application scope? I bet I could find some help finding a better solution here :-) 

>(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)?

It looks like there is a one-to-one association between a config file and a JSP's in the example but all the files are loaded on startup. I did this thinking, it would be easier to describe the examples. Like struts and faces, I thought it would be nice to allow the developer to decide how to best organize within an application. 

>(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.

I agree, that's a lot of logic in a tag. Refactoring to a component or a utility class would make it more reusable. I was also thinking it would be a cool feature if there was events in the subtree component when the subtree was built. Perhaps this would allow the subview definition to be defined dynamically or alter based on the model data? 

>(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.

That would really be a powerful combo. I guess the subtree tag/component could build the tree and the other tags would just find the element in the component tree and override an attribute. This would allow overriding deep within the tree.

>What do you think?

Gary