Intermixed.
On Tue, 9 Nov 2004 10:47:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Thanks, Joe, > > Some thoughts below: > > > > > On Tue, 9 Nov 2004 12:26:22 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > > > > >Aren't Struts and JSF in the end really competitors? Seems so to me. > > >I cannot see them merging in any sensible solution. > > > > 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. > > > > I may have misunderstood, and I am at a disadvantage because I am > still trying to get a good idea of what JSF is all about, but I > thought that Craig saw any merger between Struts and JSF as a > temporary thing which was fundamentally not a long run arrangement. That's a little too simplistic to represent my opinions. There are two fundamentally different worlds to consider -- the thousands of applications already built on top of Struts, and the thousands of applications that will be written in the next few years (and are looking for technologies and architectures to base themselves on). For existing apps, Struts has always embraced new technologies (see how JSTL, and in particular the expression language from JSTL 1.0, has been incorporated). The basic idea has been to allow existing apps to incorporate these new technologies, *without* throwing away anything they've already built. Indeed, this approach has been one of the reasons Struts is so popular. Supporting JSF *just* for its visual components (in the struts-faces integration library) is no different. It would be *irresponsible* for the Struts developers not to embrace this, and allow existing apps to take advantage of the new generation of visual components that is emerging, without making you throw away your Action and ActionForm classes, your client side validation, your Tiles, and so on. That being said, there is significant overlap in functionality between JSF and Struts 1.x -- so much so that it is pretty difficult to contemplate using the combination in new apps. For example, which technology are you going to use for validations? for page navigation? Quite frankly, if you don't need the validator framework or tiles there isn't a tremendous amount of value add in trying to combine the two technologies (and the MyFaces folks have even removed Tiles from that equation, because they integrate with it directly). Struts needs to do something useful in the *application controller* tier ... the view has been done. > > >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. > > > > 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 don't understand your idea of a "view controller", Joe. The "view > controller" is a controller which is not something different from the > Struts "controller" is it? The controller, from my perspective needs > to be decoupled from the view. A "view controller" is just another > way of saying, if I understand, that the view and the controller will > be coupled. That's exactly right. For background, go grab a copy of the "Core J2EE Patterns" book, and look up the "View Helper" pattern. That is exactly what a view controller is doing. There's one view controller per page. > Ultimately, of course, there has to be some interface between the view > and the controller. I would wish there were an interface that could > adapt the Struts architecture with the JSF sort of view intricacies. > However, I don't see that the event-based, page-based, JSF approach > can do that. And I don't see *why* you want to do that? Can you explain what advantages you perceive from such a combination, even if you cannot articulate how the problem might be solved? Note that Shale's proposal still contemplates some application-level things that would happen on every request (authentication, for example) ... it's just that it assumes you'll use existing container facilities (servlet filters) so we don't need to waste our time building Struts APIs to do exactly the same thing. > > I admit I am struggling with this and do not claim to speak with any > authority in fact or in understanding. The ideas I have seen seem to > be running counter to my intuitions, just like they are with Adam > Hardy. I have that same sense but am not sure I am right at all. I > certainly don't want to get things wrong and maybe I am completely > muddled about this. I have not seen that so far, however. It will really help you to download the Struts nightly source code build, and examine the application in the "contrib/struts-shale-mailreader" directory. This is the exact same application that is shipped with Struts (struts-example), and you can see from the dramatically simpler code and configuration why I kinda like this approach :-). > > Sorry for going on so long. > > Jack Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
