These are some great questions, and particularly relevant to me as I'm
working on the 2ed edition of Struts in Action. You can be sure our
book will cover, at least in part, Struts Ti. Here is my 2c:
Pilgrim, Peter wrote:
Hi
1) Is the WebWork name going to exist still?
No, at least not in Apache Struts. The WebWork project will probably
stick around supporting 1.x and possibly to host migration code.
2) Is the Struts name going to be annexed with WebWork?
Nope. While initially, this WebWork import will be called Struts Ti, it
is my hope it will quickly be accepted as Struts Action 2.0.
3) A users has invested his or her hard-earned cash in `WebWork' in Action book.
Will contents of this tome still be relevant in Struts?
Absolutely, since Struts Ti == WebWork 2.2, with some package name changes.
4) In fact there are a number of such books on the markets e.g Struts Receipes
and Struts Cookbook. Are these book becoming irrevelant or still revelant?
Have the book publishers lost a dosh of cash, then ?
These books will continue to be important due to:
1. All the existing Struts Action 1.x applications out there
2. The Struts Action 1.x will continue to be supported and developed
Just because there might be a Struts Action 2.0, doesn't mean
development or support will stop on 1.x. WebWork itself is a good
example of this as their 1.x community is still quite alive.
5) What architectural components are going to be replaced in Struts ?
( And conversely in Webwork?)
This is a tough question because we haven't started on the Struts
compatibility layer so I can't tell you what we can support from Struts.
WebWork will be imported as is, so I don't see anything replaced there
initially, however, we might decide to remove some deprecations.
I can tell you it is my personal goal for the Struts compatibility layer
to support to some extent Struts Actions, ActionForms, Validator, and
Tiles at least.
6) What happens to the custom tag libraries like HTML or HTML-EL?
These, of course, will still be supported by Struts 1.x. We might find
it possible to simulate them with the Struts compatibility layer, I
don't know yet. Still, I think you'll really like the WebWork tags
since they support multiple template technologies (JSP, Velocity,
FreeMarker, etc) and have "themes" which include an Ajax theme that uses
Dojo.
7) Will Struts users suddenly now have to learn OGNL thing?
Struts 1.x users, of course, won't, and while initially Struts Ti users
will, one of our goals in Struts Ti has been to make that pluggable so
you could stick JSP EL there or even XPath.
8) How will the Webwork Integration affect popular Struts extensions such as
the Validator or Tiles?
Again, it is my goal the compatibility layer or even Struts Ti itself
will support them. To be honest, I'm not to keen on making Validator
support core, because I personally think there are better ways to do
validation, but Tiles will be important to support. There is a version
of Tiles that is being worked on which doesn't require Struts at all, so
it is possible it could be easily used with Struts Ti.
9) A Girl named Geraldine (or A Guy named Gerald if you are so inclined) has invested in
heavily Spring supported Struts Actions, and has read your recent announcement and
she proclaims "What Do I Do Now?!"
Keep on keeping on. I too have a Struts Action 1.x application that
uses Spring-supported Actions and plan to be supporting it for a while.
Struts Ti, if she was interested in it for new apps, will contain
heavy Spring integration which might be a better choice.
( Spring support AOP already, so does it fit with the WebWork interceptors? )
Two different things, really, so yes, they compliment each other well.
10) "What does WebWork really bring to the Struts party? "
"What is the different between that and this new Struts Ti that I have been hearing
about?"
WebWork, from a developer and user point of view, is a great framework
that is well designed, and basically most things I wish Struts was.
Struts Ti started as a annotation-driven Ruby on Rails-type framework
which was built on WebWork, however, we are moving some of those
advanced features back to "phase 2" and making phase 1 the WebWork
import with Struts compatibility tools.
11) What will be the typically code that the application developer writes for
Struts 2.x?
Will it be Struts Action, Chains of Commands, or Interceptor?
WebWork too has Actions, however, they view Actions as Struts Actions +
ActionForms, which I might add, Craig himself sees as a better way to go
as reflected in JSF. Furthermore, Actions are request-scoped, so no
more worrying about thread safety. We hope to add commons-chain
integration at least at the global level, however, I'm sure Ted will
spur integration at the Action level as well :)
12) When do you expect Struts 2.x to "go live"?
When it's ready of course. :) The WebWork guys want to finish WebWork
2.2, then they will set on the course of migration. There are a few
incubator steps the Apache Software Foundation requires to be completed
before we can import the code. From there, we will develop the Struts
compatibility layer, and hopefully see a quick release. After that, we
start rolling in some of the original Struts Ti features like zero
configuration (using annotations), quick development mode, and possibly
some sort of workflow framework (Beehive, Spring Web Flow, Rife, etc).
Don
References:
http://www.theserverside.com/news/thread.tss?thread_id=37794
http://blogs.opensymphony.com/webwork/
http://www.manning.com/books/lightbody
--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
---------------------------------------------------------------------
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]
