On 12/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I think Struts is pretty cool. But JSF seems to be the future so I am now > learning it. But I am getting really confused about Shale versus pure JSF > versus Struts. Maybe Craig McClanahan can give me some more insite into > what I should be learning for my next Java based web project. Is JSF the > future? And if it is which JSF should I be learning?
One of the most important lessons that newcomers to the software realm need to understand is this: there is no "one size fits all" answer to any significant engineering problem. Fundamentally, in the Java-based web application architecture space, two schools of thought are emerging as very popular ... an "action framework based approach" (Struts 1.x, WebWork, Spring MVC, ...) and a "component based approach" (JavaServer Faces, Tapestry, ASP.Net, ...). Both approaches have their adherents, and the programming styles involved will tend to attract developers with different tastes for things like "object orientedness" and where the responsibility for creating the actual view tier markup should be placed (put way too simplistically, templates versus components). But both architectural styles are viable, and neither one is going to go away any time soon -- although I will contend that both architectural styles will need to pay attention to what AJAX means to the craft of creating web applications. So, which should you learn? Depends on what you are planning to do. If you are tasked to maintain and enhance an existing Struts-based (or WebWork based, or whatever-based) application, it would certainly behoove you to become an expert in that underlying technology :-). If, on the other hand, you are facing a new project, you need to evaluate issues like: * How long do I have to complete it? * What's the expertise level of my team with the various technologies? * Do I have a budget (time and/or $$) to acquire expertise and/or tools that support the various technologies? My personal belief is that component oriented development is more accessible to a wider array of developers than action oriented frameworks. Therefore, I spend my time (disclaimer: I'm paid to do this too, but that doesn't cover much of my open source effort :-) working on technologies that are designed to increase the overall number of developers in the world that are using Java based technologies. Does that mean JSF is "better" than action oriented frameworks? Depends on your goals -- for my goal, it is, but remember .... this is not a "good" versus "bad" dichotomy ... its "better" (for this particular goal) versus "good". One other potential confusion around JSF, in particular, is that it can be viewed as having a couple of different "personalities": * JSF is an API for user interface components that happens to support a view-tier oriented controller tier. * JSF is an extensible controller tier that also has a robust view tier API for components. Nearly every existing web framework can claim "we integrate with JSF" based on viewing it as the first personality. What you end up with is the ability to use the emerging set of JSF components that are available, but you're not leveraging the fact that JSF knows how to do things like navigation between pages as well. Shale was (until Seam came along) the only framework I know of that took the second viewpoint -- Shale is all about leveraging existing JSF capabilities as the front controller, and utilizing its extensibility APIs to add functionality and/or ease of use, *without* reimplementing fundamental things (like validation and navigation) that JSF already supports. Starting from this viewpoint lets Shale be a *lot* smaller (read, "less for me to have to learn"). Indeed, the core of Shale is currently around 112kb (versus nearly five times that for Struts 1.2). Yes, you need a JSF implementation as well, but that's not a long term problem ... any app server that implements Java EE 5 is going to be required to support JSF, just like it's required to support the servlet and JSP APIs, so it's going to be built in to your servers already -- and, if you use a standalone container like Tomcat, you can accomplish the same result by putting either the JSF RI or MyFaces into the shared library directories available to all webapps installed on that server instance. So, to answer your original question, it is in your economic best interest to understand both kinds of technologies, and to learn which ones to apply in which circumstances. Buf if you find that JSF fits your needs for a particular project, you'll also want to investigate Shale, because it smooths off a bunch of the edges of component based development -- to say nothing of providing functional equivalence with Struts 1.x support for things like client side validation and support for Tiles. --Brad Craig