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
