On 12/29/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 12/29/06, Gary VanMatre wrote: > > > > >From: "Craig McClanahan" > > > > > > 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. Oh, right... How about "org.apache.shale.clay.component". There are two components here.
Yah, that makes sense ... and is consistent with what I did with the package containing the token component in shale-core.
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. > I suppose that you might import these components if you used "binding" to the backing bean but maybe that's assumed with any JSF component.
"Assumed" maybe ... part of my goal with this page is to set correct expectations for what application developers *should* feel OK about importing, and where they should keep their pitty pats to themselves unless they are more advanced ;-). Adding "o.a.s.c.component" makes sense for that goal. Being explicit about all the rest being framework level things should help us set correct expectations for the future. (And, we can always promote a particular package to the "app developer" list later if it's found to be useful.)
> Craig > > > > Gary > > > > > Craig
Craig
