From: Keats K. <ke...@xa...> - 2005-08-10 01:22:54
|
Hey Marc. I on vacation (with a very poor dial-up connection from the Delaware shore), but I did manage to look at this a bit. It's not actually a bug, although it certainly a head-scratcher. The issue is that the arguments to #eval are evaluated before the macro (templet) whose context they are being added too. Since your argument to $outerTemplet "renderTemplet" is a templet, and a templet is a Macro, WM attempts to evaluate it -- in the current context -- before passing it to the $outerTemplet. Since there is no variable $value defined in the current context, you get an error. The messed up error message is another issue. It's a bit better if you use the CrankyEEH, but still a bit screwy. I'll put this on my list to look at one of these days. I'm not sure what the best solution is. My first thought is to use #setblock to define your templet argument as a plain string, and then convert it to a templet within the outerTemplet or something. I may play around with this and see if it works. Good luck. Keats Marc Palmer wrote: >Hi, > >I've hit upon what I believe is an obscure bug in #eval/#templet in 2.0 RC1. > >I'm finding it with my JSP taglib but I don't believe it is specific to >the taglib, it smells more like a problem with #templet/eval. Of course a >unit test will prove this so that will naturally be my next course of >action. However I can't commit to WM from my workplace. > >...evaluating this template: > ><html> ><body> > >#templet $render > >Value is: $value > >#end > >#templet $outerTemplet > > #set $value = "Hello!" > #eval $rendertemplet using { > "value" : $value > } > >#end > >#eval $outerTemplet using { > "rendertemplet" : $render >} > ></body> ></html> > > >...the intention/expectation is that this will simply output: > > ><html> ><body> > >Value is: Hello! > ></body> ></html> > > >...but, rather weirdly, you get this: > > ><html> ><body> > >Value is: <!-- Attempted to write an undefined variable: Hello! at >render:4.11 --> > ></body> ></html> > >Notice that it says undefined variable "Hello!" - but that is the value of >the variable! It's like it's trying to recursively evaluate it. > >Keats - any thoughts? > >I will try to dig into the source and write a unit test for this, but I >wanted to flag it in case I'm being stupid. > >Also, there seems to be an error handling bug. If your innermost templet >references a non-existent variable, you get something like: > >Value is: <!-- Attempted to write an undefined variable: <!-- Attempted to >write an undefined variable: $iknowthisdoesntexistvalue at unknown:2.58 >--> at render:4.11 --> > > >...notice that this has two error messages and unbalanced "-->" so you get >some nasty output in the page and interestingly two sources - unknown and >render. Also note that it gets the error variable name right in this case, >but in the first problem I talked about it uses the -value- of the >variable as the "unknown" variable name. > >Very confusing! > >Cheers > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >Webmacro-user mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-user > > > |