> I think this is all good stuff, but I'd rather see integration with 
> Tiles instead of reinventing Tiles. Tiles has already covered some of 
> this ground and I see no reason for us to follow. 

 
I would also like to see tiles integrated.  You really have some interesting 
points about Tiles and SiteMesh on you blog.  I really had not thought about 
the distinction of decoration verses composition.  I really see this subview as 
more of a decoration strategy as it is a replacement/ stand-in for the JSP JSF 
tags adding reuse thru inheritance and composition.

> 
> I'd also like to see integration with SiteMesh, which excels at page 
> decoration (as opposed to Tiles, which excels at page composition). 
> I've been talking to the folks on the SiteMesh mailing list about 
> integration between Tiles and SiteMesh, but that of course, is outside 
> the context of JSF. We could do a lot of cool things in Shale to 
> provide a unification of JSF, Tiles and SiteMesh without reinventing 
> any of those technologies. 

I think it would be an interesting option to be able to pull in a SiteMesh 
generated template into a faces page.  However, if you where not able to add to 
the JSF component tree, you are really missing out on so much of what faces has 
to offer in terms of event binding and listeners.  Without providing this 
support, in faces terms, your only providing a fancy outputText component.

> 
> Remember that this mindset is the cornerstone of Shale: Shale aims to 
> augment JSF, not reinvent it, and IMO we should take the same approach 
> with other open-source software that we support. 

The only thing that my component reinvents is the the faces JSP tags.  With 
standard JSP tags, you are limiting your reuse to just composition.  Using this 
XML metadata provides a means to create reusable and extendable view 
compositions while using the faces components and associated renders.  


> 
> 
> david 
> 
> Le Mar 12, 2005, à 9:44 AM, [EMAIL PROTECTED] a écrit : 
> 
> > This would be the second attempt but I would like to start a 
> > discussion on a Shale subview component extension. 
> > 
> > Currently, The shale subview jsf component provides a post-back method 
> > to the prerender method on the ViewController. The id attribute of 
> > the component is assumed as the managed bean name. This method would 
> > be very useful for staging data for the subview and promoting reuse. 
> > 
> > The extension would add the following features: 
> > 
> > * Fragments of a page could be created using a XML definition and the 
> > same node structure would cover all components making it very 
> > abstract. A top-level component could be represented by a 
> > displayElement node and associated to the logical name of the JSF 
> > component using a componentType attribute. 
> > 
> > * The describing documents could be digested at application startup 
> > and all inheritance resolved at startup. Checks for circular 
> > references would be applied. 
> > 
> > * Like tiles, the metadata defining the subcomponent tree would 
> > support generalization inheritances and also composition inheritance. 
> > Top-level displayElement definitions can extend other top-level 
> > dislpayElements. Composition is formed using the element node that 
> > includes and overrides attributes of the target top-level node. 
> > 
> > * It would also allow a token replacement feature of the binding EL 
> > so that the metadata describing the construction of a subcomponent 
> > tree could be reused on multiple managed bean names. Featured with 
> > the Shale life cycle methods on the ViewController, would provide many 
> > more reusable view compositions. 
> > 
> > 
> > This composition technique could be used in conjunction with other 
> > methods too. A sample application can be downloaded from the tracking 
> > system. I removed the libraries to make the upload possible. The 
> > example uses the myfaces JSF implementation and the Shale library. 
> > 
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=33752 
> > 
> > Regards, 
> > Gary VanMatre 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [EMAIL PROTECTED] 
> For additional commands, e-mail: [EMAIL PROTECTED] 
> 

Reply via email to