On 12/29/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > I updated a big first pass fixup on the api-stability page (source is > framework/src/site/xdoc/api-stability.xml), but the website did not get > regenerated and republished as it usually does. Is there something we need > to do to trigger that? > > In the mean time, please review the source file for content. A particular > question for Gary is whether we want to mark any of the " > org.apache.shale.clay" APIs as being designed for direct use by an > application developer in a webapp, or if that is all supposed to be behind > the scenes and all you are doing is using the components themselves in your > view. > I think your right-on to say that the clay component and metadata sources are the strongest extension points. I've thought about making interfaces of the config beans so that it would be easier to define alternate sources for the metadata used to build the subtree. This is an area that the JSF spec doesn't address and I wonder if it will be covered in JSF 2? I wouldn't be surprised if we see some templating extension that is similar to facelets which might be another option for Clay to support.
It seems likely to me that JSF 2 will deal with non-JSP view handlers in some fashion, but that's ultimately up to the EG to decide -- and a JSR has not even been filed yet. It might be best to keep the published API based at a Component that is
loosely defined by various metadata sources. Please add the "org.apache.shale.clay" package to the public API list.
Well, I would ... but there are no classes or interfaces directly in this package. What I did for the other packages was identify those that had classes or interfaces you'd expect to import into the Java code in a webapp. Is there anything like that in Clay? The only thing I can see in the sample apps is the use of org.apache.shale.util.Messages from shale-core.
Craig Gary
Craig
