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 FrankZammetti: http://wiki.apache.org/struts/SAF1RoughSpots ------------------------------------------------------------------------------ == 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. '''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. 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, 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. - 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. '''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. 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. '''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. - 1. Add "form" attribute with the same meaning as "name" attribute; deprecate "name". + 1. '''Form attribute''' [MichaelJ] Add "form" attribute with the same meaning as "name" attribute; deprecate "name". + * [FrankZ] +0. Same comment as the above point. - 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. '''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? - 1. 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. Improve Tiles to support real components, that can be fully independent of composite page, can process user input, and can render themselves. + 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. + + 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 being separate as a rough spot. + + 1. '''Built-in AJAX support''' [FrankZ] I am not entirely sure what the best form for this is, although I believe the !AjaxTags paradigm still has a great deal of merit. In any case, in today's world, not offering some degree of AJAX out of the box is probably a rough spot for many. + + 1. '''Custom attributes on tags''' [FrankZ] All Struts tags that render HTML should allow for arbitrary attributes. I again propose a "specCompliant" attribute on the <html:html> tag. When true, no arbitrary attributes are allowed (this would be the default if the attribute is not present). If false, any attribute can be added. This has been a hassle for me a couple of times where I wanted to store some custom information on a tag for client-side purposes. + + 1. '''The ability to switch off auto-form population''' [FrankZ] The idea here is that Struts would still instantiate an !ActionForm and call reset(), but that's it. This can be useful if you want to use an !ActionForm only as an output object, but want to handle input manually. This came up for me converting a non-Struts app to Struts, where there was no notion of an !ActionForm in the previous framework. + + 1. '''Built-in dependency injection''' [FrankZ] This should be modeled after what is offered in JSF. If we took the code from the !DependencyFilter in Java Web Parts, added in true injection (shouldn't be a terribly big deal), I believe we would have even better capabilities than in JSF. Spring is of course still out there for those that need/want more! This may not be so much a rough spot as just a fairly low-hanging piece of fruit (because most of the work is already done by virtue of leveraging !DependencyFilter) that I think people would appreciate having. + + 1. '''!ThreadLocal !ActionContext''' [FrankZ] Yes, I think this is one place we should flat-out rip off Webwork :) Backwards-compatibility would have to be considered, but I'd like Actions to have to deal with a single object, and for that object to be accessible via the !ThreadLocal mechanism. This should also open the door for POJO Actions. + + 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. + + 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. + + 1. '''MAYBE roll StrutsWS into Struts''' [FrankZ] Heck, I'm not even sure *I* would +1 this idea! Might be worth considering at least. + == 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. '''Chain documentation''' [MichaelJ] 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 are confusing''' [MichaelJ] 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. Also, 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. 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. + 1. '''Visual representation of tags that render widgets''' [MichaelJ] 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. '''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. 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 SAF1 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!" - 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. '''Dispatch-type actions should be more front-and-center''' [MichaelJ] 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. + * [FrankZ] As an oft-stated opponent, GENERALLY, of Dispatch-type Actions, I wouldn't be thrilled with this being sold as a "best practice". I would have no problem with it being described in more detail and the pluses and minuses stated for people to be able to make a more informed decision either way. - 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. '''Preference for session-scoped !ActionForms''' [MichaelJ] 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. + * [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". - 1. 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 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. '''!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. - 1. Emphasize using of nested properties, using business objects as nested properties, using dynaforms holding business objects. + 1. '''Use of nested properties''' [MichaelJ] 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]
