On 11/24/01 6:22 PM, "Donnie Hale" <[EMAIL PROTECTED]> wrote:
> Thanks for responding - I guess I should have given an example. > > What I was envisioning would define macros like: > > #macro(form $name="required", > $action="required", > $enctype="some-default-value", > ...) > ## macro code > ## error if $name or $action referenced but not passed ??? > #end > Hm. This is kinda cool. I can see where we have to change the code to support this - not bad.... Then the proxy will pass in the default values on invocation if they aren't in the actual VM invocation. The only downside is that this could be damn confusing for people to read if they aren't familiar with the idea. > All of the possible parameters would be in the macro definition, those that > aren't required having some default value, possibly empty. You can look at > the Struts taglib docs to see what we'd be shooting for. (BTW, a macro > definition would be more natural if it was "#macro name( ..." rather than > "#macro (name ..."; just my opinion, though.) Nah :) it's a directive, like any other : #<directive>( [ arg ] * ) > Invoking it would be: > > #form($name="uploadForm", $action="/upload.do", > $enctype="multipart/form-data") Well, hold on for a sec. Since the #macro() definition has positional parameters, then I think that the way to invoke is #form( "uploadForm" "/upload.do" ) (in the case where you want the default enctype...) Another approach is to add an argument entity 'pair' where something like #form( $name="uploadForm" ) Simply stuffs "uploadForm" into the context behind the key 'name' for that invocation of the VM and there are no real args. This seems to need a bit of fleshing out - how to you handle when someone doesn't send in a required value? It can be enforced with positional params, but not sure with 'pair' parameters... > This is a little bit off the top of my head, but I think I'm explaining > myself OK. There may be other ways to do it, but that's what was in my mind. Pretty good... > Donnie > > -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] > Sent: Saturday, November 24, 2001 5:37 PM > To: Velocity Developer's List > Subject: Re: #macro functionality > > > On 11/24/01 5:02 PM, "Donnie Hale" <[EMAIL PROTECTED]> wrote: > >> I'm throwing this question out there now as I'm playing around with the >> Struts-Velocity integration. One person responded that they'd like to see > a >> Struts html:form-like macro library in Velocity. I think that would be >> useful as well, especially if we want Struts/Velocity to have some of the >> Struts/JSP capabilities, such as auto-populating of forms based on the >> current values of an ActionForm in the request/session context. > > Cool beans. I was talking to a Velocity user at a client the other day, and > he said that it would be nice to have little HTML-generating Velocimacros, > so while your doing the form one... :) > > >> >> As it stands right now, parameters to Velocity macros are position-based. >> The docs say that the same number of args must be passed as are specified > in >> the macro definition. Unfortunately, that makes it difficult to directly >> mimic, for example, a Struts <html:form ... > tag. Typically, only a > couple >> of parameters are passed. However, there are a bunch of parameters that > can >> be passed. In the case of Struts, the parameters are name-value pairs. >> >> While there are some less-than-perfect ways to work around this or to >> slightly enhance the position-based macros, the best solution (I think) >> would be to develop a name-value macro capability. Would that violate any >> fundamental philosophical tenet of Velocity? Would it make more sense to >> make it a separate directive, e.g. #nvmacro (lousy name, I know), or to >> extend the current #macro directive to work either way? > > Hm. Like what do you imagine to do? > > I can see some workarounds, such as : > > #foo( [$a, $b, $c] [$x,$y, $z] ) > > Or populating a map and passing that in... > > #set($foo.name = $value) > #set($foo.anothername = $anothervalue ) > > > -- > Geir Magnusson Jr. [EMAIL PROTECTED] > System and Software Consulting > Be a giant. Take giant steps. Do giant things... > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
