Michael Jouravlev wrote:
<snip />
* POJO-based action that combines an Action and ActionForm in a
similar manner to JSF backing beans and WebWork 2 Commands
I am all in for this, but preserving compatibility with current
Action/ActionForm
Struts Ti and particularly its underlying workhorse XWork, allows you to implement Actions however you'd like. The
default implementation will be a JSF/Ruby on Rails style POJO controller with annotations. We will provide a Struts
compatibility layer which will support regular Struts actions and forms.
* Integration of a dialog or page flow capability drawing from
Beehive, Spring's web flow, and Shale's Dialogs.
How about Struts Dialogs? They are fully compatible with current
codebase and provide dialog and wizard support. Beehive seem to be too
heavy for me.
The Beehive folks are re-implementing their Page Flow on top of Struts Ti and XWork. They bring experience with
toolability and Java 5 annotations which I personally don't have. My main complaint of Beehive is their verbose
annotations, however, they are working on that and for those that like it as simple as possible, Ti supports
XDoclet-style annotations simultaneously.
Design Goals
* No servlet dependency in core framework,
I don't like that. This is a *web* framework, I want to have easy
access to plumbing. I can see how WebWork guys are tired of answering
questions "how I can get my request".
As I said, Ti will have a Struts classic compatibility layer which will let you use Actions and ActionForms, if you are
more comfortable with them.
portlet and JSF support
out of the box
Does not Shale support JSF out of the box? What is the point for Ti
then? I would say, than new Struts version should work with current
technologies like JSP and not force using new markup.
If you are happy with JSF and/or Shale, feel free to use it. Struts Ti is aiming for a simple, clean framework that
requires no configuration, is Action-first rather than Page-first, can run in multiple environments, and use any
presentation technology, JSF and JSP included.
Regarding flow, have a closer look at Beehive. Their page flow is intuitive and tested, not to mention toolable. In
fact, they just had their first open source release and I believe are now a top level Apache project.
Don
* No bias to any view technology
Well, using scope objects like request or session, every Java
framework is biased towards JSP. Is it not true?
Couple of words about flow. I think about flow for the third year, I
had several iterations, and now I came to thinking that flow is not
needed. I mean, the global application flow is not needed. It only
ties up actions/pages to each other, and is hard to maintain.
What I think of istead of flow, is "web islands", autonomous actions
which can have built-in mini-flow in them if needed. That is, one
action has set of states and can render different pages according to
state.
Moving from action to action, from web island to web island should be
flow-less. Either an action accept input in its current state, or is
not. Either it can render itself in its state, or its not. How does a
user get to this action, should not be hardcoded.
Why would not you take a look at the simple wizard that can be created
using current Struts codebase:
http://struts.sourceforge.net/strutsdialogs/wizardaction.html There is
a live demo available which you can try.
I want to donate my project to Struts and I am open to suggestions.
I rewrote MailReader using Struts Dialogs, I wanted to clean it up and
to write decent docs, but I guess no time for that, so I will upload
it to my demo server in couple of days.
Michael.
---
Struts Dialogs: build components, controls and wizards easier.
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
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]
