On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady
<[EMAIL PROTECTED]> 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 interested
> >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 (http://incubator.apache.org/projects/myfaces.html)
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
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
