> Cool! Put all the boxes away? :-) I'm typing on my laptop - on my lap - if that gives any indication of how many boxes are put away. ;-)
> BTW, I want to mention that I really like the diagram on the > overview page of the VelocityStruts documentation. Great job! Thanks. :-) > -0 on Nathan's proposal. Ok, I understand now and also agree that both formal/informal should be documented. Perhaps the simple form should be more prominent in a Designer guide, with both forms in a Developer guide. > two parameters: This is not an exotic case but quite a common thing. <soapbox>I've seen a lot of funky template stuff, I'm not going to lecture, but geez it's so much easier to put the heavy lifting in the backend. But hey, that's just my goofy need to keep things simple. Do whatever makes you happy. :-P </soapbox> > We could do this: Instead of showing both notations in most > examples, we could just mention this in one place, for > example in an additional section in the user guide. +1 > Yes, I don't see are reason either and I don't remember why I > originally added it. Ha. Looks like Nathan likes it so he can lazily write $form.bean.* instead of looking up the form name in the struts-config.xml <grin> > But, I just noticed, that nowwhere else the form bean is > mentioned. I suggest that the form bean is mentioned in the > section "Access to Struts Framework Resources" of the users guide. +1 > Do you see many things that are more aimed at developers? Well, specifically, the FormTool docs talk about HTTP Requests, versions, JAR, Classes, Toolbox config, methods with return types. http://crufty.happysearch.com/velocity/tools/struts/docs/FormTool.html (BTW: getTokenName says it returns 'int' which is wrong, eh?) I'm thinking Designers have attention spans even shorter than gnats and Managers, so maybe basic HOWTO info on the main Struts Tools page would be good? Could describe how to use the Form/Msg/Error tags, and how to handle transaction tokens - which are wildly different from the Struts Taglib forms, right? Example: ---------------------------------- The Struts <html:form> tag automatically provides a feature which can help prevent users from accidentally submitting a form twice with the same data. This feature, called "transaction tokens", is turned on by the developer in the application configuration and handled by the tag. When the tag is converted to HTML, a <form> is created and a hidden field is placed into the form with a one-time-use token. The token will look something like this: <input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="224e7d7071ece4280bff018afcd41ec"> VelocityStruts only uses standard <form> tags, but this means that if Transaction Tokens are being used in the application, the template must manually include the hidden field. Fear not! This is easy, simply add the following hidden field to the form. <input type="hidden" name="$form.TokenName" value="$form.TokenValue"> So if the page has a form called "WidgetEditForm", the Velocity template would look like this: <form name="$WidgetEditForm.name" action="$WidgetEditForm.action" method="POST"> <input type="hidden" name="$form.TokenName" value="$form.TokenValue"> <!-- other input fields here --> </form> ----------------------------------- That brings up some questions. 1) Can we add getTokenValue() as an alias for getToken() to make the naming consistent and pretty? 2) Does $WidgetEditForm.Name even exist? Should it? Can it? 3) Why would there be $form.TokenName and $WidgetEditForm.username versus just having $form.* or $WidgetEditForm.*? What is more consistent with the Struts paradigm? 3) What would the action really look like? $link.foo $WidgetEditForm.Action ? (I don't know. All of the examples are hard-coded, and I'm not clear form the various docs.) Cheers, Timo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
