Interesting...I can see you have put a lot of time and thought into
this. My first pass seems to find this a cross between the portlet api
and JSF. What I saw missing from the articles and wiki pages is a
higher level justification:
- Why not just use portlets?
- Why not just use JSF?
- Why should Struts the project include another non-standard component
framework?
It seems to me that the web framework space is moving 1) towards
standardization and 2) away from JSP-specific solutions and really JSP
altogether. I'm curious as to what specific value(s) you feel this
component framework brings to Struts that goes against those directions.
Don
Michael Jouravlev wrote:
As most of you probably know, I have been quite obsessed with page
components developed with JSP or with JSP/Struts [1],[2]. My first
attempt used Struts/JSP, the second one is pure JSP-based [3]. It
proved to be quite robust, simple and it works. So now in my newly
acquired powers of Struts committer I want to build this technology
into Struts 1.x.
The code is not GA quality yet, but major stuff works. Nice thing is
that the same code/markup works in both non-Javascript and
Javascript-enabled browsers. With Javascript, simple Ajax is used to
replace component markup in a composite page (make it AHAH since it
returns XHTML, not XML). Without Javascript good old
redirect-after-post is used, the reload target is calculated
automatically.
I believe that this is a really nice feature. And it is extensible.
Compare it to, say, ICEFaces. I was experimenting and I implmented
many of these features like Ajax tab component or partial submit. This
technology will put the end to "Struts has no components" claim. I do
not suggest this for SAF2 since it already has Ajax and component
features.
You can read more in Wiki pages, that I envision as peice of future
documentation [4]
I will be able to finish coding myself so I do not need much help on
this part. What I do need is approval for:
* enhancing Struts 1.x with this technology
* enhanching Action class with dispatching functionality
So while I will be polishing the code, I want these ideas to get
marinated for a while. I already raised the question about sticking
dispatching stuff into Action [5], [6]. The replies were:
Don -- OK
Frank -- OK, if all current functionality is retained
Dave N -- OK, if execute() will be made default dispatch method
Niall - Nah... (but not Noooo! so I hope to convince him)
I would like to explain my position once again, largely for Niall and
maybe for others too.
* After series of experiments with oh so many flavors of dispatch
actions we now have the best of the breed: EventDispathAction. It
covers all the bases, it is highly unlikely that another dispatch
action will be created for Struts 1.x. I want to implement
EventDispathAction in base Action.
* No one will be hurt: it will be possible to use Action just as an
ordinary old-school Action. Older dispatch actions will work as well.
* Having dispatching functionality at the core allows to promote the
concept of a web resource or a web business object. Programming with
Struts is still more like procedural, comparing to OO. I argue that
for an interactive app OO paradigm is easier to use, like Customer
object and methods on it. But again, nothing prevents from standard
usage of Action.
* The code will be simpler and cleaner, no need to instantiate dispatchers.
* Big thing: it will be possible to make event definition in action
mapping first-class elements.
* I can think of more if needed ;-)
Why this is needed? Because my concept of a web component stems from a
concept of a stateful web resource that is controlled by a dispatch
action [7].
The proposed markup in struts-config.xml will look something like this:
<action component = "Login"
view = "/login/loginComponent.jsp"
path = "/login"
type = "samples.login.LoginAction"
form = "loginform"
scope = "session"
validate = "false">
<event name="loginEvent" handler="login"/>
<event name="logoutEvent" handler="logout"/>
</action>
Here event definitions are first-class elements of action mapping.
Those of you who object this approach, consider how ASP.NET works.
Yes, it is page-based, but the code-behind class has event handlers
for all UI controls on a page. Very, very similar. Struts can do the
same, but even better, because we can render different views from one
event dispatcher.
* "component" attribute contains the name of a component. It
identifies an action as a component manager. Such actions are handled
differently than a regular action or a simple dispatch action.
* "view" attribute identifies a default view. May consist of several
subviews.
* "form" is just another name for "name" property, I wanted to make
this change for a long time ;)
* "event" property allows to define incoming events and corresponding
method handlers. An event is just a request parameter.
If action mapping does not define "component" and "event" elements, it
is processed as a regular Action. If "event" elements are defined,
action is process in the same manner as EventDispatchAction does. If
"component" is defined, the action does some additional
component-related processing. I think this is quite simple, and no
current functionality will be affected.
References:
[1] http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html
[2] http://today.java.net/pub/a/today/2006/05/04/almost-portlets.html
[3] http://www.jspcontrols.net/
[4] http://wiki.apache.org/struts/StrutsManualActionWebComponent
[5] http://marc.theaimsgroup.com/?l=struts-user&m=114676523831110&w=2
[6] http://marc.theaimsgroup.com/?l=struts-dev&m=114723101619599&w=2
[7] http://wiki.apache.org/struts/StrutsManualActionClasses
---------------------------------------------------------------------
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]
