>From: Laurie Harper <[EMAIL PROTECTED]>
>
> Yee CN wrote:
> > I am in the middle of migrating to facelets and at the same time planning
> > for Shale. It seems to me that Shale Clay and Facelets templating overlaps
> > to a large degree. Is there any guideline on whether the two should/can
> > coexist and which one should be use for any particular circumstances?
>
> They probably can co-exist, but I'd strongly recommend not trying to
> make them ;-)
>
>
> Yee CN wrote:
> > I am in the middle of migrating to facelets and at the same time planning
> > for Shale. It seems to me that Shale Clay and Facelets templating overlaps
> > to a large degree. Is there any guideline on whether the two should/can
> > coexist and which one should be use for any particular circumstances?
>
> They probably can co-exist, but I'd strongly recommend not trying to
> make them ;-)
>
This is more of a reflection on JSF. JSF kind of assumes that you are
only going to pick one type of view technology. Clay cheats using
a filter chain that captures the type of view before the suffix of the
view id is changed.
> You're right, they do overlap a lot. In fact I think they're pretty
> close to functionally equivalent, bar syntactic differences and a few
> minor points. I don't know Clay well enough to say that with certainty,
> though, so if Gary shoots me you'll know why ;-).
>
No, I think they do cover common ground. I would say that
the biggest difference is that the core extension point for clay is
rooted as a component. This gives Clay a couple more
options. You can use clay in JSP, HTML and XML views.
They can also be intermixed to a certain extent. The metadata
used to build the component tree could come from other sources
in the future.
Another difference is Clay's meta-data inheritance - similar to tiles.
This provides the classic OO vertical inheritance. Clay also has
something unique called symbols that is a parameter substitution
layer on top of EL. Symbols allow you to inject customizations
horizontally into an inheritance hierarchy. They can also be used
to create generic tiles like layouts.
In terms of HTML tapestry like views, Clay supports old school
html. It's very forgiving in it's parsing. However, many probably
prefer the required XML facelets approach.
Another strength for Clay is that it's already part of Shale package
(Shared code and Struts community).
> So my advice would be to pick either one or the other. Personally I did
> as you are doing: started using JSF, then started using Facelets, then
> added Shale into the mix. You can pick and choose which bits of Shale
> you use, adding in each feature as you have need for it, so this works
> well. And if you did want to start using Facelets today but switch to
> Clay later, it shouldn't be too big a deal.
>
I've only looked at the facelets features. Never taken it for a walk but
I'm sure it's top-shelf.
> You could also start using Clay directly, without having to immediately
> start using any of the rest of Shale until you're ready to do so. With
> the possible exception of the View Controller feature, I don't think
> Clay requires much else.
>
Clay does depend on features in Core Shale. The view controller and
filter chains are required but you can pick and chose from there.
> Gary will no doubt be able to add additional insight.
>
>
The core mission of Clay is targeted at "reuse". We've taken a step
or two backwards from the visual object oriented tools for building
GUI's. JSF is targeted for delivering event oriented, component based
web development. Is cut-and-paste and exceptable level of reuse?
That's the question that Clay tries attempts to challenge.
> L.
>
