Craig McClanahan wrote:
This is very well said. Using MyFaces and its tiles integration, the need of struts 1.x seems to be redundant.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:
I may have misunderstood, and I am at a disadvantage because I amAren'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.
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.
Struts-shale adds value on top of current technologies with its framework of request processing and addresses, in a framework fashion, application and dialog controllers. Combining this with IoC framework such as Spring, we will have a very clean elegant web application framework to work on:
1) The application is completely configurable with faces-config and IoC-config. There is no need of digester and writing your own codes to instantiate the beans.
2) We can separate beans for UI components in faces from value-holding objects in IoC contaier and programmatically wire them together in a very clean fashion using facilities of underlying frameworks.
3) One valuable feature that shale can address in a framework fashion is a standard way of incremental authentication (challenge) when specified by the requested resource.
BaTien DBGROUPS
I don't understand your idea of a "view controller", Joe. The "viewI 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?
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]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
