> >>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 its 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.
The approach in Clay is to provide a stand-in for constructing a sub-tree under
the JSF component tree using something other than JSP tags. This means that
all the rendering is done by the JSF components or more commonly the associated
renders.
The rendering performance would be the same as if the entire component tree was
assembled from the JSP tags. The benefit is that this metadata provides
inheritances and reuses that you can not get from JSP tags (a.k.a. faces tiles).
I think that a common misconception is that the JSF jsp tags render the
presentation where there function is really to construct the component tree and
invoke rendering.
>
>
> 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.
>
The approach that I was taking was to build the JSF component tree from the
rendered Velocity document (dual processing) but if you can build the JSF
component tree from the Velocity template rendering that would be very
interesting.
> 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...
I see. So you might have a template that looks like this?
Enter your Name: #set( $component = $JSFHelper.createComponent("input") #set(
$component.action = "#{managedBean.name}")
I'm not sure how you would merge the output in the template with the rendering
of the component tree without dual processing? The inline text "Enter your
Name: " should also be a jsf component.
Gary
>
> Werner
>
