velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <>
Subject Re: JavaServer Faces and Velocity
Date Sun, 06 Mar 2005 19:35:39 GMT
marcus eber <> wrote:
> Is it possible to use Velocity and JavaServer Faces. I know there are
> Velocity Tools for Struts. 
> What about JavaServer Faces?

It's possible, but I don't think I've seen any publicly-available 

You can take a look at this url on creating custom JSF ViewHandlers.  Page 2 
is probably of the most interest.

Improving JSF by Dumping JSP

I'd be interested in hearing a report on whatever you find out or whatever 
you decide to implement, as I'm also considering this option.
I suspect that the Velocity Tools project would be interested in any 
ViewHandler implementation you come up with.

Below is some info by Craig McClanahan on the subject, but again, he 
primarily points you back to Hans Bergsten (author of the above URL) and his 
book.  I haven't been able to flip through his book yet as it's not at any 
of the local stores.


Begin forwarded message:

Date: Tue, 26 Oct 2004 12:50:05 -0700
From: Craig McClanahan <>
Subject: Re: Struts Shale
In-reply-to: <>
To: Struts Developers List <>
Reply-to: Struts Developers List <>
Message-id: <>
References: <2004102611440.542770@PC15> <2004102694227.321917@PC15>
List-Id: "Struts Developers List" <>

On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady
<> wrote:
> Niall Pemberton wrote:
> >OK Craig didn't say it was "JSF only" - but that was my interpretation of
> >the likely direction.
> >
> >He said "The interface as currently defined is not dependent on JSF" but
> >then went on to say that JSF already solves a whole load of the view tier
> >issues and re-inventing them outside JSF is "...not an effort I'm 
> >in actually doing, and IMHO it would needlessly complicate the overall
> >architecture -- but it's technically feasible."
> >
> >Niall
> >
> My understanding is that the interfaces will be optimized to a JSF
> "emphasis" but amenable to and sensitive to any other options nuts like
> myself might want to code.  Is that right, Craig?

Let's look at this from a variety of perspectives:

* The proposed Struts Core doesn't contain or use any
  JSF components -- it presumes the use of the infrastructure
  stuff (managed beans, expressions, navigation mapping,
  as well as the basic request processing lifecycle)
  that is darned useful, and would have to be reinvented
  by any non-JSF-based implementation anyway.

* JSF itself is bound to JSP substantially less than Struts is,
  even though a JSF implementation is required to support JSP.
  For example, if you like Tapestry's approach of a separate
  HTML file containing markup with id attributes that correspond
  to a component tree, that's a very straightforward thing to
  implement -- indeed, Hans Bergsten's book gets you about
  80% of the way there.  Or, if you want to output WML or SVG
  instead of HTML ... that's nothing the controller need concern
  itself with -- just pick the correct JSF renderers.

* The same thing could be done for any other templating
  technology that has some way to establish the data bindings
  (Velocity macros, for example) and is accessible via
  RequestDispatcher.forward() or a programmatic interface
  to actually do the rendering.

    I'd be OK with having a subproject lying around
    that implemented one or more of these adapters
    for view tier technologies; I can provide design
    assistance but not much in the way of development
    help due to time constraints.

* That being said, JSF goes far beyond just using templates,
  because it provides a sophisticated component model (so
  you can build things like tree controls and scrollable tables)
  and an event model optimized for component oriented development.
  Choosing a templating technology which forces you to give that
  up seems to me a sub-optimal choice.  But it could be done,
  if we're willing to simulate the controller-level parts of JSF.

* Even if the core controller part of Struts was JSF-agnostic
  (except for an implementation of the APIs based on it),
  you still can't write an application on top of this without committing
  to a choice in view tier technology.  The more stuff like how
  validation errors are propogated that we have to abstract in
  order to be JSF-agnostic, the more complicated we make
  the architecture; and the more code we have to wrte and fix
  and document and test.

* JSF is going to be part of J2EE 5.0 anyway, so rumors of its
  imminent demise are not credible :-).

* Indeed, Apache is currently incubating an open source
  implementation (
  that will, naturally enough, be Apache licensed and suitable
  for distribution (once it passes the compatibility tests).

* Finally, there's a "marketing" viewpoint :-).  The world has changed
  since Struts was first developed, and there's so many frameworks
  out there that people get laughed at on TheServerSide etc. for
  creating YAWAF (yet another web application framework).  Without
  some distinguishing characteristic, what (besides the "Struts"
  name) would we bring to the table that all the other non-JSF-specific
  frameworks already do?

My personal itch is to not have to build everything from scratch --
its to build on the JSF request processing lifecycle, without
committing you to any particular view tier templating approach.  Doing
more work than that is ... more work.

> Michael McGrady


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message