Hi Claude, I'm not sure exactly what the question is, but I think I've had similar thoughts - I did toy with the idea of generic action support (i.e. in the LinkTool), and also to introduce an interface that the more specialized tools would implement (like StrutsLinkTool and SecureLinkTool) when I was checking out Spring :-)
It's not a big issue for me though. cheers, Marin� -----Original Message----- From: Claude Brisson [mailto:[EMAIL PROTECTED] Sent: 19. mars 2005 02:13 To: Nathan Bubna Cc: Velocity Developers List Subject: Re: FormTool and ValidatorTool - vital functionality missing ... somehow i'd like to say something in this debate, but i don't know struts, and i still haven't anything to propose to ease the html writing of a form. <advertisement> in velosurf on the side of the commit page i use things like $object.update($query) or $db.entity.insert($query) or (soon) $db.entity.refine($query). so in the form i expect (by default) field names to correspond to entity fields (which are (by default...) database fields). it's also about forms, but it looks quite orthogonal to your debate... well, let's come back to our sheeps; </advertisement> just a question... what can be done around the concept of "action" that would have a sense without struts? especially, considering that an action is just, somehow, nothing more than a string, i.e. how we name it, is it a natural behaviour to have to use struts to use actions, and should it be the policy of the velocity-tools? -- Claude On Mon, 2005-03-07 at 16:54 -0800, Nathan Bubna wrote: > On Sat, 5 Mar 2005 15:56:01 -0000, Marin� A. J�nsson > <[EMAIL PROTECTED]> wrote: > > Well, if we go with a #formTag() macro (if not as a part of a larger > > macro lib - then at least as a demonstration of good practices in > > the example app) then we need named parameters IMO since the html > > form tag can take many attributes and most of them should be optional i.e.: > > named attributes could come in handy... > > > (map syntax) > > #formTag( { 'action' : 'someAction', 'onSubmit' : 'return > > validateEmailForm(this)' } ) > > this would work with Velocity 1.5, but it isn't released and i'm not > willing to depend on an unreleased version. > > > (better syntax) > > #formTag( $action = 'someAction', $onSubmit = 'return > > validateEmailForm(this)' ) > > i currently have trouble fathoming this feature being added to > Velocity before a 2.0 is developed. for now, we'll have to do the > less obvious: > > #formTag( 'someAction' 'return validateEmailForm(this)' ) > > type of thing. and in case of optional attributes, we'll just > recommend passing $NULL for now. (#formTag( 'someAction' $NULL )) > > and i think, given that including standardized macro libraries is a > rather significant new feature, i'm thinking that we should hold off > on them until after we push out a 1.2 release. let's just get the > Struts tools up to speed, include the macro(s) in the example apps and > document them somewhere (not sure where offhand). that'll give us > some time to figure out how we want to document the macros and include > them in the distribution. that is, of course, unless someone steps up > with a tested patch for all that. (takers, anyone?) > > > I don't think there's need to bug the Struts developers with this > > issue as this doesn't really have anything to do with Struts Core - > > it's about three > > things: > > > > 1) Instantiate form-beans in the view using the name of the > > action-mapping path for each form. > > This is simply an enhancement that makes it largely unnecessary to > > specify a form for an action that displays a form - and also makes > > it possible to have multiple form-beans instantiated for a single action (page). > > > > 2) Generate the html form-name dynamically using the name of the > > action-mapping path for each form. > > At present this would be an enhancement for ValidatorTool users as > > the generated javascript needs the html form to have the correct > > name with respect to the action it submits to. However the user > > still needs to fill in the onSubmit attribute by hand, which also > > needs a matching name, so this is a little > > > > 3) Specifying the validation form-name in the getDynamicJavascript() > > method of the ValidatorTool. > > For cases where there are multiple forms in a page, or a form has > > not been associated with the action that displays the page (see item 1 above). > > > > After dwelling on this for a bit I think the following solution > > would be better than the one I mentioned in my previous post: > > > > <form name="$validator.getFormName('someAction')" > > action="$link.setFormAction('someAction') > > onSubmit="$validator.getFormOnSubmit('someAction')"> > > > > ... reason being the "name" and "onSubmit" attributes are only > > really required if the ValidatorTool is used (which is probably not > > that often) so the ValidatorTool should handle them. The LinkTool > > OTOH could implement a > > setFormAction(String) method, for use with form-action links, that > > would instantiate the relevant form-bean if necessary. > > > > This would also make for some slick global macros: > > > > #formTag('someAction') > > > > or (in case of ValidatorTool being in use) > > > > #validatorFormTag('someAction') > > this all sounds good to me! > > > cheers, > > Marin� > > > > btw. should we be pushing for Struts - ViewContext to be introduced > > in the core? I see they have it slated for v1.3 and they've already > > thrown in the ActionContext - but the ViewContext bean is nowhere to be seen yet. > > i'm not sure. i have seen some of the threads on this, but haven't > had time to follow them closely. it seems we have Ted Husted > advocating for it (or something like it), but i'm not seeing anyone > step up with the code for it. last i saw though, Ted was suggesting > they essentially mimic/adapt/copy our multiple-tool interface (if not > the very code), instead of a single all-powerful bean. i haven't > really had time to look at it or the possibilities here though. so, i > guess my answer is--if you want to push for it and/or throw some code > at them, then go for it and we'll see what happens! > > > -----Original Message----- > > From: Nathan Bubna [mailto:[EMAIL PROTECTED] > > Sent: 4. mars 2005 22:14 > > To: Velocity Developers List > > Subject: Re: FormTool and ValidatorTool - vital functionality missing ... > > > > <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] > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
