You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <st...@reumann.net> on 2006/01/04 22:02:46 UTC
The framework I think I want...
Since I've been working on a rich client .NET app for a while, I've been
a bit out of the loop on all the latest 'goings on' in regard to
frameworks. (I couldn't keep up with all the Struts/JSF/Shale/WebWork
comments on the list a while a back.)
I'm actually quite happy with what Struts has to offer except for the
deal with having to use ActionForms. I'd really like a Struts-like
framework but allows me to use POJOs to capture my data and provides a
nice way to redisplay that data back to the user if validation fails (ie
a POJO that backs a form with a Data datatype will display back the
String they entered). The managed bean approach to JSF that I've used
some was REALLY nice - but I'm not yet convinced I want everything else
in regard to JSF at this time.
Will the collaborative effort between Struts and WebWork possibly be
exactly what I'm looking for? I looked at WebWork a long time ago and it
looked like it took a managed bean approach type of an approach and no
need for ActionForms (but I never really used it, so I could be way off.)
--
Rick Reumann
http://www.tech.reumann.net - Struts lessons, articles, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Mark Lowe <me...@gmail.com>.
On 1/6/06, Tamas Szabo <sz...@gmail.com> wrote:
> On 1/6/06, Michael Jouravlev <jm...@gmail.com> wrote:
> >
> > On 1/5/06, Tamas Szabo <sz...@gmail.com> wrote:
> > > >
> > > > I'm actually quite happy with what Struts has to offer except for the
> > > > deal with having to use ActionForms. I'd really like a Struts-like
> > > > framework but allows me to use POJOs to capture my data and provides a
> > > > nice way to redisplay that data back to the user if validation fails
> > (ie
> > > > a POJO that backs a form with a Data datatype will display back the
> > > > String they entered).
> > >
> > >
> > > You can bind request parameters to POJOs using Spring.
> > > And you can use the SpringBindingActionForm to redisplay the data to the
> > > user.
> >
> > From
> > http://www.springframework.org/docs/api/org/springframework/web/struts/SpringBindingActionForm.html
> > "Note this ActionForm is designed explicitly for use in request scope."
> >
> > Will not work for me.
>
>
> Not out of the box. But you can extend it.
> We extended it, and use the subclass one in session scope.
>
> The other interesting thing is that you can't use <c:out ...> on properties
> exposed via a SpringBindingActionForm. That's probably because
> JSTL tags don't get properties using Commons Beanutils ...
>
> But if we are at the subject of binding request params to business layer
> objects...
> Probably a lot of people bind req params directly without using ActionForms
> just
> to avoid writitng all the ActionForms. How do you assure
> that only the allowed properties will be set in the object?
>
> Ex. we have a bean with prop1, prop2.
> Only prop1 is allowed to be changed, but no one can prevent someone sending
> a request having a prop2 parameter in it. If you bind the request params to
> objects directly
> prop2 will be set to the value set by the "misbehaving" user.
> I know a few solutions to this, but in all of them you will have to
> explicitly specify all the
> properties that are allowed to be set.
> And if you do this then it's the same as declaring these properties as a
> DynaActionForm
> or to give it to a tool that generates an ActionForm ahving all these
> properties.
> So why is it better to bind request params to business layer objects
> directly without using
> ActionForms?
>
> Tamas
>
>
Some folk will claim that writing action forms its too much hassle.
Some solutions to this problem (if you percieve it as such) include
generating action forms from business objects as is the case with
xdoclet.
JSF's backing beans are really slick at all this stuff (converting
user input values to relevent types and validating before population
etc), but the other burdens of JSF make it a hard technology to choose
in production projects. Lets hope that JSF starts moving along faster
than it has been.
Its not good to bind request params to business objects if not
mediated (converted and validated). After all request parameters are
strings, something needs to be between the request and business tier.
What that is or how you do it is debatable.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Rick Reumann <st...@reumann.net>.
Dave Newton wrote the following on 1/6/2006 9:35 AM:
>
> Doesn't it just need validation info rather than model knowledge (you
> listed validation constraints/msgs in your original list, which is why I
> can't figure out why it needs any more info).
Not necessarily related to the model per-se but I see what Ted is saying
about other areas and to me it is the most 'grey' area in regard to web
apps - that is the 'other stuff' such as "How do I want my JSP form to
know whether it should display certain things as an Edit form or an
Insert form." If I have a JSP that has all my form inputs and set up
looking exactly how I want, but if it's being used as insert page I want
the title on the page to be different than if I'm doing an edit. Same
thing with the buttons. Possibly I might want the button to say "Update"
if I'm doing an edit and "Insert" if doing an insert. This came up in
another post a while back, and there is no real clear-cut best practice.
I'm guessing Ted refers to this as the "data entry hint" in his first
list I posted.
Then there are such things as maybe the user of the form is a "Special
User" and thus we need to show a special text box for the user to enter
the "Gold club membership number." Then you need some logic to decide if
the user is a gold member some processing needs to be totally different
of the form data... so do you:
a) Change where the form submits. In the Struts world a different
dispatch or Action, which involves logic in the JSP to decide how to
declare the <html:form> tag or
b) submit to the same action or dispatch method and then branch from there.
Obviously, I think choice b makes the most sense but in other cases it's
not always so clear.
In complex applications, things often become very blurry.
As a side note, at the moment, this is why I'm comfortable with JSTL on
the front end. When I was using MyFaces what I could do on the front end
with complex situations seem to be predicated on what the renderer could
give me - such as the DataTable (I think that was the name). Possibly
it's just my particular use cases I've run into... but often times my
front end had to be tweaked in different ways. "if this type of user" -
display extra text boxes here. "if this other user"- hide this div but
create another div with this stuff in it. Of course sometimes if the
views become too complex different views need to be broken out into
separate JSPs or possibly include files etc. The point is, though, that
I seem to have a lot of control. I felt I was missing some of this
front-end control when I was working with JSF - my markup seemed bound
to what rendering components I used - versus me having the complete
flexibility with JSTL to create the front end stuff in ways I was used to.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 2:01 pm, Michael Jouravlev said:
> The above was not meant to be an attack on you (do you have
> suggest-type thing?) ;-)) Google has also bandwidth and number of
> connections to spare ;-)
Oh, I know, I was just pointing it out because many people don't realize
they do that, and it's kinda cool. Your right of course, they can spare
some bandwidth for keypresses :)
> ...and the larger the Javascript file gets. If validation still has to
> be done on server, how do you compare (1) one-time (hopefully) load of
> a large Javascript validation file for client-based validation, with
> (2) going back to the server and updating a relatively small page
> region without full page reload? [ I have my Ajax now too, :-) ] The
> latter is simpler for me. Is it better? It is not much worse than
> former I would say, but a lot simpler, and I do not have to duplicate
> Java validation in Javascript.
That's a fair point. Assuming it is a one-time load though, just the
simple fact that there are less requests being made with client-side
validation I think is a clear benefit. Well, PRESUMABLY less requests
anyway... the more you can catch without hitting the server, the less
requests. It *is* simpler when only the server is involved though, no
question there. Just the fact that you don't have to have duplicate code
(whether you write it yourself or have some taglib or something generate
it) is a clear advantage.
>> If you combine an ActionForm with an Action, what happens if you want to
>> give that combined object session scope? Would you then store the
>> entire
>> thing in session? I would assume so. That seems like a (potentially)
>> big
>> waste of resources.
>
> Why? The code and class definition are loaded only once. Where the
> resources are wasted?
Well, if I have a couple of pages that I want to store in session, and it
is a combined object, my session is bigger than if the objects I'm storing
are just data. That's what I was referring to. There is still physical
memory being used to store the instance of the Action class in session.
I'm a stickler about the size of session because I work in a distributed
environment where session size is something you need to be very cognizant
of.
> I am pretty happy with ActionForm in session ;)
I know :) And I'm a big believer in "whatever works for you", so I'm
happy either way.
>> If an ActionForm is thought of
>> ONLY as a buffer as you say, a DTO between presentation and control
>> basically, Struts seems a lot cleaner all of a sudden.
>
> Um, a lot cleaner (1) if it contains only request parameters
> per-request as it is bieing recommended to be used now, or (2) if it
> contains I/O data between requests during conversation with a user,
> including wrong input values and error messages?
Good question... I'd say #1, but I treat it as an I/O buffer in the sense
that yes, it takes in request parameters per-request, but it also is the
container where output data goes to be rendered by the presentation layer,
and that would include error messages. It would NOT include state between
related requests though (i.e., a wizard flow). #2 is where that
"something else" I mentioned comes in. And again, I'm talking
generalities here... there are obviously places where session-scoped
ActionForms make sense right now.
And of course I have to reiterate that I don't have at the moment a better
answer, we're just discussing what the problems with the current framework
might be, expressed in terms of what we'd like to see, as per the original
topic of the thread :)
> The main drawback of session-scoped ActionForm is that I can have only
> one of each kind. Does not work well with several windows opened.
> Couple of years ago I was doing a little different, i had a list of
> session-scoped presentation objects that contained I/O values and
> errors. So I could have one action form and several session-scoped I/O
> objects related to it. But then I decided to abandon this, too complex
> to manage and users don't usually open secondary windows themselves.
That's along the lines of what I am describing above. Maybe what there
needs to be is a single I/O buffer object and some peripheral objects
attached to the same view for "other things", which sonuds about like what
your saying you played with :)
> Michael.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> On Fri, January 6, 2006 1:01 pm, Michael Jouravlev said:
> > Rrright. You want to save on network bandwidth by validating in
> > browser. At the same time we have Ajax "suggest"-type junk growing in
> > popularity, where server is pulled each time a user hits a button.
>
> Well, not *each* time a key is pressed... look at the code for Google
> Suggests and you will see they do a really cool thing where they throttle
> the number of requests based on how fast you are typing. It's not a 1:1
> call per keypress unless you are typing really slow.
>
> (My own AjaxTags example doesn't do this, but hey, Google has Ph.D's to
> spare whereas I don't have even one!)
The above was not meant to be an attack on you (do you have
suggest-type thing?) ;-)) Google has also bandwidth and number of
connections to spare ;-)
> > Nah. Imho, client-side validation should be minimal. Empty/non-emty,
> > proper length. Maybe some simple data conversion check like is it a
> > number or a valid email. Yes, it is not DRY and redundant because the
> > final validation is done on the server anyway, but user's Athlon 64
> > needs some code to chew. Everything more complex than above, including
> > custom error messages, inter-field dependencies, etc is checked on
> > server. It will be checked on server anyway, because user's browser is
> > in the open, whoever can change the validation rules or turn them off
> > or turn Javascript off.
>
> Best practices have dictated for a long time that any validation that
> occurs on the client should also occur on the server. But, the more you
> can pull off on the client, the more responsive and user-friendly your
> application will usually be.
...and the larger the Javascript file gets. If validation still has to
be done on server, how do you compare (1) one-time (hopefully) load of
a large Javascript validation file for client-based validation, with
(2) going back to the server and updating a relatively small page
region without full page reload? [ I have my Ajax now too, :-) ] The
latter is simpler for me. Is it better? It is not much worse than
former I would say, but a lot simpler, and I do not have to duplicate
Java validation in Javascript.
> If you combine an ActionForm with an Action, what happens if you want to
> give that combined object session scope? Would you then store the entire
> thing in session? I would assume so. That seems like a (potentially) big
> waste of resources.
Why? The code and class definition are loaded only once. Where the
resources are wasted?
> > Advertising ActionForm as a request parameter holder in Struts best
> > practices is a mistake imho. It can be used as an input/output buffer,
> > as this kind of layer that you talk about. Apparently, it should have
> > session scope ;) and implement Serializable.
>
> I would make the argument that session-scope for an ActionForm is the
> abomination. There should be something else, and I'm not sure I know
> what, that gets stashed in session scope.
I am pretty happy with ActionForm in session ;)
> If an ActionForm is thought of
> ONLY as a buffer as you say, a DTO between presentation and control
> basically, Struts seems a lot cleaner all of a sudden.
Um, a lot cleaner (1) if it contains only request parameters
per-request as it is bieing recommended to be used now, or (2) if it
contains I/O data between requests during conversation with a user,
including wrong input values and error messages?
> Of course, that
> then leaves a lot of questions about how you persist user entries and
> such, and I admit I don't have a good answer there.
The main drawback of session-scoped ActionForm is that I can have only
one of each kind. Does not work well with several windows opened.
Couple of years ago I was doing a little different, i had a list of
session-scoped presentation objects that contained I/O values and
errors. So I could have one action form and several session-scoped I/O
objects related to it. But then I decided to abandon this, too complex
to manage and users don't usually open secondary windows themselves.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dakota Jack <da...@gmail.com>.
Well, however, isn't it true that the common variety was created for this.
This reminds me of the librarian who said she could not remain open an extra
five minutes for me because of the rules. Upon examination, she authored
and enforced the rules.
On 1/6/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 1/6/06, Hubert Rabago <hr...@gmail.com> wrote:
> >
> > On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > > ...all of which raises a question that I don't know the answer to...
> > does
> > > Struts 1.3 pool Commands? I.e., if I implement my Actions as
> Commands,
> > do
> > > I get that per-request functionality I want? If so, that is at least
> a
> > > step in a good direction.
> >
> > IIRC, Craig implements Commands the way he did Actions, so there's one
> > instance of it for the whole app (per jvm, etc, you know what i mean).
>
>
> That's what the default Commons Chain imlementation does, so that's what
> the
> current 1.3 code does ... if you don't want that, use a different
> implementation of org.apache.commons.chain.Chain :-).
>
> On the other hand, if you're using the CoR design pattern, all your state
> information should be in the Context object that gets passed around, not
> in
> instance variables in a Command instance. Therefore, you shouldn't *want*
> to have multiple instances of the command classes. Put the per-request
> state information in the context (or approprately organized in a session
> scope attribute) where it belongs.
>
> Craig
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: The framework I think I want...
Posted by Dakota Jack <da...@gmail.com>.
LOL Okay, Big Fella, stand at ease. If what you said does not suggest what
I said, then you are safe as barrel water.
Let me state it for myself. It is clearly POOR and has been for a long
time. If people are too danged sensitive to accept that, sobeit. Yesterday
is gone. I am not writing history but am writing and designing code. To
heck with the ego parade.
<snip>
On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>
>
> > This has been, in my opinion, the biggest downfall of Struts. As you
> > suggested, Frank, the whole way the view state is taken care of by
> Struts
> > is
> > poor.
>
> Woah, hold on now, don't put words in my mouth :) I wouldn't go so far as
> to say it's poor because many people have had a great deal of success with
> it. I *do* think there are some shortcomings that may or may not have
> some relatively simple solutions, and I don't think too many people would
> disagree. No one thinks Struts is perfect, but based on how many people
> use it and use it successfully, it's probably not fair to say it's poor,
> or that any one part of it is poor.
>
> Frank
</snip>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: The framework I think I want...
Posted by Simon Chappell <si...@gmail.com>.
On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
*snip*
> I'm not able to use 1.3 yet based on some politics here, so I've had to
> stick with 1.2.7.
Luxury! I'm still out here "allowed" to use 1.1. So, you folks just
feel free to change anything you like, it isn't going to make *any*
difference to me.
That said, 1.1 still works and solves enough of my problems that I
praise it far more than I curse it, the struts-config.xml file
excepted, of course.
Simon
--
www.simonpeter.com
uab.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 4:01 pm, Craig McClanahan said:
> Or, the per-request POJO *is* the context object (which already has
> per-request lifetime). Why have two beans instead of one?
I agree, and that is in effect what I've been doing...
I'm not able to use 1.3 yet based on some politics here, so I've had to
stick with 1.2.7. So, what I've done on a recent project is I used my own
CoR implementation from Java Web Parts (it has some extra capabilities I
needed). What I wound up doing is I have a single Action that all my
mappings point to. This Action looks at the path that was requested and
fires off the appropriate chain (which may be one Command, or multiple, or
a number of subchains, whatever). I don't use ActionForms at all, but
that one Action auto-populates the context from request, and I can turn
that off per-request, dealing with conversions and such (but not
validation, that is usually done by the first Command in the Chain). When
its all done it stuffs the context into request so that the JSPs can
render off it using my own custom tags.
I also get dependency injection via the DependencyFilter in JWP, and for
the most part this has been useful for dealing with session-scoped data...
I keep session data to a minimum, but what does get put there is retrieved
by the filter and put in request for the Action to add to ChainContext
(most of the time it amounts to having stored a ChainContext in session,
then taking that version and copying it over into the new version that the
chain uses for the current request). The end result is that Commands
themselves are extremely small and clean.
While I wouldn't call it ideal, it has all worked out rather well and gets
me most of what I'd want.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, Hubert Rabago <hr...@gmail.com> wrote:
>
> On 1/6/06, Craig McClanahan <cr...@apache.org> wrote:
> > > IIRC, Craig implements Commands the way he did Actions, so there's one
> > > instance of it for the whole app (per jvm, etc, you know what i mean).
> >
> >
> > That's what the default Commons Chain imlementation does, so that's what
> the
> > current 1.3 code does ... if you don't want that, use a different
> > implementation of org.apache.commons.chain.Chain :-).
> >
> > On the other hand, if you're using the CoR design pattern, all your
> state
> > information should be in the Context object that gets passed around, not
> in
> > instance variables in a Command instance. Therefore, you shouldn't
> *want*
> > to have multiple instances of the command classes. Put the per-request
> > state information in the context (or approprately organized in a session
> > scope attribute) where it belongs.
> >
> > Craig
>
> So, Frank, maybe what you want is a per-request POJO action object
> that gets populated by the framework with request parameters, stuffs
> the relevant data onto a context object, and triggers a chain to
> fulfill the request.
Or, the per-request POJO *is* the context object (which already has
per-request lifetime). Why have two beans instead of one?
Hubert
Craig
Re: The framework I think I want...
Posted by Hubert Rabago <hr...@gmail.com>.
On 1/6/06, Craig McClanahan <cr...@apache.org> wrote:
> > IIRC, Craig implements Commands the way he did Actions, so there's one
> > instance of it for the whole app (per jvm, etc, you know what i mean).
>
>
> That's what the default Commons Chain imlementation does, so that's what the
> current 1.3 code does ... if you don't want that, use a different
> implementation of org.apache.commons.chain.Chain :-).
>
> On the other hand, if you're using the CoR design pattern, all your state
> information should be in the Context object that gets passed around, not in
> instance variables in a Command instance. Therefore, you shouldn't *want*
> to have multiple instances of the command classes. Put the per-request
> state information in the context (or approprately organized in a session
> scope attribute) where it belongs.
>
> Craig
So, Frank, maybe what you want is a per-request POJO action object
that gets populated by the framework with request parameters, stuffs
the relevant data onto a context object, and triggers a chain to
fulfill the request.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, Hubert Rabago <hr...@gmail.com> wrote:
>
> On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > ...all of which raises a question that I don't know the answer to...
> does
> > Struts 1.3 pool Commands? I.e., if I implement my Actions as Commands,
> do
> > I get that per-request functionality I want? If so, that is at least a
> > step in a good direction.
>
> IIRC, Craig implements Commands the way he did Actions, so there's one
> instance of it for the whole app (per jvm, etc, you know what i mean).
That's what the default Commons Chain imlementation does, so that's what the
current 1.3 code does ... if you don't want that, use a different
implementation of org.apache.commons.chain.Chain :-).
On the other hand, if you're using the CoR design pattern, all your state
information should be in the Context object that gets passed around, not in
instance variables in a Command instance. Therefore, you shouldn't *want*
to have multiple instances of the command classes. Put the per-request
state information in the context (or approprately organized in a session
scope attribute) where it belongs.
Craig
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 3:36 pm, Hubert Rabago said:
> IIRC, Craig implements Commands the way he did Actions, so there's one
> instance of it for the whole app (per jvm, etc, you know what i mean).
That would be a shame. Craig, can you confirm this? If that is the case,
I'd be interested in knowing the rationale because I know the rationale
for the decision originally with Actions, but as we've discussed a couple
of times, the rationale doesn't really carry forward to the present. Is
there another reason?
(Quick, switch 1.3 to use the Chain implementation in Java Web Parts... it
doesn't "suffer" that "problem" ;) )
> *Poor* is relative. Struts might've been the bleeding edge of tech
> years ago, but it's got a lot of catching up to do now. Not that it
> can't, but instead of slowly catching up, we'll quickly catch up
> instead by merging with WW.
As a plan, that sounds good :) It will be interesting to see how it turns
out.
> Hubert
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Hubert Rabago <hr...@gmail.com>.
On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> The interesting thing is, there are some relatively minor tweaks that
> could be done to Struts that would solve a lot of problems. How about
> creating Actions per-request? Not at all a significant enhancement, but
> think of all the things you could then do. How about a simple flag to
> tell the RP to populate the Action rather than an ActionForm, thereby
> giving Michael his dream of a combined Action and ActionForm? Again,
> we're not talking about a big change. These are also not new ideas by any
> stretch, I, and you, and Michael and others have been tossing these things
> around for at least a year or more.
You're right in that these are not new ideas. I think crazybob
implemented something like this a few years ago. I tried it out
myself, and was having a lot of fun with it (yes, i'm a geek), but I
don't have the time to pursue it right now. Anyway, with Ti, this
should no longer be a problem.
> ...all of which raises a question that I don't know the answer to... does
> Struts 1.3 pool Commands? I.e., if I implement my Actions as Commands, do
> I get that per-request functionality I want? If so, that is at least a
> step in a good direction.
IIRC, Craig implements Commands the way he did Actions, so there's one
instance of it for the whole app (per jvm, etc, you know what i mean).
> No one thinks Struts is perfect, but based on how many people
> use it and use it successfully, it's probably not fair to say it's poor,
> or that any one part of it is poor.
*Poor* is relative. Struts might've been the bleeding edge of tech
years ago, but it's got a lot of catching up to do now. Not that it
can't, but instead of slowly catching up, we'll quickly catch up
instead by merging with WW.
> Frank
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Hubert Rabago <hr...@gmail.com>.
On 1/6/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
> This will be easier to do in Struts 1.3 because rather than having to have a
> custom RequestProcessor you simply need to replace the Command that gets the
> Action instance with your own version that instantiates a new Action every
> time. So rather than using o.a.s.c.c.s.CreateAction create your own
> implementation by extending AbstractCreateAction and implement getAction()
> method that does this.
<snip/>
> Again for the same reasons as above this should be straightforward to do in
> Struts 1.3 - you could use a property on the ActionMapping to flag this and
> replace the PopulateActionForm command with one that populates the Action.
<snip/>
> Niall
... and this is how I did it when I said earlier I played with these
approaches, so if anyone out there wants an example, just let me know
and I'll send you a url.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 1/7/06, Daniel Blumenthal <da...@wordchamp.com> wrote:
> I noticed that I haven't used any
> ActionForms (yet). Everything is being communicated via AJAX, and I just
> haven't needed any.
ActionForms and Ajax are not related. By the way, may I assume that
your app does not work with Javascript turned off or in Gen4 browsers?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: The framework I think I want...
Posted by Daniel Blumenthal <da...@wordchamp.com>.
Frank,
> Interesting... there is of course no reason you can't use
> ActionForms with AJAX, was it a conscious decision that you
> didn't need them? How
> are you getting around not using them? Your Actions pull parameters
> directly from request I assume?
Right. My struts-config.xml file is basically divided into three sections,
as follows.
Setup actions:
<action path="/Home" type="app.HomeSetupAction">
<forward name="success" path="/HomeView.do"/>
</action>
File mappings:
<action path="/HomeView" forward="/pages/Home.jsp"></action>
AJAX actions (all handled by one Action):
<action path="/GetWordInfo" type="app.CommandAction"/>
<action path="/Login" type="app.CommandAction"/>
<action path="/Logout" type="app.CommandAction"/>
To send AJAX commands, I use JavaScript to construct an appropriate
URL/query string, then send using the standard XMLHttpRequest code. Inside
the CommandAction class, I figure out which command was called
(request.getServletPath()), call the matching function, and use
request.getParameter() to get the parameters specific to the command.
> > Any thoughts on JSTL? Must have? Nice but not necessary?
>
> I just started using JSTL fairly recently, but I would highly
> recommend doing so. I guess I'd say VERY nice, but not
> necessary. However, I will say this... if you are thinking
> of using the Struts taglibs, aside from HTML, I think the
> better option by far is using JSTL. The HTML taglib still
> has a place, but the others I consider deprecated in favor of JSTL.
>
> Then again, if your building RIAs with Struts, my opinion is
> that the HTML taglib will get in your way far more than it
> will help anyway...
> That's another thread though :)
Very interesting - now that I'm not using ActionForms (to repeat - not a
conscious decision, but the way things seem to be turning out), I find
myself only using tiles, logic, and bean tags. So, everything *but* html.
I'll definitely give JSTL a hard look.
Oh, and I use sslext. Is this still necessary in 1.2.8? In 1.3?
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Daniel Blumenthal wrote:
> I hadn't really thought about it, but looking at the code which has already
> been written for "version 2" of my site, I noticed that I haven't used any
> ActionForms (yet). Everything is being communicated via AJAX, and I just
> haven't needed any. So it's interesting to hear that other people are
> moving away from them (even if for entirely different reasons).
Interesting... there is of course no reason you can't use ActionForms
with AJAX, was it a conscious decision that you didn't need them? How
are you getting around not using them? Your Actions pull parameters
directly from request I assume?
I've discussed with a few people the idea of developing an entirely new
framework that is specifically geared to writing RIAs, and I've
prototyped a few ideas, but honestly, none of it has been significantly
different than what we have already, which has dissuaded me from going
at it full-bore. I think the basic idea is worth persuing though... a
framework whos purpose in life is to build the kinds of apps we're
starting to see more and more of, rather than trying to do them with
frameworks that aren't really geared towards that. This is at least
part of the promise of JSF, but even that I feel tries to cater to the
more "typical" web development, and in doing so isn't the right
direction as far as what I'm talking about goes.
> Any thoughts on JSTL? Must have? Nice but not necessary?
I just started using JSTL fairly recently, but I would highly recommend
doing so. I guess I'd say VERY nice, but not necessary. However, I
will say this... if you are thinking of using the Struts taglibs, aside
from HTML, I think the better option by far is using JSTL. The HTML
taglib still has a place, but the others I consider deprecated in favor
of JSTL.
Then again, if your building RIAs with Struts, my opinion is that the
HTML taglib will get in your way far more than it will help anyway...
That's another thread though :)
> Daniel
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: The framework I think I want...
Posted by Daniel Blumenthal <da...@wordchamp.com>.
I just wanted to say, this has been a great thread, and given me a lot of
food for thought. As I mentioned previously, I've spent a lot of time with
my head down developing in Struts 1.1, and now that I'm refactoring my site,
it's good to hear people batting around different ideas about the different
weaknesses/strengths of the various frameworks.
I hadn't really thought about it, but looking at the code which has already
been written for "version 2" of my site, I noticed that I haven't used any
ActionForms (yet). Everything is being communicated via AJAX, and I just
haven't needed any. So it's interesting to hear that other people are
moving away from them (even if for entirely different reasons).
Any thoughts on JSTL? Must have? Nice but not necessary?
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dakota Jack <da...@gmail.com>.
Again, it was not a challenge. Thanks for explaining.
On 1/6/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>
> Its a valid point - I did vote for WebWork without much knowledge and
> anyone
> crticising my decision to do that probably has good grounds to do so. For
> the record the following was my response on the PMC list to the proposal
> to
> merge with WebWork.
>
> ---- quote ----
> "I like this idea and prefer it to Clarity. IMO a true merger of projects
> is
> the only way we might successfully pool resources and stop competing.
> Clarity is a good concept, but I don't believe it would be possible to
> keep
> everyone on board and prevent communities splitting. I have no real
> knowledge of WebWork, but it has a good reputation and I dabbled around in
> the source code a week or so ago and liked what I saw. I also think if
> Spring are involved then things are going to go badly - that may be an
> unfair criticism, but its my gut feeling.
>
> I don't have the time or ability to be driving Struts forward with major
> contributions or re-writes of the existing framework, but I am happy
> carrying on with smaller contributions and support -so pooling resources
> this way is IMO a good thing. It would be good to get to know the people
> from these other projects a bit better - I went to Eddie O'Neil's
> presentation at BeaWorld recently, but the others I know nothing about.
> Are
> any of them going to ApacheCon?"
>
> ---- end quote ----
>
> Niall
>
> ----- Original Message -----
> From: "Dakota Jack" <da...@gmail.com>
> Sent: Friday, January 06, 2006 11:59 PM
>
>
> I am confused (there's an opening for those that like them): did you not
> vote for WebWorks, Niall? If so, how could it be that this education is
> happening now? That's not a challenge so please don't take it as one, but
> a
> curious question as to what is going on.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: The framework I think I want...
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Its a valid point - I did vote for WebWork without much knowledge and anyone
crticising my decision to do that probably has good grounds to do so. For
the record the following was my response on the PMC list to the proposal to
merge with WebWork.
---- quote ----
"I like this idea and prefer it to Clarity. IMO a true merger of projects
is
the only way we might successfully pool resources and stop competing.
Clarity is a good concept, but I don't believe it would be possible to keep
everyone on board and prevent communities splitting. I have no real
knowledge of WebWork, but it has a good reputation and I dabbled around in
the source code a week or so ago and liked what I saw. I also think if
Spring are involved then things are going to go badly - that may be an
unfair criticism, but its my gut feeling.
I don't have the time or ability to be driving Struts forward with major
contributions or re-writes of the existing framework, but I am happy
carrying on with smaller contributions and support -so pooling resources
this way is IMO a good thing. It would be good to get to know the people
from these other projects a bit better - I went to Eddie O'Neil's
presentation at BeaWorld recently, but the others I know nothing about. Are
any of them going to ApacheCon?"
---- end quote ----
Niall
----- Original Message -----
From: "Dakota Jack" <da...@gmail.com>
Sent: Friday, January 06, 2006 11:59 PM
I am confused (there's an opening for those that like them): did you not
vote for WebWorks, Niall? If so, how could it be that this education is
happening now? That's not a challenge so please don't take it as one, but a
curious question as to what is going on.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dakota Jack <da...@gmail.com>.
I am confused (there's an opening for those that like them): did you not
vote for WebWorks, Niall? If so, how could it be that this education is
happening now? That's not a challenge so please don't take it as one, but a
curious question as to what is going on.
On 1/6/06, Niall Pemberton <ni...@blueyonder.co.uk> wrote:
>
> ----- Original Message -----
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> Sent: Friday, January 06, 2006 8:56 PM
>
>
> >
> > I'm on chapter 4 :)
> >
> > Frank
>
> Excellent. I can't decide if its a really well written book or that it
> seemed so familiar that it just felt like being at home - only better!
> Most
> technical books I get bored with v.quickly and end up just dipping in and
> out for the bits I want, but I sat and read the first 5 chapters and it
> seemed v.easy going. Got a bit busy in the last week so haven't been back
> to
> it yet.
>
> Niall
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: The framework I think I want...
Posted by David Evans <ds...@berndtgroup.net>.
On Fri, 2006-01-06 at 20:49 +0000, Niall Pemberton wrote:
> ----- Original Message -----
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> Sent: Friday, January 06, 2006 8:21 PM
>
> > Not at all a significant enhancement, but
> > think of all the things you could then do. How about a simple flag to
> > tell the RP to populate the Action rather than an ActionForm, thereby
> > giving Michael his dream of a combined Action and ActionForm?
>
> Again for the same reasons as above this should be straightforward to do in
> Struts 1.3 - you could use a property on the ActionMapping to flag this and
> replace the PopulateActionForm command with one that populates the Action.
> In this case though as well as configuring the chain to use the custom
> Command, you will also need to change the sequence of Commands since the
> Action is currently created after the ActionForm is populated.
related to this, sort of, on this page:
http://struts.apache.org/struts-action/roadmap.html
under the "Struts Action Framework 1.5.x considerations" heading it says:
"Consider a "populate" method on ActionForm. From an OOP standpoint,
it might be cleaner if an ActionForm populated itself rather than
rely on a "god" class to populate it from the outside."
It seems that even if you change the process, as stated in the original post,
to populate the Action instead of the ActionForm, it would still be nice to allow
the population method to be controlled somehow, either by having a "populate" method
in the ActionForm or Action, or even declaring a populate class in the ActionMapping,
that could be any java class that defines a "populate" method.
Does anyone else care about this? Because i have an application in which i had
to extend the RequestProccessor, i overloaded the processPopulate method to check
the ActionForm for a "populate" method, via reflection, which would be run, if
it existed. The application builds forms on the fly out of a set of form/page/field
definitions that exist in a database, each field having a "fieldType" that corresponds
to a class that defines a populate, validate and generateView method.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
Sent: Friday, January 06, 2006 9:17 PM
> On Fri, January 6, 2006 4:09 pm, Niall Pemberton said:
> > Excellent. I can't decide if its a really well written book or that it
> > seemed so familiar that it just felt like being at home - only better!
>
> That's what struck me too... I have to admit my feeling so far has been
> "ok, this doesn't seem all *that* much better than what Struts offers",
> but I suspect there are some things coming that will change that. But,
> through it all I'm also thinking "well, this isn't going to be a difficult
> transition at all for Struts developers", which is really good. It really
> *is* quite familiar, at least so far.
Going from memory, in one of the first few chapters they say something along
the lines that its the small bits - attention to detail - just finishing off
the product that little bit better - adds up to something that makes a big
improvment as a whole. So far I'd have to agree and I think we have been
guilty of not quite finishing things off well as we could - take errors as
an example - how many users get really frustrated becuase they get some
obscure message that makes no sense? Anyway the example they used to
demonstrate this was v.poor (<bean:message> can only take 4 args) - I was
tempted to pop in a new <bean:arg> tag - it would suited my perverse sense
of humour to make the book out of date ;-) Even though the example was poor
though I do agree with the overall point.
Niall
> Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 4:09 pm, Niall Pemberton said:
> Excellent. I can't decide if its a really well written book or that it
> seemed so familiar that it just felt like being at home - only better!
That's what struck me too... I have to admit my feeling so far has been
"ok, this doesn't seem all *that* much better than what Struts offers",
but I suspect there are some things coming that will change that. But,
through it all I'm also thinking "well, this isn't going to be a difficult
transition at all for Struts developers", which is really good. It really
*is* quite familiar, at least so far.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
Sent: Friday, January 06, 2006 8:56 PM
>
> I'm on chapter 4 :)
>
> Frank
Excellent. I can't decide if its a really well written book or that it
seemed so familiar that it just felt like being at home - only better! Most
technical books I get bored with v.quickly and end up just dipping in and
out for the bits I want, but I sat and read the first 5 chapters and it
seemed v.easy going. Got a bit busy in the last week so haven't been back to
it yet.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 3:49 pm, Niall Pemberton said:
> This will be easier to do in Struts 1.3 because rather than having to have
> a
> custom RequestProcessor you simply need to replace the Command that gets
> the
> Action instance with your own version that instantiates a new Action every
> time. So rather than using o.a.s.c.c.s.CreateAction create your own
> implementation by extending AbstractCreateAction and implement getAction()
> method that does this.
Agreed. That's why a few weeks back I was making a lot of noise about
getting 1.3 out. Once it is out, a lot of these sorts of things will
become common knowledge and Struts will look a whole lot better in a
number of ways.
> Also, I've only just started reading the WebWork book (on Chpt 5), but it
> works in this way already (no separate form and a new instance every time)
> -
> I believe they're moving away from having to have any concrete classes /
> interfaces - just have a POJO that gets populated and then configure it to
> call a method.
I'm on chapter 4 :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
Sent: Friday, January 06, 2006 8:21 PM
> The interesting thing is, there are some relatively minor tweaks that
> could be done to Struts that would solve a lot of problems. How about
> creating Actions per-request?
This will be easier to do in Struts 1.3 because rather than having to have a
custom RequestProcessor you simply need to replace the Command that gets the
Action instance with your own version that instantiates a new Action every
time. So rather than using o.a.s.c.c.s.CreateAction create your own
implementation by extending AbstractCreateAction and implement getAction()
method that does this.
> Not at all a significant enhancement, but
> think of all the things you could then do. How about a simple flag to
> tell the RP to populate the Action rather than an ActionForm, thereby
> giving Michael his dream of a combined Action and ActionForm?
Again for the same reasons as above this should be straightforward to do in
Struts 1.3 - you could use a property on the ActionMapping to flag this and
replace the PopulateActionForm command with one that populates the Action.
In this case though as well as configuring the chain to use the custom
Command, you will also need to change the sequence of Commands since the
Action is currently created after the ActionForm is populated.
Also, I've only just started reading the WebWork book (on Chpt 5), but it
works in this way already (no separate form and a new instance every time) -
I believe they're moving away from having to have any concrete classes /
interfaces - just have a POJO that gets populated and then configure it to
call a method.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 2:59 pm, Dakota Jack said:
> Heh, Frank,
>
> The major problem with action forms is that there is an assumption that an
> action must be sandwiched between two instances of the same action form
> response object. This is simply contrary to what anyone would logically
> expect of a normal transversal by a client through a site. An action,
> typically, should yield a distinct action form from the prior action form.
>
> AF1 (response) --> request --> A1 --> AF2 (response).
I would tend to agree with that... you know, I have an interesting
experience... almost three years ago I wrote a rather complex application
that was not Struts-based, it used a home-grown framework. There was no
notion of an ActionForm in it, or anything like it. As a result, the
Actions have a method that pulls parameters out of request and stuffs them
into a WorkContext object (which looks a lot like a cross between an
ActionForm and a ChainContext). Almost two years ago, I was asked to
convert the application to Struts. For a number of reasons, ActionForms
wound up being used as (a) output containers, i.e., a place to store data
destined for display and (b) as storage objects during a wizard flow. I
did not use the Struts taglibs, and ActionForms were not attached to
Action mappings, hence no auto-population occurred, no auto-validation,
etc.
Now, it is true that I didn't get much of the benefit of Struts doing
this, but it was necassery to avoid rearchitecting the entire application.
More importantly though, all the problems typically sited with Struts,
and ActionForms in particular, were not present. I had a very easy time
of making it do exactly what I want, and this thing is a pretty complex
app, has a number of wizard flow, freeform navigation, is what most would
now call an RIA, etc.
To me, it's really the auto-population mechanism that causes problems, not
because I think its a bad idea (it's not) but because I think we don't
have enough control over it. I'd like to be able to turn it off on a
per-mapping basis for instance, especially when I'm pulling the form out
of session and I don't want to just automagically have what's there
overwritten with what was submitted (which is, I believe, a problem
Michael was pointing out).
The interesting thing is, there are some relatively minor tweaks that
could be done to Struts that would solve a lot of problems. How about
creating Actions per-request? Not at all a significant enhancement, but
think of all the things you could then do. How about a simple flag to
tell the RP to populate the Action rather than an ActionForm, thereby
giving Michael his dream of a combined Action and ActionForm? Again,
we're not talking about a big change. These are also not new ideas by any
stretch, I, and you, and Michael and others have been tossing these things
around for at least a year or more.
...all of which raises a question that I don't know the answer to... does
Struts 1.3 pool Commands? I.e., if I implement my Actions as Commands, do
I get that per-request functionality I want? If so, that is at least a
step in a good direction.
> This has been, in my opinion, the biggest downfall of Struts. As you
> suggested, Frank, the whole way the view state is taken care of by Struts
> is
> poor.
Woah, hold on now, don't put words in my mouth :) I wouldn't go so far as
to say it's poor because many people have had a great deal of success with
it. I *do* think there are some shortcomings that may or may not have
some relatively simple solutions, and I don't think too many people would
disagree. No one thinks Struts is perfect, but based on how many people
use it and use it successfully, it's probably not fair to say it's poor,
or that any one part of it is poor.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dakota Jack <da...@gmail.com>.
Heh, Frank,
The major problem with action forms is that there is an assumption that an
action must be sandwiched between two instances of the same action form
response object. This is simply contrary to what anyone would logically
expect of a normal transversal by a client through a site. An action,
typically, should yield a distinct action form from the prior action form.
AF1 (response) --> request --> A1 --> AF2 (response).
This has been, in my opinion, the biggest downfall of Struts. As you
suggested, Frank, the whole way the view state is taken care of by Struts is
poor.
<snip>
On 1/6/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>
> The idea of an ActionForm was a great concept to begin with, and it seems
> like many people don't see the benefit (not saying you Michael, just
> making a general statement).
>
> Frank
</snip>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: The framework I think I want...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Fri, January 6, 2006 1:01 pm, Michael Jouravlev said:
> Rrright. You want to save on network bandwidth by validating in
> browser. At the same time we have Ajax "suggest"-type junk growing in
> popularity, where server is pulled each time a user hits a button.
Well, not *each* time a key is pressed... look at the code for Google
Suggests and you will see they do a really cool thing where they throttle
the number of requests based on how fast you are typing. It's not a 1:1
call per keypress unless you are typing really slow.
(My own AjaxTags example doesn't do this, but hey, Google has Ph.D's to
spare whereas I don't have even one!)
> Nah. Imho, client-side validation should be minimal. Empty/non-emty,
> proper length. Maybe some simple data conversion check like is it a
> number or a valid email. Yes, it is not DRY and redundant because the
> final validation is done on the server anyway, but user's Athlon 64
> needs some code to chew. Everything more complex than above, including
> custom error messages, inter-field dependencies, etc is checked on
> server. It will be checked on server anyway, because user's browser is
> in the open, whoever can change the validation rules or turn them off
> or turn Javascript off.
Best practices have dictated for a long time that any validation that
occurs on the client should also occur on the server. But, the more you
can pull off on the client, the more responsive and user-friendly your
application will usually be. Of course there is that fine line of not
having business logic on the client (i.e., should an entered dollar amount
be checked against a mutual fund load table on the client? Probably not).
> Client validation is just a cherry on a cake, but I don't want this
> cherry to be too large.
I would argue the bigger the cherry, the better. The application will be
better for it in most cases. Yes, there is more to consider when you do
that, but the benefits outweigh the negatives IMO.
But, I always give the cherry to my wife off my sundaes anyway, I'm not a
fan of cherrys to begin with :)
> Actually, if we talk about Struts, ActionForms is the basis of this
> layer, I only would prefer them to be combined with Actions. There are
> properties aka getters/setters, so setters can always check what is
> being passed from browser. I am an old school in terms that I usually
> don't use dynaforms, instead I define an ActionForm having dual typing
> either by having String-type and strong-type property right in the
> form, or by having String-type property in the form for display and a
> nested strong-type property from a business object. Yes, I would like
> this to be automated and JSF managed beans look nice in this extent.
The idea of an ActionForm was a great concept to begin with, and it seems
like many people don't see the benefit (not saying you Michael, just
making a general statement). Think about the case where you want to slap
a VB-based front-end over a Struts-based application. When you have an
object that serves as a string-only buffer between the presentation and
the rest of the application, you have effectively abstracted away any data
types differences between how the presentation is built and how the rest
of the app is built because strings are, for all intents and purposes,
universal. If you try and go directly to native types, you have to deal
with the fact that maybe VB doesn't have a BigDecimal type for example.
The conversion, assuming one is possible, has to occur at an arguably
inappropriate time.
I suppose the fact that not too many people have ever had to change from
JSP to VB has something to do with this :)
If you combine an ActionForm with an Action, what happens if you want to
give that combined object session scope? Would you then store the entire
thing in session? I would assume so. That seems like a (potentially) big
waste of resources. Why wouldn't you rather have an object that contains
almost nothing but data and store that? (I'm playing devil's advocate
here... I haven't fully decided whether I agree with the basic premise or
not).
> Advertising ActionForm as a request parameter holder in Struts best
> practices is a mistake imho. It can be used as an input/output buffer,
> as this kind of layer that you talk about. Apparently, it should have
> session scope ;) and implement Serializable.
I would make the argument that session-scope for an ActionForm is the
abomination. There should be something else, and I'm not sure I know
what, that gets stashed in session scope. If an ActionForm is thought of
ONLY as a buffer as you say, a DTO between presentation and control
basically, Struts seems a lot cleaner all of a sudden. Of course, that
then leaves a lot of questions about how you persist user entries and
such, and I admit I don't have a good answer there.
> Michael.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 1/6/06, Ted Husted <te...@gmail.com> wrote:
> On 1/6/06, Dave Newton <ne...@pingsite.com> wrote:
> > Doesn't it just need validation info rather than model knowledge (you
> > listed validation constraints/msgs in your original list, which is why I
> > can't figure out why it needs any more info).
>
> If we consider the target type to be a validation constraint, then we
> are stating the same fact twice. Target type is an implicit validation
> constraint. Other domain constraints might be a range of values within
> the target type. And, of course, in practice, checking subranges
> usually begs converting the input to the target type.
Rrright. You want to save on network bandwidth by validating in
browser. At the same time we have Ajax "suggest"-type junk growing in
popularity, where server is pulled each time a user hits a button.
Nah. Imho, client-side validation should be minimal. Empty/non-emty,
proper length. Maybe some simple data conversion check like is it a
number or a valid email. Yes, it is not DRY and redundant because the
final validation is done on the server anyway, but user's Athlon 64
needs some code to chew. Everything more complex than above, including
custom error messages, inter-field dependencies, etc is checked on
server. It will be checked on server anyway, because user's browser is
in the open, whoever can change the validation rules or turn them off
or turn Javascript off.
Client validation is just a cherry on a cake, but I don't want this
cherry to be too large.
> Ideally, formatting and conversion should be part of validation, so
> that we don't do any of these things more than once as part of the
> same request/response. But, all this is something that we also need to
> do with *any* presentation layer, not just a web front-end. For
> example, we should be able to run independant unit tests (another
> presentation layer) that demonstrate that input and output are being
> formatted as expected.
>
> These concerns, and many others, beg the existing of a layer between
> *any* presentation layer and *any* business layer. I think we've been
> trying to create this layer with efforts like XWork and Commons Chain.
> A controller layer between the view and model that handles concerns
> like conversion/formatting/validation, and even logical navigation,
> but that is independant of a particular presentation layer.
Actually, if we talk about Struts, ActionForms is the basis of this
layer, I only would prefer them to be combined with Actions. There are
properties aka getters/setters, so setters can always check what is
being passed from browser. I am an old school in terms that I usually
don't use dynaforms, instead I define an ActionForm having dual typing
either by having String-type and strong-type property right in the
form, or by having String-type property in the form for display and a
nested strong-type property from a business object. Yes, I would like
this to be automated and JSF managed beans look nice in this extent.
I also store error messages in the ActionForm, so my errors correspond
to a page (or a component on a page). I guess I could go further and
have error messages per property but this is too much hassle.
Advertising ActionForm as a request parameter holder in Struts best
practices is a mistake imho. It can be used as an input/output buffer,
as this kind of layer that you talk about. Apparently, it should have
session scope ;) and implement Serializable.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Ted Husted <te...@gmail.com>.
On 1/6/06, Dave Newton <ne...@pingsite.com> wrote:
> Doesn't it just need validation info rather than model knowledge (you
> listed validation constraints/msgs in your original list, which is why I
> can't figure out why it needs any more info).
If we consider the target type to be a validation constraint, then we
are stating the same fact twice. Target type is an implicit validation
constraint. Other domain constraints might be a range of values within
the target type. And, of course, in practice, checking subranges
usually begs converting the input to the target type.
Ideally, formatting and conversion should be part of validation, so
that we don't do any of these things more than once as part of the
same request/response. But, all this is something that we also need to
do with *any* presentation layer, not just a web front-end. For
example, we should be able to run independant unit tests (another
presentation layer) that demonstrate that input and output are being
formatted as expected.
These concerns, and many others, beg the existing of a layer between
*any* presentation layer and *any* business layer. I think we've been
trying to create this layer with efforts like XWork and Commons Chain.
A controller layer between the view and model that handles concerns
like conversion/formatting/validation, and even logical navigation,
but that is independant of a particular presentation layer.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dave Newton <ne...@pingsite.com>.
Ted Husted wrote:
>On 1/6/06, Dave Newton <ne...@pingsite.com> wrote:
>
>
>>I expect I'm just groggy, but why does the presentation side need to
>>know about model/persistence stuff?
>>
>>
>Client side validation.
>
>
Doesn't it just need validation info rather than model knowledge (you
listed validation constraints/msgs in your original list, which is why I
can't figure out why it needs any more info).
Dave
Re: The framework I think I want...
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, Ted Husted <te...@gmail.com> wrote:
>
> On 1/6/06, Dave Newton <ne...@pingsite.com> wrote:
> > I expect I'm just groggy, but why does the presentation side need to
> > know about model/persistence stuff?
>
> Client side validation.
You also need to know the model data type for conversion, in both directions
(modelDataType->String for rendering, String->modelDataType for updating).
Struts Action Framework currently splits responsibilities for this ... the
tags do conversion automatically on rendering, but it is up to the
application's business logic to deal with it for updating. In most of the
other technologies (JSF, SpringMVC, Tapestry, WW) the responsibility all
belongs to the view tier.
> -T.
Craig
Re: The framework I think I want...
Posted by Ted Husted <te...@gmail.com>.
On 1/6/06, Dave Newton <ne...@pingsite.com> wrote:
> I expect I'm just groggy, but why does the presentation side need to
> know about model/persistence stuff?
Client side validation.
> One of my primary concerns is that I want as much of the application as
> "reasonable" to be accessible to the _developers_ of each layer but
> still provide safety. IOW, I want the HTML folks to know what's
> available to them on the page and how to use it (c:forEach seems easy to
> us, but man... :/ the back-end folks to know what the front-end needs, etc.
Yes, a big advantage to explicit inputs and outputs per command is
that it tells both tools and developers what a command expects and
needs, and by implication, what it doesn't use, so that the
presentation layers (including unit tests) can see how to use the
command.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Dave Newton <ne...@pingsite.com>.
Ted Husted wrote:
>The big picture is that the presentation layer, whether it's a web
>layer or not, needs to know a lot about every property that is exposed
>by the application. We need to know the property's
>
>* view name
>* view type (String or boolean)
>* validation constraints
>* default control type
>* model name
>* model type
>* persistence type
>* label
>* data entry hint
>* validation message
>* text format (mask)
>
>
I expect I'm just groggy, but why does the presentation side need to
know about model/persistence stuff?
>But, in no one place do we itemize these facts (and any others I
>missed). Instead, we scatter them throughout the application [...]
>
>I know that some people say that we have too much XML in our
>applications [...] I'd like to take it a step further
>so that we could just say "put form x here", and the rest could be
>generated from the object graph and style sheet.
>
>
+1
IMHO, there are several problems with XML:
1) Wads of files, each serving a different purpose, instead of a
collective file (which can get big, but that's easy enough to deal with
on any of several layers).
2) XML is a pain; it's difficult to read (for me, anyway). Much of this
can be solved with UI work.
For one project I had a "master XML" file (physically many, but
whatever) from which I generated Torque schema files, JSP pages, Action
base classes, form beans, validation rules, application resources, etc.
On top of this was layered a pseudo-GUI (mostly a property editor) such
that a project stub could be created in minutes.
>I think the trick is that we need to stop repeating
>ourselves, and provide a central repository where all these facts can
>be maintained for all the view properties.
>
>
Oh, that would be nice, especially if I didn't have to code JSPs for
every freakin' form/display/etc. Typing sucks, and so far J2EE has made
me do too much of it.
>Ideally, I
>believe that tit would be helpful
>
Ah, yes... that it would. Or at least pleasant, if not technically
"helpful."
Oh, typo.
>if there were a unified set of
>mappings, accessible to each layer, that could describe an entity as
>it flows from the database, through an object graph, onto the
>presentation layer, and back again. (Or not, if it is a virtual
>property.)
>
>
One of my primary concerns is that I want as much of the application as
"reasonable" to be accessible to the _developers_ of each layer but
still provide safety. IOW, I want the HTML folks to know what's
available to them on the page and how to use it (c:forEach seems easy to
us, but man... :/ the back-end folks to know what the front-end needs, etc.
All with a whiz-bang interface.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Ted Husted <te...@gmail.com>.
On 1/6/06, Tamas Szabo <sz...@gmail.com> wrote:
> So why is it better to bind request params to business layer objects
> directly without using ActionForms?
It isn't, really. People do that, but when we do, we flirt with the
dark side. The problem with ActionForms, and similar strategies, is
that we are going for the quick fix rather than the big fix. We try to
solve the immediate problems, but we don't step back and look at the
big picture.
The big picture is that the presentation layer, whether it's a web
layer or not, needs to know a lot about every property that is exposed
by the application. We need to know the property's
* view name
* view type (String or boolean)
* validation constraints
* default control type
* model name
* model type
* persistence type
* label
* data entry hint
* validation message
* text format (mask)
But, in no one place do we itemize these facts (and any others I
missed). Instead, we scatter them throughout the application, and then
we wonder why programming the web presentation is so hard. It's hard
because, when it comes to presentation layer properties, we still
don't
* Separate Concerns, and
* Say It Once (DRY)
I know that some people say that we have too much XML in our
applications, but I think the problem is that we have too much
notation in some places because there is not enough notation in other
places. If we graph the properties, and then list which properties go
with a form, much of the validation and form layout can be deduced,
and many simple forms could be generated from a single tag.
WebWork is starting to do the latter now. You can list the controls
for a form, and the UI tags take care of all the formatting, including
table tags, labels, and messages. I'd like to take it a step further
so that we could just say "put form x here", and the rest could be
generated from the object graph and style sheet.
In the OverDrive whiteboard, we've been using a strategy where the
input and output properties for a command (or Action) are explicit,
along with which input properties are required. We also specify
"processors" for each property that handle the validation and
formatting concerns. Likewise, the labels, hints, and validation
messages are specified *once* for each property. Nearly all the
validation concerns can be deduced from a rich object graph, which
eliminates a lot of bother.
I expect that if you are using a rich domain object model, then
annotations could be used in lieu of XML, or at least in conjunction
with XML. But, regardless of how the presentation's view schema is
created, I think the trick is that we need to stop repeating
ourselves, and provide a central repository where all these facts can
be maintained for all the view properties.
Specifications like XForms imply that a view schema exists, but do not
explicity define anything like a master object graph. Ideally, I
believe that tit would be helpful if there were a unified set of
mappings, accessible to each layer, that could describe an entity as
it flows from the database, through an object graph, onto the
presentation layer, and back again. (Or not, if it is a virtual
property.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Tamas Szabo <sz...@gmail.com>.
On 1/6/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 1/5/06, Tamas Szabo <sz...@gmail.com> wrote:
> > >
> > > I'm actually quite happy with what Struts has to offer except for the
> > > deal with having to use ActionForms. I'd really like a Struts-like
> > > framework but allows me to use POJOs to capture my data and provides a
> > > nice way to redisplay that data back to the user if validation fails
> (ie
> > > a POJO that backs a form with a Data datatype will display back the
> > > String they entered).
> >
> >
> > You can bind request parameters to POJOs using Spring.
> > And you can use the SpringBindingActionForm to redisplay the data to the
> > user.
>
> From
> http://www.springframework.org/docs/api/org/springframework/web/struts/SpringBindingActionForm.html
> "Note this ActionForm is designed explicitly for use in request scope."
>
> Will not work for me.
Not out of the box. But you can extend it.
We extended it, and use the subclass one in session scope.
The other interesting thing is that you can't use <c:out ...> on properties
exposed via a SpringBindingActionForm. That's probably because
JSTL tags don't get properties using Commons Beanutils ...
But if we are at the subject of binding request params to business layer
objects...
Probably a lot of people bind req params directly without using ActionForms
just
to avoid writitng all the ActionForms. How do you assure
that only the allowed properties will be set in the object?
Ex. we have a bean with prop1, prop2.
Only prop1 is allowed to be changed, but no one can prevent someone sending
a request having a prop2 parameter in it. If you bind the request params to
objects directly
prop2 will be set to the value set by the "misbehaving" user.
I know a few solutions to this, but in all of them you will have to
explicitly specify all the
properties that are allowed to be set.
And if you do this then it's the same as declaring these properties as a
DynaActionForm
or to give it to a tool that generates an ActionForm ahving all these
properties.
So why is it better to bind request params to business layer objects
directly without using
ActionForms?
Tamas
Re: The framework I think I want...
Posted by Michael Jouravlev <jm...@gmail.com>.
On 1/5/06, Tamas Szabo <sz...@gmail.com> wrote:
> >
> > I'm actually quite happy with what Struts has to offer except for the
> > deal with having to use ActionForms. I'd really like a Struts-like
> > framework but allows me to use POJOs to capture my data and provides a
> > nice way to redisplay that data back to the user if validation fails (ie
> > a POJO that backs a form with a Data datatype will display back the
> > String they entered).
>
>
> You can bind request parameters to POJOs using Spring.
> And you can use the SpringBindingActionForm to redisplay the data to the
> user.
>From http://www.springframework.org/docs/api/org/springframework/web/struts/SpringBindingActionForm.html
"Note this ActionForm is designed explicitly for use in request scope."
Will not work for me.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Tamas Szabo <sz...@gmail.com>.
On 1/6/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 1/5/06, Tamas Szabo <sz...@gmail.com> wrote:
> >
> > >
> > > I'm actually quite happy with what Struts has to offer except for the
> > > deal with having to use ActionForms. I'd really like a Struts-like
> > > framework but allows me to use POJOs to capture my data and provides a
> > > nice way to redisplay that data back to the user if validation fails
> (ie
> > > a POJO that backs a form with a Data datatype will display back the
> > > String they entered).
> >
> >
> > You can bind request parameters to POJOs using Spring.
> > And you can use the SpringBindingActionForm to redisplay the data to the
> > user.
>
>
> What happens on invalid input in this scenario? For example, when you
> bind
> a parameter to an integer field, and then type "1a3" instead of "123" into
> the field. The user would expect "1a3" to be redisplayed.
Both the values entered by the user and validation messages are
stored in an Errors object.
You can use SpringBindingActionForm to:
1. expose the error messages from the Errors object to ActionMessages.
2. To expose the values entered by the user from the underlying Errors
object, which of course contains both valid and invalid input (the
SpringBindingActionForm extends ActionForm and it provides a subclass of
org.apache.commons.beanutils.PropertyUtilsBean)
See the API:
http://www.springframework.org/docs/api/org/springframework/web/struts/SpringBindingActionForm.html
... or the code:
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/springframework/web/struts/SpringBindingActionForm.java?view=markup
Craig
Tamas
Re: The framework I think I want...
Posted by Craig McClanahan <cr...@apache.org>.
On 1/5/06, Tamas Szabo <sz...@gmail.com> wrote:
>
> >
> > I'm actually quite happy with what Struts has to offer except for the
> > deal with having to use ActionForms. I'd really like a Struts-like
> > framework but allows me to use POJOs to capture my data and provides a
> > nice way to redisplay that data back to the user if validation fails (ie
> > a POJO that backs a form with a Data datatype will display back the
> > String they entered).
>
>
> You can bind request parameters to POJOs using Spring.
> And you can use the SpringBindingActionForm to redisplay the data to the
> user.
What happens on invalid input in this scenario? For example, when you bind
a parameter to an integer field, and then type "1a3" instead of "123" into
the field. The user would expect "1a3" to be redisplayed.
Craig
Tamas
>
>
Re: The framework I think I want...
Posted by Tamas Szabo <sz...@gmail.com>.
>
> I'm actually quite happy with what Struts has to offer except for the
> deal with having to use ActionForms. I'd really like a Struts-like
> framework but allows me to use POJOs to capture my data and provides a
> nice way to redisplay that data back to the user if validation fails (ie
> a POJO that backs a form with a Data datatype will display back the
> String they entered).
You can bind request parameters to POJOs using Spring.
And you can use the SpringBindingActionForm to redisplay the data to the
user.
Tamas
Re: The framework I think I want...
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:39 AM -0500 1/5/06, Rick Reumann wrote:
>Craig McClanahan wrote the following on 1/4/2006 4:24 PM:
>>On 1/4/06, Rick Reumann <st...@reumann.net> wrote:
>>>Since I've been working on a rich client .NET app for a while, I've been
>>>a bit out of the loop on all the latest 'goings on' in regard to
>>>frameworks. (I couldn't keep up with all the Struts/JSF/Shale/WebWork
>>>comments on the list a while a back.)
>>>
>>>I'm actually quite happy with what Struts has to offer except for the
>>>deal with having to use ActionForms. I'd really like a Struts-like
>>>framework but allows me to use POJOs to capture my data and provides a
>>>nice way to redisplay that data back to the user if validation fails (ie
>>>a POJO that backs a form with a Data datatype will display back the
>>>String they entered). The managed bean approach to JSF that I've used
>>>some was REALLY nice - but I'm not yet convinced I want everything else
>>>in regard to JSF at this time.
>>
>>
>>I don't know why ... JSF already does exactly what you are asking for here.
>
>I knew you were going to say that:) I do love the JSF 'backing bean'
>concept. Other aspects of JSF I'm not completely sold on yet, but I
>think I will spend more time with it again shortly to get up to
>speed the latest developments. (The last app I built with it was
>about five months ago.)
And you may also want to look at the ModelDriven interface in
WebWork. I don't know of a succinct explanation of it online, but
it's discussed in the Webwork in Action book enough that you could
get the idea. But it would basically allow you to use POJOs to
collect form data instead of writing or configuring form classes.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 1/4/2006 4:24 PM:
> On 1/4/06, Rick Reumann <st...@reumann.net> wrote:
>> Since I've been working on a rich client .NET app for a while, I've been
>> a bit out of the loop on all the latest 'goings on' in regard to
>> frameworks. (I couldn't keep up with all the Struts/JSF/Shale/WebWork
>> comments on the list a while a back.)
>>
>> I'm actually quite happy with what Struts has to offer except for the
>> deal with having to use ActionForms. I'd really like a Struts-like
>> framework but allows me to use POJOs to capture my data and provides a
>> nice way to redisplay that data back to the user if validation fails (ie
>> a POJO that backs a form with a Data datatype will display back the
>> String they entered). The managed bean approach to JSF that I've used
>> some was REALLY nice - but I'm not yet convinced I want everything else
>> in regard to JSF at this time.
>
>
> I don't know why ... JSF already does exactly what you are asking for here.
I knew you were going to say that:) I do love the JSF 'backing bean'
concept. Other aspects of JSF I'm not completely sold on yet, but I
think I will spend more time with it again shortly to get up to speed
the latest developments. (The last app I built with it was about five
months ago.)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The framework I think I want...
Posted by Craig McClanahan <cr...@apache.org>.
On 1/4/06, Rick Reumann <st...@reumann.net> wrote:
>
> Since I've been working on a rich client .NET app for a while, I've been
> a bit out of the loop on all the latest 'goings on' in regard to
> frameworks. (I couldn't keep up with all the Struts/JSF/Shale/WebWork
> comments on the list a while a back.)
>
> I'm actually quite happy with what Struts has to offer except for the
> deal with having to use ActionForms. I'd really like a Struts-like
> framework but allows me to use POJOs to capture my data and provides a
> nice way to redisplay that data back to the user if validation fails (ie
> a POJO that backs a form with a Data datatype will display back the
> String they entered). The managed bean approach to JSF that I've used
> some was REALLY nice - but I'm not yet convinced I want everything else
> in regard to JSF at this time.
I don't know why ... JSF already does exactly what you are asking for here.
Your backing beans don't have to be ActionForms ... they can be POJOs. The
properties of your POJOs can use native data types, because the components
take care of redisplaying the string formats for you on invalid data.
Converters can be registered explicitly, or defaulted based on the data type
of the POJO property you bind to. Validators can be added (and, if you add
Shale to the mix, you can get exactly the same Commons Validator support for
client side and server side validation that Struts Action Framework offers).
And, you get managed beans too :-).
Will the collaborative effort between Struts and WebWork possibly be
> exactly what I'm looking for? I looked at WebWork a long time ago and it
> looked like it took a managed bean approach type of an approach and no
> need for ActionForms (but I never really used it, so I could be way off.)
The current WW code is somewhere in the middle between Struts 1.x and JSF.
It combines the concepts of Action and ActionForm (so your execution method
has direct access to the form data), lets you use native data types), and
creates instances on each request for you. You used to have to implement
the Action interface, but that's now optional. It doesn't have "managed
beans" per se, but you could use Spring for that (although you don't get
general binding of component values to model data on them).
The story is yet to be written, but I presume the merged code will carry
forward these sorts of features.
--
> Rick Reumann
> http://www.tech.reumann.net - Struts lessons, articles, etc.
Craig