struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <andrew.david.h...@gridnode.com>
Subject RE: what the webwork guys say about struts
Date Wed, 16 Jul 2003 10:20:12 GMT
<snip src="wiki.opensymphony.com">
WebWork’s pros include being a smaller, simpler framework, not having to
build ActionForm beans, making it very simple to test your Actions, having
multiple well-supported view technologies, simpler views with less JSP tags
and a more powerful expression language, not having to make your Actions
thread-safe, not having your Actions tied to the web, and not being part of
Jakarta J. WebWork2 also adds many new features such as Interceptors,
packages, IoC, etc. WebWork’s cons include being a smaller project with
fewer books and less tool support, having less standards support for specs
like JSTL and JSF, and not being part of Jakarta
</snip>

Fair enough to a point, but Id definately disagree about struts not
providing good support for using other views. There is nothing in struts
that specifically makes it hard to support other view technologies - the
taglibs that come with struts are purely a convienience for the majority who
use JSP (theres a good argument to make them a seperate download imho) - but
theres nothing anything to stop you using other things. Many people use
velocity with struts - its a good fit from what I hear, and you could use
pretty much any other technology too so long as that technology doesnt
depend on some proprietary framework to be used with it (which would affect
WW also). All the struts config objects are accessible from the servlet
context and there are even toolkits for technologies such as velocity... I
personally use my own homebrew rendering technology (which basically is just
leveraging DOM and xhtml) and found that struts didnt get in the way and
indeed meshed nicely in many cases.

What I saw in the good 2 minutes or so I looked at WW just now that _did_
get me excited was the idea of it making it much easier to seperate classes
from dependancies on the servlet api thus becoming easier to test. One can
always test struts with things like StrutsTestCase or cactus doing mock
object or in container tests, but learning how is a daunting task, which Id
imagine has put off many people from trying. (I know Ive never bothered to
work out how to do it - but hey, my codes so good it doesnt need testing
right? ;->) If it could easily test my stuff in good old Junit using j2se...
that would be sweet mate...


<snip>
The mapping from HTTP Request to Actions is really cohesive. You have a
form with fields, you have an action with corresponding fields.
</snip>

Yes - theres a lot to be said for the idea of merging the actionform and the
action and instantiating a new instance for each request (or reusing one
from the session). Ive never fully grokked why struts was so keen to use the
singleton pattern for actions. Tis true that servlets do this - and actions
resemble servlets (after all they are in the end just the bit of the
ActionServlet that does the specific work!) , but I and others have oft
debated the merits of relaxing the threadsafety rule on actions and
instantiating new ones each time - and merging the actionform into the same
object so that you have a sort of 'component' perhaps follows on from this?

hmmm... Can anyone think of some good reasons not to make Action an
interface?


-----Original Message-----
From: Butt, Dudley [mailto:dbutt@metropolitan.co.za]
Sent: Wednesday, 16 July 2003 17:08
To: struts-user@jakarta.apache.org
Subject: what the webwork guys say about struts


BEOW IS AS IS, PASTED FROM WW forum:
=====================================

Check out the docs on the Wiki (http://wiki.opensymphony.com),
especially

http://wiki.opensymphony.com/space/Migrating+from+Struts+1.0+to+WebWork+
2 - migrating from Struts to WebWork2

And the article I just posted:

http://wiki.opensymphony.com/space/Writeup+of+Mike%27s+Talk+at+TSS+on+We
bWork2 which is a general overview of WebWork2.

For your specific questions, WebWork is better than Struts because it is
a simpler framework, with less ties to the web and in genral less
useless contracts for your code to implement. Being less coupled makes
things easier to test, which is always better. With WebWork2, we've
added some very powerful features. Check the docs I listed for the
overview.

For the view, you can use Velocity as well as JSP, FreeMarker,
JasperReports, and XML/XSLT. Velocity and JSP are the most common, and
the best supported, but all are first class citizens in WW, unlike Stuts
where anything but JSP is difficult.


================================================================

I use Webwork in my 'Enterprise Java' clases, largely because it is
incredibly simple. One reason for this is it let's us deal JSP as a
single presentation tier, which reduces the learning curve (and you can
always move to something else at a later stage).

The mapping from HTTP Request to Actions is really cohesive. You have a
form with fields, you have an action with corresponding fields. Data
gets populated and the Action is executed.

It really is that simple to get started.

Testing is really nice, you can run all your Actions through JUnit
without being tied to the Web Container. This speeds development time as
you don't need to package and deploy every time you make a change and it
makes debugging much simpler.

And WW2 rocks.

===========================================================================





NOTICE:

This message contains privileged and confidential information intended
only for the person or entity to which it is addressed.
Any review, retransmission, dissemination, copy or other use of, or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient, is prohibited.

If you received this message in error, please notify the sender
immediately by e-mail, facsimile or telephone and thereafter delete the
material from any computer.

The New Africa Capital Group, its subsidiaries or associates do not
accept liability for any personal views expressed in this message.

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message