What we need to solve all this is: * two #param directives (one which evaluates, one which doesn't) * two #property directives (one which escapes, one which doesn't)
With the above to things, velocity templates would be able to do all the things JSPs can. In fact, the two #param directives is something that JSP doesn't support, but that's because JSP doesn't have it's own EL, whereas Velocity does and so taking advantage of it is a good idea. Would that work for everyone? Got an suggestions for the names of the directives? -Pat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew McAuliffe Sent: Monday, November 17, 2003 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As I said in another reply, the biggest problem is that you can't use an object variable in velocity, since it always gets converted to a string first. If I have a collection of model objects, and want to call a component tag with them in an iteration through the collection, I can't, because a call to the component tag with the former behavior can only pass in the reference to the model object, converted to a string. For example, for a model object like PhoneNumber -number -area code -number type the new behavior will allow for syntax like this: #foreach ($number in $person.phoneNumbers) #bodytag (Component "template=numberDisplay.vm") #param("phoneNumber" $number) #end #end If you always call "stack.findValue()" behind the scenes, there's no way the value stack can know the value of a velocity variable unless you manually push it onto the stack, then pop it off. That's a hack to me, and is also inconsistent with the way every other velocity directive or macro works (directives and macros allow object references to be passed in, not just strings). The new approach still allows for strings evaluation, but it forces a manual call to $stack.findValue(). I think that's a fair tradeoff. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Monday, November 17, 2003 9:16 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive As far as I am concerned this approach is not the correct one ! I explain my point of view with an example : With the latest XWork+WW2 cvs snapshot, you can write a select tag both ways : 1/ #tag(Select "name='nameValue'" ...) -> in this case, the parameter with key=name and value=stack.findValue("nameValue") is added to the parameters map. is equivalent to #bodytag(Select ) #param("name" "nameValue") -> in this case, the parameter with key=name and value=nameValue is added to the parameters map. #end 2/ #tag(Select "name=nameValue" ...) is equivalent to #bodytag(Select ) #param("name" "$stack.findValue($nameValue)") #end -------- You can admit it's not very coherent, you have two different behaviors according to what you use (extra tags or external params) whereas the same handling behind is used (extra tags are converted as parameters). Can you explain to me what are your arguments ? Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK >I believe some people asked for it to be that way as it's more natural >for a Velocity context... I may be wrong though.. >> -----Original Message----- >> From: Fred Lamuette [mailto:[EMAIL PROTECTED] >> Sent: Monday, November 17, 2003 9:34 AM >> To: [EMAIL PROTECTED] >> Subject: [OS-webwork] Param directive >> >> >> Having the latest XWork+WW2 cvs snapshot, I can notice a behavior >> change for the param directive. >> >> Before >> #param("paramName" "paramValue") -> store in the parameters list, >> the value >> OgnlValueStack.findValue(paramValue) >> From now >> #param("paramName" "paramValue") -> store in the parameters list, >> the value paramValue >> >> Why did you change the previous behavior ? >> >> Richard HALLIER >> Chef de projet >> [EMAIL PROTECTED] >> 01.40.12.41.52 >> www.uniclick.org >> UNICLICK >> >> >> >> >> ------------------------------------------------------- >> This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, >> easy and secure way to access your computer from any Web browser or >> wireless device. Click here to Try it Free! >> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/ >g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
