Okay, maybe velocity isn't the right tool as a viewhandler, but how about a renderer? The renderer only renders HTML, no need to worry about templating or building a component tree.
On 3/16/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
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. > > > > > >
