myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: Tomahawk release plans?
Date Fri, 16 Mar 2007 15:34:06 GMT
Velocity is a fine tool -- I use it all over the place.

Because of my experience with Velocity, I've looked into the attempts
to use it as viewhandler.   It's not an ideal fit.    Facelets does a
much better job.     Velocity is not the right tool for the job.

http://people.apache.org/~matzew/jsfvelocity.html

On 3/16/07, Jörn Zaefferer <joern.zaefferer@googlemail.com> wrote:
> I like the approach of renderers written in velocity. Sounds like a logical
> approach to me: Take a language with enough power that was written for
> exactly the thing you need to do.
>
> Fortunately JSF is quite flexible when it comes to exchanging certain
> components like view handlers. Have you done any research on actually
> implementing a JSF renderer in velocity?
>
> On 3/16/07, Werner Punz <werner.punz@gmail.com> wrote:
> > Jörn Zaefferer schrieb:
> > > I'm not familiar with Velocity, therefore I'd like to know how velocity
> > > handles "logic" in its views. JSF in general does a good job avoiding
> > > any classic if/else and loop constructs in my views. Can I get that with
> > > Velocity, too?
> > >
> > actually jsf tries to avoid it and then mixes it in again via helper
> > constructs (datalist in tomahawk or ui:repeat in facelets), thing is,
> > that a templating mechanism basically has the same
> > language needs as every other language, which is
> > sequences, iterations and selections!
> >
> >
> > JSF/EL follows the we want to be as minimalistic as possible approach
> > and fails so far that the core language constructs had to be added via
> > crude helper constructs.
> >
> > Velocity is on the other side of the fence, it adds a full blown
> > language for templating which is as far as possible from xml to make a
> > visual difference in editing, but it still tries to keep a clear border
> > between model/controller and view.
> >
> > So what you get is, a full blown language on its own, with macro
> > capabilities, an internal macro compiler and cacher, and still a clear
> > border which is needed in mvc (one of the reasons why JSP itself is a
> > bad solution is that it blurs those borders)
> >
> > So a typical velocity construct looks like this
> >
> > <h1>$component.myvalue</h1>
> >
> > #if($compoment.myvalue == 'A')
> >    #macro1($component)
> > #else
> >    <h2 styleClass="error"> component value is not set </h2>
> > #end
> >
> >
> > so where is the difference to the printwriter...
> >
> > the difference is, basically an inversion of rendering,
> > you basically define the renderers in the language you want to target,
> > but with a full blown programming language underneath it which allows
> > encapsulation of code parts sequences and iterations, but the
> > strict cut between component as model/controller part is still there,
> > the code is just shifted into a domain which is easier to maintain, than
> >
> > hundreds of lines of prints and calls into constants.
> > I personally see this approach more feasable than a crude
> > html/el approach or an approach of adding helpers ot the printwriter,
> > or even worse the introduction of another jsp layer onto the component
> > renderer where scriptlets are reintroduced again.
> >
> >
>
>

Mime
View raw message