Re: A WM brain bender: The solution

Mike Weerdenburg wrote:

>Hello Marc and others,
>
>I would't like to see the following solution:
>
>#eval <Macro or String> [using { ... }]
>
>Is precisely what I want, it does the same trick as my Directive...
>  
>
I'm in Calif for SD West this week, but I should be able to make this 
change when I get back next week.

>Personally I would't like to see an option 'to $myOutput'
>
>So you would get: 
>#eval <Macro or String> [using { ... }] [to $myOutput]
>  
>
I don't think the "to $myOutput" is necessary; just use #setblock, e.g.,

  #setblock $myOutput { #eval $myStringTemplate }

>Can somebody !please! pick this 'solution' up?
>
>PS. 'using { ... }' must be optional, just as the 'to $myOutput'
>  
>
It already is.

Also, we could probably add an option like "inline" to have #eval use 
the current context.  Is this worthwhile?

Keats

>Greetings,
>Mike Weerdenburg
>
>-----Oorspronkelijk bericht-----
>Van: [email protected]
>[mailto:[email protected]] Namens Marc Palmer
>Verzonden: maandag 14 maart 2005 10:54
>Aan: [email protected]
>Onderwerp: Re: [WebMacro-user] A WM brain bender: The solution
>
>Mike Weerdenburg wrote:
>  
>
>>Hello everybody,
>>
>> 
>>
>>I use this 'evalStringTemplate' to convert text from a database (or other
>>source) to a 'parsed' text.
>>
>>    
>>
>
>I quite like your solution, certainly more than the #include as template 
>"string:xxxxx" mechanism I am using currently (hey, it works). However 
>the #include with configurable "protocols" is a brilliant mechanism and 
>very useful indeed.
>
>To address Marcel's complaint about the "abuse" of #include, multiple 
>databases containing templates would be configured using multiple 
>delegating template loader definitions, such as db1: and db2:
>
>However a DB-based template loader could work like the URL template 
>loading, and include the server and database name etc, with a JDBC URL. 
>There's no reason not to do this as far as I can see, otherwise you're 
>saying that http:// or https:// is a bad machanism.
>
>
>Back to the main issue... the problem with #evalStringTemplate is 
>name-spacing of variables. #eval does this nicely, although an option to 
>-not- create a new context would be nice.
>
>I think this feature should be built into #eval really, as Keats suggested:
>
>#eval <macro or string> [using { ... }]
>
>Personally, unless "using" is optional at the moment (can't check, 
>webmacro.org seems down again), I think if "using" is omitted it should 
>just use the current page context.
>
>Also, you could mitigate some of the error trapping problems of allowing 
>strings to eval by requiring "as string" for String evaluations:
>
>#eval <Macro | "as string" String> [using { ... }] 
>
>What do you guys think?
>
>Cheers
>
>
>  
>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click