[EMAIL PROTECTED] wrote:
I was thinking about maybe using the "Facelet" approach for the
component creation as well - this is basically exact the same stuff as
defining the components by using JSP. I don't know how to do loops and
stuff like that then, though...
The Clay component under Shale is another example of using an alternative
method of adding components to the component tree. There is an example in the
uses cases for using xml and runtime composition. An HTML layout use case is
coming soon.
I originally had considered Velocity integration. The concern that I had was that if you could not create JSF components and associated listeners, converters and validators, you really only have a sophisticated outputText component and your really missing out on allot of what JSF has to offer over Velocity.
The approach that I was taking was to merge a document using Velocity and
reparse it building a JSF component tree. Craig was not comfortable with this
dual processing and David ended up steering us to the Tapestry like views.
Not that it’s directly relevant to this thread…. but I thought I would share
our experience.
Gary
Hi Gary I do not really see the problem here.
Your approach sounds interesting, but I see it also as a little bit to
complicated... You might get better performance using velocity to render
the pages instead of using it as a component renderer.
But I think Craig was right with his opinion that dual processing might
be a problematic route.
But I think there might be another approach if we follow the approach in
this thread of per component rendering.
Velocity is only a templating language, and probably the best there is
currently (combined with WebMacro).
The problem I see what you mean with providing the entire infrastructure
is to get more stuff up and running, like the event system, you
basically have to add some kind of rendering infrastructure into the
velocity context which allows you to render the additional data and
scripts into the template which are needed for the rest of the
mechanisms (most of them are dynamically rendered javascripts)
I do not see a real problem there, it is however a lot of work, because
what I could gather from my limited works on the components, most of
this rendering stuff is helper methods which are somehow referenced from
base components and those reference back into helper classes.
If you go that route for velocity, I would recommend to follow the tools
approach of Turbine. Turbine basically uses IOCed classes which are sent
into every rendered velocity template, they are used for many things
(therefore called tools)
And those tools for instance in Turbine are used for creation of static
links out of dynamic and semi dynamic data, or delivering entire control
sets (which is what I did once)
Rendering that stuff in velocity probably should follow a similar
approach of providing tool objects for every rendered template, which
can enable the actions and other stuff, basically a lot of
infrastructure JSF provides...
Werner
