Intermixed as well.
On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> Various people's comments are interspersed with my own below...
>
>
>
> >What intrigues me about JSF which I haven't been able to find out
> >yet, is whether JSF is also only meant for light-weight apps. Does
> >JSF's tendency towards page-driven Commands Pattern implementation
> >as Craig mentioned put it in danger of encouraging such Bitter Java
> >anti-patterns?
> >
> >I also gather that JSF's Controller implementation of the MVC
> >framework is not nearly as robust as the Struts implementation.
> >Would a large application that wanted to use JSF also need Struts?
>
> I think this is exactly the point. JSF's controller model may not
> scale to a large application. However, in the Shale proposal, JSF's
> controller model is only being asked to control the view. Right now,
> Struts doesn't have a separate concept of a "view controller," and I
> am finding that a limitation. I would like a clean facility for
> prepopulating forms from system data which interoperates with the
> existing mechanism for prepopulating forms when validation fails and
> the user must try again. I would also like a clean mechanism for
> doing certain kinds of page preparation based on the destination page
> rather than the processing action. I feel that this cleans things up
> and supports a nicer separation of concerns. Neither of these is
> easy in Struts today, and I think the way forward is to more
> explicitly model a "view controller" subcomponent. I think Craig
> believes that JSF has already done that. I still have to find out
> for myself.
>
Consider the very typical pattern we use in Struts, with a setup
action, a JSP page, a form bean, and a processing action -- plus at
least four configuration entries in struts-config.xml (two actions --
one with validation disabled for no obvious reason other than "that's
the way you have to do it" -- a form bean, and a forward.
Now, go download the Shale source, and check out the source code in
contrib/struts-shale-mailreader, which contains the source for the
canonical Struts example application, so we can all see the
difference. Note that this pattern takes a JSP page, a ViewController
class, and one configuration entry. And there's less code to boot --
to say nothing of the fact that the code is *much* simpler.
My guess is that the average Struts 1.x application, if re-implemented
with Shale, would lose 10-20% of it's Java code line count, and about
the same percentage of its configuration file line count.
> >Aren't Struts and JSF in the end really competitors? Seems so to me.
> >I cannot see them merging in any sensible solution.
In the areas where they overlap (custom tags on a JSP page), there is
competition. However, JSF has things Struts doesn't (real UI
components), and Struts has things JSF doesn't (real per-request
processing).
But your point is well taken, which is why Shale proposes *not* to
combine the existing Struts with JSF -- instead, just build the Struts
functionality as *plugins* to what JSF already provides, so there is
no overlap.
>
> No, I don't think so. JSF is primarily focused on the view. Struts
> is only partially focused on the view. I think it's plausible that
> they could cooperate, even though I haven't yet decided that that's
> the best way forward. As noted above, I suspect that trying to use
> JSF as a complete controller solution would lead to the same kinds of
> problems people had in "Model 1" (JSP-centered) development.
In what respect? Separation of concerns is pretty much the same if
you follow good design practices in both approaches. The view
controller code is much easier to unit test, because it doesn't tie
you to servlet apis (and, of course, that makes it much easier to
incorporate into portlet environments as well).
> >I don't think that this note by "Vinny" is unimportant. I like the
> >idea of something like JSF for the view. I am not sure I like the
> >controller architecture which it uses and which, i think, ultimately
> >is a choice inconsistent with Struts, which I like.
The point that Vic is making is that there are people who don't
consider the fact that EJB is part of J2EE is sufficient reason to
justify its use. That's fair -- and I don't justify it that way; it's
only a reassurance that it's not just a shot in the dark technology,
and will be supported by more than one vendor.
The point that Vic and other EJB-bashers miss (and probably hate) is
that, despite all their bitching, there are *massive* numbers of
applications that successfully use EJBs. Like any other technology,
it is not a panacea for every single app. But it *is* being
successfully used.
> Personally, I agree that using JSF simply because it will be
> including in J2EE 1.5 (or 5.0) isn't reason enough. But can you
> elaborate on *why* you don't like the controller architecture that
> JSF uses, and why it's inconsistent with Struts?
>
> I still feel pretty ambivalent about depending on JSF for Shale, but
> while Craig has defended his arguments, I haven't heard many serious
> points against it. Maybe everyone else needs time, like I do, to
> really absorb the implications and look at some real scenarios --
> Craig does have a sort of "unfair advantage" given his deep
> involvement in both Struts and JSF. But still, I'd like to hear some
> more substantial arguments against than have come up yet.
>
That's why I'm not trying to press the issue towards a vote in the
short term. Instead, I'm showing how I feel in code more than in
words -- including a version of the example that everyone is familiar
with to show how much simpler it is than using Struts 1.x.
If anyone want to convince *me* to support something else, they'll
have to do the same thing. Unsubstantiated generalizations, or
aesthetic arguments ("JSP sucks because I hate the syntax for custom
tags") just isn't going to cut it with me :-).
> Joe
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
