On 8/2/05, Don Brown <[EMAIL PROTECTED]> wrote: > Struts Ti is a simplified Model 2 framework for developing webapps which > allows the developer better access to the underlying servlet/portlet > environment.
This is I agree with. > It serves a niche of web applications that don't want the > additional complexity of server-side components and verbose > configuration, yet want the structure and controller features of a > modern web framework. This I don't get. > Key Features > > * 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 > * Pluggable EL for data binding defaulting to JSP 2.0 EL but > allowing OGNL or even BeanUtils Nice > * 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. > 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". > 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. > * 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]
