Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/SAF1RoughSpots
--
== Code Issues ==
- 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O
conversion. !FormDef seem to solve most conversion/validation issues, so bring
!FormDef into Struts core and consider using dynaforms with nested business
objects as a best practice.
+ 1. '''I/O conversion''' [MichaelJ] The suckiest part of SAF1 is I/O
conversion. [https://formdef.dev.java.net/ FormDef] seem to solve most
conversion/validation issues, so bring !FormDef into Struts core and consider
using dynaforms with nested business objects as a best practice.
- 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple,
for a user's perspective it includes just reset/populate/validate functions.
Consider to call all lifecycle functions explicitly from an action class, no
more automatic population.
+ 1. '''SAF1 lifecycle''' [MichaelJ] The lifecycle of SAF1 is quite simple;
from a user's perspective it includes just reset/populate/validate functions.
Consider the option to call all lifecycle functions explicitly from an action
class, no more automatic population.
* [FrankZ] I personally would not want to see the auto-population and
validation and such go away. I think them being declarative is a powerful
notion. I DO however agree that a developer should be able to turn them off
declaratively and do it all manually.
- * [MichaelJ] Considering to call lifecycle functions explicitly does not
mean removing autopopulation from the next release :)
1. '''Automatic validation''' [MichaelJ] Deprecate automatic validation,
newbies always stumble upon the fact that their action class is not called when
validation fails. Instead, promote explicit validation.
* [FrankZ] Definite -1 from me. Again, I'm +1 to being able to turn it
on and off, but I very much believe it should be there. Perhaps there is some
room for better logging in the cases you mention?
- * [MichaelJ] Deprecating autovalidation does not mean removing that
feature from the next release :) I hope you reconsider your -1 or do you want
me to remove deprecate word entirely? I think that without autovalidation
things will be clearer: action class will always be called, and different error
conditions with different targets can be supported.
1. '''Input attribute''' [MichaelJ] Deprecate input attribute of
action tag in struts-config.xml. At least, rename it to error or something.
A frequent misconception is to think that the lifecycle starts with displaying
an input page, which is obviously not true.
* [FrankZ] +0. I don't disagree with you at all, and I think there are
probably other things that could similarly be changed. However, I think it is
very important that anything done with SAF1 be evolutionary and take
backwards-compatibility into consideration in a big way. I think if you want
revolution you go for SAF2 (a minor revolution in that it's theoretically still
compatible) or Shale.
- * [MichaelJ] Hey Frank, now ''you'' are writing me off the boat? ;) What
if I want some revolution staying within SAF1 codebase?
1. '''Form attribute''' [MichaelJ] Add form attribute with the same
meaning as name attribute; deprecate name.
* [FrankZ] +0. Same comment as the above point.
- * [MichaelJ] Again, add means add. It does not mean removing name in
the next release.
1. '''Differentiate forward from redirect in mappings''' [MichaelJ]
forward tag implements both forward and redirect, this is confusing.
Implement two separate tags like render for forward and transfer for
redirect. forward tag still can be kept for compatibility purposes.
* [FrankZ] Hmm, I'm not sure how I feel about that. Maybe simply adding
a type attribute, ala Webwork, would do the trick? forward or redirect as
values?
@@ -46, +42 @@
/component
}}}
- This mapping use new format for action mapping. component is essentially
action with different defaults and some new elements. This is 1:1
correspondence between mapping and action class. Same action class handles
input phase as well as render phase (I saw your remark about
Redirect-After-Post, here it is, implemented).
+ This mapping uses the action mapping format introduced in Struts Dialogs
project. A component is essentially an action with different defaults and
some new elements. This is 1:1 correspondence between mapping and action class.
Same action class handles input phase as well as render phase (I saw your
remark about Redirect-After-Post, here it is, implemented).
1. '''!DispatchActions''' [MichaelJ] Having that many dispatching actions
in the distro, all of them but
