Craig McClanahan wrote:

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

Thanks Craig. I guess now my question is when will I be able to buy books on Struts/Shale. As a long time Java developer I bought three Struts books and picked Struts up in two weeks. I was able to quickly learn Struts and I am picking up JSF pretty fast also. But now I want to learn the Struts/Shale combo.
--Brad.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to