<disclaimer>i haven't been developing with Struts in many months and
have forgotten much and not learned much that is new. so i don't
think i totally get what is going on here.</disclaimer> but a few
comments follow inline...
On Fri, 4 Mar 2005 01:59:35 -0000, Marin� A. J�nsson
<[EMAIL PROTECTED]> wrote:
> As I've been investigating the inner workings of the JavascriptValidatorTag
> in Struts v1.2 - how it interacts with the FormTag, the ValidatorPlugin and
> different types of ValidatorForms - I've come to realize that the current
> versions of the FormTool and the ValidatorTool lack some vital
> functionality.
>
> At present the FormTool is mainly a convenience tool to access the form bean
> associated with the current action.
> The fact is there should be no need to specify a form bean for an action
> that simply displays a form that's empty or that only contains the default
> values.
> The Struts FormTag OTOH uses it's action-attribute (action-mapping path) to
> find an ActionConfig from which it retrieves the form name. It then creates
> an instance of the form bean (if need be) and puts it in the scope and under
> the name specified in said ActionConfig.
> This feature i.e. allows us to have one struts action display multiple
> different forms that all have the appropriate form beans instantiated and
> ready to use.
>
> At present the ValidatorTool, like the FormTool, uses the form bean
> associated with the current action to render the dynamic javascript. This
> is not how it should work for the reason stated above - it should not
> require a form to be associated with the action that displays the form. On
> the contrary the getDynamicJavascript() method of the ValidatorTool should
> always require a formName parameter that matches the form name of
> _submitting action_ (the ValidatorTool takes care of changing the formName
> in the case of ValidatorActionForms or DynaValidatorActionForms). The
> ValidatorTool then relies on the FormTool having instantiated said form bean
> in scope and rendered the correct name-attribute for the html form.
>
> AFAICS there is no elegant solution to this problem using tools;
>
> <form name="$form.setAction('someAction')"
> action="$link.setAction('someAction')"> ... </form>
certainly not ideal, but not terrible IMHO.
> ... since setAction() for both FormTool and LinkTool in this case need
> matching parameters (the action path) - this would go down in my book as a
> Bad Solution. The setAction(String) method of the FormTool finds the
> relevant ActionConfig and instantiates the relevant form bean appropriately.
> It then return the name of the form as specified in the ActionConfig.
>
> An alternative would be to let the FormTool render the whole html form-tag
> ... but that would go against the Velocity Philosophy(tm) - and for good
> reason!.
yeah, let's definitely not do that.
> IMHO this would be a prime candidate for a standard global macro lib ;-)
which is something we've long talked about and halfheartedly began on
the wiki, but it's never seemed to garner sufficient interest or
momentum.
> #renderHtmlFormTag('someAction')
>
> Thoughts?
1) why not just #formTag('fooAction')?
2) would we need to support other attributes in that tag?
2b) if so, how would it be done?
3) how would we distribute the macro library(ies)?
4) should we ping [EMAIL PROTECTED] about this for their thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
