[Struts Wiki] Update of "SAF1RoughSpots" by MichaelJouravlev

[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 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org