[Struts Wiki] Trivial Update of "SAF1RoughSpots" by TedHusted

[Apache Wiki <wi...@apache.org>]

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 TedHusted:
http://wiki.apache.org/struts/SAF1RoughSpots

The comment on the change is:
/s/SAF/Struts (only)

------------------------------------------------------------------------------
- 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.
+ Struts 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 Struts 1 makes sense even after release of Struts 2. This page tries to summarize major issues with Struts 1 and possibilities to fix them or provide better workarounds.
  
  == Code Issues ==
  
-   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. '''I/O conversion'''  [MichaelJ] The suckiest part of Struts1 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; 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.
+   1. '''Struts 1 lifecycle'''  [MichaelJ] The lifecycle of Struts 1 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.
  
    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?
  
    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.
+     * [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 Struts 1 be evolutionary and take backwards-compatibility into consideration in a big way.  I think if you want revolution you go for Struts 2 (a minor revolution in that it's theoretically still compatible) or Shale.
  
    1. '''Form attribute'''  [MichaelJ] Add "form" attribute with the same meaning as "name" attribute; deprecate "name".
      * [FrankZ] +0.  Same comment as the above point.
@@ -88, +88 @@

  
  == Best Practices Issues ==
  
-   1. '''Focus on best and most common approaches'''  [MichaelJ] 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. '''Focus on best and most common approaches'''  [MichaelJ] Instead of having several ways to do things, Struts 1 should focus on one best and the most common way, even if it involves a couple more lines of code. Less is more.
  
-   1. '''Webresource-centered approach'''  [MichaelJ] Up until now SAF1 best practices center around a View, usually a JSP page. Instead, best practices should teach the webresource-centered approach.
+   1. '''Webresource-centered approach'''  [MichaelJ] Up until now Struts 1 best practices center around a View, usually a JSP page. Instead, best practices should teach the webresource-centered approach.
      * [FrankZ] Speaking for myself, I would need to see a good definition of this approach before I was +/- on it.  I have never seen a clear explanation that made me say "oh yeah, I see, that's better!"
      * [MichaelJ] Check out DataEntryForm. Well, it uses dispatching action and session-scoped form, but if you look at it from 10000 ft, it gives the idea of what web resource is about. Basically, it is one-two actions, one form and one or more JSPs. A resource does NEVER forwards to a JSP page that does not belong to the resource. In the best case we can have nice and simple 1:M relationship between action and JSPs.
  
@@ -101, +101 @@

      * [FrankZ] -1.  Saying there is "nothing wrong" with it, I do not believe is true.  Speaking as someone who works all day in a large distributed enterprise environment, I am very well aware of the pitfalls of storing things in session and in letting session get too big.  I'm not saying I never store anything in session, of course I do! :)  But I think people need to know the positives and negatives of doing so and decide what is appropriate in a given use case rather than being told this or that is a "best practice".
      * [MichaelJ] My original wording did not have "preference". What I am saying is that session-scoped forms should not be a taboo, and their benefits (as well as pitfalls) should be clearly explained.
  
-   1. '''Building stateful components'''  [MichaelJ] It is possible to build stateful and independent web components with SAF1. Best practices should teach how to do that.
+   1. '''Building stateful components'''  [MichaelJ] It is possible to build stateful and independent web components with Struts 1. Best practices should teach how to do that.
  
    1. '''!ActionForm as true I/O buffer'''  [MichaelJ] !ActionForm should be used as I/O buffer instead of simply collecting user input from request.
      * [FrankZ] Could you explain this further?  I'm not at all clear on what you mean.