On 12/29/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
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.)
OK, the website has caught up with all but one of my changes (the package name for the shale-view package is mistagged as org.apache.shale.validatorwhen it should be org.apache.shale.view ... I've already committed a fix for that ... take a look at [1] and make any last minute comments you'd like to have included before we finish up a 1.0.4 release. Craig
> Craig > > > > > > Gary > > > > > > > > > Craig > Craig
