Paul, thanks for the warm support, I really appreciate it! Well, I
cannot thank you more, my ears are all red :-)
In any case, I think we can wait until 1.3.5 goes GA before making a
final decision about where this code belongs. In the meantime I will
continue working on it.
Integrating html2 would be nice too. It uses Ajax as well, so the two
engines can be combined into one.
In relation to html2, I am curious about how important client-side
validator is. I mean, comparing Ajax roundrip to amount of Javascript
preloaded for client-side validation, does it really make sense? And
if a form is filled out correctly, this validator code is not used at
all.
So, maybe switching to Ajax validation instead of client-side
validation makes sense? Centralizing all features (and bugs) in one
place. Like client-side validator does not handle European dates.
Michael.
On 6/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
I am +1 for Michael's idea.
I empathize with anyone who believe it's a non-standard way of doing portlets,
or that the idea is better as an independent plug-in, but consider that Struts
does not have to be the bare-of-the-bare of frameworks. Struts 1.x is
definitely legacy and has provided a consistent interface for programming, but
let's not confuse legacy support with being too old to learn new tricks :-)
What I find very promising in Michael's design is that he is helping promote a
good practice. I have followed his articles and successfully implemented what
he is recommending -- and I do believe this would make a great addition to have
these best practices built into Struts. And since the proposal is nothing but
an endorsed methodology, it [1] does not lock me into using it and [2] I don't
have to use it. Those are a hallmark of a great framework: give me the generic
cases, but don't dictate the corner cases.
I also am +1 for embedding an action dispatcher straight into the Action. The
base class can default to EventActionDispatcher, and must be overridden. If no
execute() is provided, the dispatching is the default; otherwise you can
program normal actions, as before. My addition here is that I should be able to
pass in a dispatcher to the super class in the constructor, because, I DO use a
customized version of EventActionDispatcher in my classes -- so I'd like the
ability to customize what dispatching is used.
The timing of Michael's suggestions is opportune for me. My "page"
attribute/property idea is to facilitate something comparable. These things would be a
worthy 1.4.0 release.
Paul
Michael Jouravlev <[EMAIL PROTECTED]> 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:
view = "/login/loginComponent.jsp"
path = "/login"
type = "samples.login.LoginAction"
form = "loginform"
scope = "session"
validate = "false">
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]
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2�/min or less.
---------------------------------
Want to be your own boss? Learn how on Yahoo! Small Business.
