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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > >
