[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
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 -- 1. '''Built-in support for RAP (Redirect After Post) pattern''' [FrankZ] I'm not sure how best to accomplish this, but this should be a very easy thing for a developer to do, the framework should do any required heavy lifting. Again, not so much a rough spot as it is something I think a lot of people would appreciate. * [MichaelJ] Redirect-After-Post is fully implemented in [http://struts.sourceforge.net/strutsdialogs/index_v1.html Struts Dialogs 1.x]. After Struts 1.2.9 got better dispatch action, I stopped advertising Struts Dialogs project, but it is still valuable in terms of samples. Check it out. EventActionDispatcher and !EventDispatchAction can implement Redirect-After-Post as well, Paul and I spent quite some time discussing how !EventDispatchAction can be used for both input and render phases. + * [MichaelJ] To simplify redirect-after-post pattern, Struts must implement Flash scope, that is, the scope that survives after redirect, but is automatically cleaned up after redirected request finishes. Currently similar pattern is applied to the messages queued to session scope. 1. '''Pre and post-processing abilities''' [FrankZ] A developer should be able to specify a class and method to call before and after an Action executes, on a per-mapping basis. This should be independant of modifying a chain. Should just amount to adding the appropriate config file changes and two commands to the default chain. This is for handling things like common setup of view-type Actions, etc. * [MichaelJ] +0. I prefer having 1:1 correspondence between mapping and action class. With autopopulation out of the way, I can call whatever I want right in the beginning and at the end of execute() method. Same thing, but simpler, I think. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
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 @@ }}} - 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
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
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
--
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.
* [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?
+ * [MichaelJ] Check out this mapping from one of the users of Struts
Dialogs 1.x (he uses Tiles too):
+ {{{
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ }}}
+
+ 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).
+
- 1. '''DispatchActions''' [MichaelJ] Having that many dispatching actions
in the distro, all of them but !EventDispatchAction and more generic
EventActionDispatcher should be deprecated.
+ 1. '''!DispatchActions''' [MichaelJ] Having that many dispatching actions
in the distro, all of them but !EventDispatchAction and more generic
EventActionDispatcher should be deprecated.
1. '''Tiles improvements''' [MichaelJ] Improve Tiles to support real
components, that can be fully independent of composite page, can process user
input, and can render themselves.
1. '''Per-request Action instantiation''' [FrankZ] Actions should be
instantiated for each request, therefore removing the thread safety concerns
that exist today.
+ * [MichaelJ] +0. Not sure that this bothers me anymore :)
1. '''Pure POJO !ActionForms''' [FrankZ] An !ActionForm should not need to
extend !ActionForm. The framework would have to be smart enough to not call
validate() and such in that case. This would allow for the Action to be the
!ActionForm as well, and this is really the underlying goal because many people
view them
[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev
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 New page: Struts Action 1 (a.k.a. Struts Classic) is a well-known framework. It has its deficiencies, but workarounds are known as well. For many, continuing to use SAF1 makes sense even after release of SAF2. This page tries to summarize major issues with SAF1 and possibilities to fix them or provide better workarounds. == Code Issues == 1. 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. 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. Deprecate automatic validation, newbies always stumble upon the fact that their action class is not called when validation fails. Instead, promote explicit validation. 1. 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. 1. Add "form" attribute with the same meaning as "name" attribute; deprecate "name". 1. "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. 1. Having that many dispatching actions in the distro, all of them but !EventDispatchAction and more generic EventActionDispatcher should be deprecated. 1. Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. == Documentation Issues == 1. Struts 1.3.x introduces the concept of chain of commands, but there is no comprehensive documentation on how this new architecture can be used for initial request processing (as a substitute to solid RequestProcessor) as well as for business processing (using Commands instead of Actions, etc). 1. Taglib reference uses too many words for simple things. Words like "attribute", "value", "property" used in different contexts, which does not help much in understanding how the tags really work. 1. Taglib docs should show one best way of doing things instead of saying that one can use this, or this or this in combination with this. 1. Tags that render widgets should have examples and pictures. Here is some initial work in attempt to improve this: StrutsWidgets. == Best Practices Issues == 1. Instead of having several ways to do things, SAF1 should focus on one best and the most common way, even if it involves a couple more lines of code. Less is more. 1. Up until now SAF1 best practices center around a View, usually a JSP page. Instead, best practices should teach the webresource-centered approach. 1. Dispatch-action style request processing should become a cornerstone technique instead of "yet another way of doing things". It works especially well in data entry form processing or menu processing. See DataEntryForm. 1. Best practices should explain that there is nothing wrong in having session-scoped action forms. Best practices should teach how to build stateful web resources. 1. It is possible to build stateful and independent web components with SAF1. Best practices should teach how to do that. 1. !ActionForm should be used as I/O buffer instead of simply collecting user input from request. 1. Emphasize using of nested properties, using business objects as nested properties, using dynaforms holding business objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
