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]