My biggest problem with this is that it basically eliminates any advantage to using velocity as far as ease of use is concerned. One of the main reasons I prefer velocity over JSP is that the syntax is more natural, especially for things like iterations. Requiring two extra lines makes the whole thing ugly, unintuitive, and increases the possibility of errors (what if you forget to pop the item off of the stack? The possibility of subtle, hard to find errors over a large code base is definitely there). Also, the value stack should be used when it is necessary to be used. Passing a variable to a tag via a velocity directive doesn't seem to me like it needs to get the stack involved. You have a velocity approach the moment you start to use velocity as your templating language. The stack is a utility object that is available to your pages, and is obviously a core part of the framework, but if it doesn't need to get involved, it shouldn't.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Lamuette Sent: Tuesday, November 18, 2003 1:06 AM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Param directive Here is the different point of view. I personnaly think the push/pop actions are NOT a hack. Either you have a WW2 approach or a Velocity one. I think we are in the first one, that makes all the difference, the stack is the main way to access data. If you need to pass reference objects without pushing on the stack, just use velocity macros, it works perfectly. And I'd like to point out that you can ALWAYS pass in any object references via ognl (stack.findValue), you have just to push the needed object, in your example : #foreach( $number in $person.phoneNumbers ) $stack.push($number) #bodytag(Component "template=numberDisplay.vm") #param("phoneNumber" "top") -> actually, (behavior in the previous release) you pass $stack.findValue("top") = $number. #end #set ($trash = $stack.pop()) #end In your component numberDisplay.vm, you can use $parameters.phoneNumber as a direct reference : ---------------------------------------------------------------------------- ------------------ #set($phoneNumer = $parameters.phoneNumber ) $phoneNumber.number $phoneNumber.areaCode ... My conclusion would be : 1/ All you found impossible (pass in object references) is actually possible via the stack. 2/ I think it's important to keep the WebWork philosophy (data in a stack) to not break the consistency. 3/ Keep in mind, accessing the stack relies on ognl which is very very powerfull (projection for instance). I hope I convince you to keep as a standard the data access via the stack. Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Drew McAuliffe Envoye : mardi 18 novembre 2003 00:15 A : [EMAIL PROTECTED] Objet : 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
