From: <kea...@na...> - 2003-03-28 21:09:41
|
Marc, I think I have finally tracked this one down. Line 781 in PropertyOperatorCache.java, in the PropertyOperatorCache.PropertyOperator.setProperty() method: parent = getProperty(context, instance, names, pos, pos); should be: parent = getProperty(context, instance, names, pos, pos + 1); Don't ask me to explain this (I can't). I'm guessing that this bug has been in the code forever. I suppose not many people have tried to use the binary mutator syntax, i.e., #set $obj.Prop.Key = "value" for $obj.setProp("Key", "value") Anyway, I'll try to write some unit tests for this and make sure it doesn't break anything before committing the change. Keats > -----Original Message----- > From: Marc Palmer [mailto:ma...@an...] > Sent: Wednesday, March 19, 2003 10:19 PM > To: web...@li... > Subject: [Webmacro-devel] Binary accessor "set" problem > > > > Hi all, > > I'm working against WM 1.1 final source, developing this WM > "run and go" > webapp currently codenamed "WebMacro Ignition". > > I've come across a funny. I can't -set-a property that has a binary > accessor. A glance over the WM source for this > (PropertyOperatorCache) has > not enlightened me and the laptop I'm using is just toooo slow for > interactive debug against Tomcat at the mo. > > Anyway, I'm getting this error in my template: > > Ignition encountered an error while executing a template: > FileTemplate:C:\Program Files\Apache Group\Tomcat > 4.1\webapps\ignition\WEB- > INF\classes\index.wm: > org.webmacro.PropertyException$NoSuchPropertyException: No > public property > Parameters on variable $action of class > org.webmacro.ignition.api.action.ActionParams at C:\Program > Files\Apache > Group\Tomcat 4.1\webapps\ignition\WEB-INF\classes\index.wm:17.2 > > The part of the template causing offence is: > > #set $action.Parameters.Template = "itworked.wm" > > ...and $action is of type ActionParams which has the > following methods: > > public void setParameters(String key, Object value) > > public String getParameters(String key) > > ... I know binary accessor "get" works as have used it > elsewhere but this > is the first time I've tried to "set" using it. > > Also, while binary accessor is certainly a convenience I'm > starting to > wonder whether it is a bit of an abomination. i.e. you cannot > rewrite my > previous bit of WM script as this: > > #set $params = $action.Parameters > #set $params.Template = "itworked.wm" > > Well... you could if there was a "proxy" created to represent > the virtual > field "Parameters" internally in WM that handled this but it would be > pretty nasty. Granted many web developers would not think of > doing this, > but it disturbs me that we can get ourselves into an > inconsistent situation > by using binary accessors. I think I may stop using them > having realised > this. > > $0.02 > <snip> |
From: Keats <ke...@su...> - 2003-04-29 05:46:54
|
An update on a cold thread ... In playing around with the XmlDemo, I thought I had re-encountered this elusive bug. But then I realized the reason ... I tried to do something like: #set $jdomElement.AttributeValue.Thinga = "mabob" and I got a NullPointerException. After looking at the PropertyOperator code, the problem was suddenly obvious. WM will always look for a "unary accessor" before a "binary mutator". In this case, it finds a getAttribute() method, which happens to return null, hence the NPE. Perhaps this is the problem Marc was seeing? Anyway, it's not clear to me how to "fix" this. We could catch the exception and then look for a binary mutator before throwing. But this could result in inconsistent behavior. For example, in the above case, if the attribute "Thinga" did exist, you would get an error, since you can't assign a String to a JDOM Attribute field. Alternatively, we could always check for the "binary mutator" first. This makes some sense, but there are issues here as well. It would break backwards compatability for anyone relying on the unary-first behavior. This probably wouldn't effect many templates, but if it did it could be a puzzling error. It also might have performance implications. My feeling is that we should just document the behavior and live with it. But if anyone feels strongly that this is bad, I'm open to persuasion. Keats |
From: Lane S. <la...@op...> - 2003-04-29 07:23:28
|
Keats wrote: > An update on a cold thread ... > > In playing around with the XmlDemo, I thought I had re-encountered > this elusive bug. But then I realized the reason ... > > I tried to do something like: > > #set $jdomElement.AttributeValue.Thinga = "mabob" > > and I got a NullPointerException. After looking at the > PropertyOperator code, the problem was suddenly obvious. WM will > always look for a "unary accessor" before a "binary mutator". In this > case, it finds a getAttribute() method, which happens to return null, > hence the NPE. did you mean getAttributeValue() and not getAttribute() relative to your code? > > > Perhaps this is the problem Marc was seeing? > > Anyway, it's not clear to me how to "fix" this. > > We could catch the exception and then look for a binary mutator before > throwing. But this could result in inconsistent behavior. For > example, in the above case, if the attribute "Thinga" did exist, you > would get an error, since you can't assign a String to a JDOM > Attribute field. > > Alternatively, we could always check for the "binary mutator" first. > This makes some sense, but there are issues here as well. It would > break backwards compatability for anyone relying on the unary-first > behavior. This probably wouldn't effect many templates, but if it did > it could be a puzzling error. It also might have performance > implications. > > My feeling is that we should just document the behavior and live with > it. But if anyone feels strongly that this is bad, I'm open to > persuasion. > > Keats > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
From: Marc P. <ma...@an...> - 2003-04-29 10:01:51
|
On Tue, 29 Apr 2003 01:44:56 -0400, Keats <ke...@su...> wrote: > I tried to do something like: > > #set $jdomElement.AttributeValue.Thinga = "mabob" > > and I got a NullPointerException. After looking at the PropertyOperator > code, the problem was suddenly obvious. WM will always look for a "unary > accessor" before a "binary mutator". In this case, it finds a > getAttribute() method, which happens to return null, hence the NPE. > > Perhaps this is the problem Marc was seeing? I don't think so but my memory is fuzzy. My problem was with setting the value, and I don't usually override "setter" methods. I just could never get "set" to work on a binary accessor. However I did get this exact problem you mention yesterday when playing around with some stuff. In short I think that really we should probably look for the most "complex" getter/setter first and go back to unary set/get if nothing found, but this could be a lot more complicated than it sounds. i.e. it should work as you expect it! Keats and I have come unstuck with this and we "know what we're doing". Failing that, or in the interim at least, we should leave it as is but update the binary accessor docs on the site to say "Programmers implementing binary accessor methods should not override getter or setter methods of the same name" or something to that effect. Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
From: Keats <kea...@di...> - 2003-05-12 21:52:22
|
I have created a directive version of the TemplateTool called #templet. This lets you define a reusable "Templet" within your template that can be evaluated with different values in the context. (See the example script at the end of this message.) It seems to be working pretty well, but I'm still struggling to find an acceptable syntax for setting context values. Currently it works the same way as the $template tool, i.e., you can: 1) pass an array of values to eval(), which will be put in the context as $arg1, $arg2, etc: $templet.eval([$x, $y, $z]) 2) pass an array of values and an array of names to eval(), so the values will get put into the context as $name1, $name2, etc: $templet.eval([$x, $y, $z], ["name1", "name2", "name3"]) 3) pass a Map to eval() whose contents get copied into the templet context. (This requires you to have the Map already): #set $map.name1=$x #set $map.name2=$y #set $map.name3=$z $templet.eval($map) 4) put the values into the templet context directly prior to calling eval(): #set $templet.Context.name1=$x (or equivalently: #set $templet.Args.name1=$x) #set $templet.Context.name2=$y #set $templet.Context.name3=$z $templet.eval() None of the above options are particularly pretty. Perhaps a separate directive for invoking the templet would be better. E.g., #eval $templet #arg $name1=$x #arg $name2=$y #arg $name3=$z I haven't played with subdirectives, but I think I could do this. But I'm not sure this is much of an improvement. A built-in Map declaration syntax would help here. E.g., $templet.eval([name1=$x, name2=$y, name3=$z]) or to follow what I think is the new Velocity syntax: $templet.eval([{"name1" : $x} {"name2" : $y} {"name3" : $z}]) Since I don't see this coming anytime soon, how about a $map function: $map(["name1", $x, "name2", $y, "name3", $z]) and $templet.eval($map(["name1", $x, "name2", $y, "name3", $z])) A #properties directive would be kind of cool: #properties $props { name1: $x name2: $y name3: $z } This could just parse the block and stream it to a Properties.load(). Then you could say: $templet.eval($props) Or how about: #eval $templet using { name1: $x name2: $y name3: $z } Any input would be appreciated. Keats ==================================================== Sample Script: ==================================================== <h3>Example generating a bulleted list using \#templet</h3> #templet $ul { <ul> #foreach $item in $arg1 { <li>$item</li> } </ul> } $ul.eval([["item 1", "another item", "last but not least"]]) <h3>Another list example</h3> $ul.eval([["First", "Second", "Third"]], ["arg1"]) <h3>Yet another</h3> #set $ul.Context.arg1 = ["Larry", "Moe", "Curly"] $ul.eval() |
From: Eric B. R. <eb...@tc...> - 2003-05-13 05:34:41
|
<snip> > A built-in Map declaration syntax would help here. E.g., <snip> > Since I don't see this coming anytime soon, how about a $map function: Disclaimer: I only spent an hour and 15 minutes on this... I've just committed some highly experimental Map support into CVS. #set $map = { "key" => "value", "foo" => "bar" } $map.key $map.foo Along with all the variants such as a map of maps, an empty map (#set $foo = {}), and of course using $variables as keys and values. I haven't written test cases yet, but some quick-n-dirty standalone testing shows it works, PLUS all existing test cases still pass. woo hoo! We can tweak the syntax, but I *really* like having the curly braces around the map. Plus, I tried to make it work with square brackets but javacc got confused with lists, and I don't understand LOOKAHEAD yet. Right now it uses a java.util.HashMap as the backing store, but I'd like to somehow make this configurable via WebMacro.properties, so we can use any Map implementation. Maybe TreeMap or some custom CaseInsensitiveStringKeyMapThingie so $map.Key and $map.keY are the same thing. Who knows. But I think this is a good start. eric |
From: Keats <kea...@di...> - 2003-05-13 19:42:43
|
Eric, This is way cool! Personally I'd vote for colons, but I can live with the "=>" if there is some advantage to this. You rock. Keats ----- Original Message ----- From: "Eric B.Ridge" <eb...@tc...> To: "Keats" <ke...@ea...>; <web...@li...> Sent: Tuesday, May 13, 2003 1:34 AM Subject: Map Support (was: Re: [Webmacro-devel] #templet directive) > <snip> > > A built-in Map declaration syntax would help here. E.g., > <snip> > > Since I don't see this coming anytime soon, how about a $map function: > > Disclaimer: I only spent an hour and 15 minutes on this... > > I've just committed some highly experimental Map support into CVS. > > #set $map = { "key" => "value", "foo" => "bar" } > $map.key > $map.foo > > Along with all the variants such as a map of maps, an empty map (#set > $foo = {}), and of course using $variables as keys and values. > > I haven't written test cases yet, but some quick-n-dirty standalone > testing shows it works, PLUS all existing test cases still pass. woo > hoo! > > We can tweak the syntax, but I *really* like having the curly braces > around the map. Plus, I tried to make it work with square brackets but > javacc got confused with lists, and I don't understand LOOKAHEAD yet. > > Right now it uses a java.util.HashMap as the backing store, but I'd > like to somehow make this configurable via WebMacro.properties, so we > can use any Map implementation. Maybe TreeMap or some custom > CaseInsensitiveStringKeyMapThingie so $map.Key and $map.keY are the > same thing. > > Who knows. But I think this is a good start. > > eric > > |
From: Eric B. R. <eb...@tc...> - 2003-05-13 20:07:08
|
On Tuesday, May 13, 2003, at 03:42 PM, Keats wrote: > Eric, > > This is way cool! Personally I'd vote for colons, but I can live with > the > "=>" if there is some advantage to this. Colons works for me too. => is kinda tricky to type. I'll try to change it tonight. eric > You rock. > > Keats > ----- Original Message ----- > From: "Eric B.Ridge" <eb...@tc...> > To: "Keats" <ke...@ea...>; > <web...@li...> > Sent: Tuesday, May 13, 2003 1:34 AM > Subject: Map Support (was: Re: [Webmacro-devel] #templet directive) > > >> <snip> >>> A built-in Map declaration syntax would help here. E.g., >> <snip> >>> Since I don't see this coming anytime soon, how about a $map >>> function: >> >> Disclaimer: I only spent an hour and 15 minutes on this... >> >> I've just committed some highly experimental Map support into CVS. >> >> #set $map = { "key" => "value", "foo" => "bar" } >> $map.key >> $map.foo >> >> Along with all the variants such as a map of maps, an empty map (#set >> $foo = {}), and of course using $variables as keys and values. >> >> I haven't written test cases yet, but some quick-n-dirty standalone >> testing shows it works, PLUS all existing test cases still pass. woo >> hoo! >> >> We can tweak the syntax, but I *really* like having the curly braces >> around the map. Plus, I tried to make it work with square brackets >> but >> javacc got confused with lists, and I don't understand LOOKAHEAD yet. >> >> Right now it uses a java.util.HashMap as the backing store, but I'd >> like to somehow make this configurable via WebMacro.properties, so we >> can use any Map implementation. Maybe TreeMap or some custom >> CaseInsensitiveStringKeyMapThingie so $map.Key and $map.keY are the >> same thing. >> >> Who knows. But I think this is a good start. >> >> eric >> >> > |
From: <web...@st...> - 2003-05-26 13:23:50
|
On Tue, 13 May 2003, Keats wrote: | Eric, | | This is way cool! Personally I'd vote for colons, but I can live with the | "=>" if there is some advantage to this. | | You rock. | Alignment with Velocity? -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
From: Keats <kea...@di...> - 2003-05-27 14:18:53
|
RnJvbTogIkVuZHJlIFN0+GxzdmlrIiA8d2VibWFjcm9Ac3RvbHN2aWsuY29tPg0KPiBBbGlnbm1l bnQgd2l0aCBWZWxvY2l0eT8NCg0KRG9lcyBhbnlib2R5IGtub3cgd2hhdCBzeW50YXggVmVsb2Np dHkgZW5kZWQgdXAgd2l0aD8gIEkgZG9uJ3QgdGhpbmsgaXQncw0KbWFkZSBpdCBpbnRvIHRoZWly IGRvY3MgeWV0Lg0KDQpLZWF0cw0KDQoNCg== |
From: Eric B. R. <eb...@tc...> - 2003-05-27 14:22:24
|
On Tuesday, May 27, 2003, at 10:17 AM, Keats wrote: > From: "Endre St=F8lsvik" <web...@st...> >> Alignment with Velocity? > > Does anybody know what syntax Velocity ended up with? I don't think=20= > it's > made it into their docs yet. I just IM'd Geir about it. His response: "I don't recall". Plus, I=20 don't think this has made it into any of their recent beta releases. Maybe it's time for V to align with WM, and they can use { "key" :=20 "value" } :) eric |
From: Lane S. <la...@op...> - 2003-05-29 06:59:55
|
the : is being used in java 1.5 over the new iterator: for (element : list) { System.out.println(element) } read "object element in list" so I would definitely vote for : -Lane Eric B. Ridge wrote: > On Tuesday, May 27, 2003, at 10:17 AM, Keats wrote: > >> From: "Endre Stølsvik" <web...@st...> >> >>> Alignment with Velocity? >> >> >> Does anybody know what syntax Velocity ended up with? I don't think >> it's >> made it into their docs yet. > > > I just IM'd Geir about it. His response: "I don't recall". Plus, I > don't think this has made it into any of their recent beta releases. > > Maybe it's time for V to align with WM, and they can use { "key" : > "value" } :) > > eric > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
From: Keats <ke...@ea...> - 2003-06-20 22:07:13
|
I've finally gotten back to work on the #templet an #eval directives. I thought I'd give an update and solicit some feedback. I decided to separate the context from the "templet", so you have to supply the context with the #eval (or use the current context). This means that the templet directive is now equivalent to "#setblock as macro". Since a templet is just a macro, you can expand it using the current context by just specifying the variable name. E.g., ## templet def #templet $t { Some junk with variables like $x and $y } ## expand templet with current context $t So I think I can simplify the #eval directive to just 2 optional parameters, "copy context" and "with <map>". So, the preferred usage would be something like: ## create a new context with the supplied map of variables #eval $t using { "x" : "foo", "y" : 999 } But you could also do: ## use copies of $x and $y from the current context #eval $t copy context or ## use a copy of $y from the current context and override $x #eval $t copy context using { "x" : "foo" } Any thoughts? Keats |
From: Sebastian K. <seb...@mu...> - 2003-06-21 13:00:38
|
Hi Keats, On Saturday 21 June 2003 00:06, Keats wrote: > I've finally gotten back to work on the #templet an #eval directives. I > thought I'd give an update and solicit some feedback. I'm wondering, whether #eval should really be a directive. I think I dislike it, because you don't have a choice anymore, what to do with the evaluated templet: It always gets printed. Remember Lane's wish to store templet's somewhere out of a wm-file? My proposal was to create a "Writer"-Tool, that can take any macro and store it somewhere. So with your proposal, you could do #template $t { bla bla blub blub $foo $bar } $Writer.write("some/file.txt",$t) if $t is a macro, but if you want to change the context, you couldn't. But if you would add a method "withContext(Map context)" to $t, you could do $Writer.write("some/file.txt",$t.withContext({"foo":"a", "bar" : "b"}) Do you understand my point? What was the reason for needing an #eval-directive in the first place? Sebastian -- Sebastian Kanthak PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html |
From: Keats <ke...@ea...> - 2003-06-23 14:38:12
|
----- Original Message ----- > I'm wondering, whether #eval should really be a directive. I think I dislike > it, because you don't have a choice anymore, what to do with the evaluated > templet: It always gets printed. Well you can always wrap it in a #setblock if you need the output for something else. > Remember Lane's wish to store templet's somewhere out of a wm-file? My > proposal was to create a "Writer"-Tool, that can take any macro and store it > somewhere. > > So with your proposal, you could do > > #template $t { bla bla blub blub $foo $bar } > $Writer.write("some/file.txt",$t) > > if $t is a macro, but if you want to change the context, you couldn't. But if > you would add a method "withContext(Map context)" to $t, you could do > $Writer.write("some/file.txt",$t.withContext({"foo":"a", "bar" : "b"}) > > Do you understand my point? What was the reason for needing an #eval-directive > in the first place? You could still do this sort of thing with the $Template tool. People didn't seem to like the template tool syntax, so I came up with the directive approach which seems a bit more user friendly. My approach to the above would be to use a directive for the writer, say #output #output file="some/file.txt" { #eval $t using { "foo":"a", "bar":"b" } } Would this work for you? Thanks for the feedback. Keats |
From: Lane S. <la...@op...> - 2003-06-24 07:04:18
|
Keats, Sebastian: The templet is now a powerful language construct for WM. Good work, Keats! Can a templet contain a templet? Re: #output file="some/file.txt" { #eval $t using { "foo":"a", "bar":"b" } } Is the above block evaluate or saved literally for later evaluation? -Lane Keats wrote: >----- Original Message ----- > > >>I'm wondering, whether #eval should really be a directive. I think I >> >> >dislike > > >>it, because you don't have a choice anymore, what to do with the evaluated >>templet: It always gets printed. >> >> > >Well you can always wrap it in a #setblock if you need the output for >something else. > > > >>Remember Lane's wish to store templet's somewhere out of a wm-file? My >>proposal was to create a "Writer"-Tool, that can take any macro and store >> >> >it > > >>somewhere. >> >>So with your proposal, you could do >> >>#template $t { bla bla blub blub $foo $bar } >>$Writer.write("some/file.txt",$t) >> >>if $t is a macro, but if you want to change the context, you couldn't. But >> >> >if > > >>you would add a method "withContext(Map context)" to $t, you could do >>$Writer.write("some/file.txt",$t.withContext({"foo":"a", "bar" : "b"}) >> >>Do you understand my point? What was the reason for needing an >> >> >#eval-directive > > >>in the first place? >> >> > >You could still do this sort of thing with the $Template tool. People >didn't seem to like the template tool syntax, so I came up with the >directive approach which seems a bit more user friendly. > >My approach to the above would be to use a directive for the writer, say >#output > >#output file="some/file.txt" { > #eval $t using { "foo":"a", "bar":"b" } >} > >Would this work for you? Thanks for the feedback. > >Keats > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > |
From: Brian G. <br...@qu...> - 2003-06-24 07:12:15
|
> #output file="some/file.txt" { > #eval $t using { "foo":"a", "bar":"b" } > } I really don't like this. Templates should be able to evaluate to two places: - the template output - variables in the context That's it. Not only is it a security risk to do otherwise, but its inviting all sorts of weird side effects. |
From: Lane S. <la...@op...> - 2003-06-24 16:08:17
|
I do a lot of code generation and I would like to be able to generate WM code as well. The problem I run into is streaming an block within a template: #setblock $JavaTemplate { class $ClassName bla, bla } ## how to cleanly evaluate $JavaTemplate and stream this to home/org/webmacro/dyn/$ClassName.java? Maybe someone could propose a practice here. I do not like mine currently. Possibly a context tool which is a writer? $EvalWriter(Stream, template, context)??? -Lane What is the pattern going to look like Brian Goetz wrote: >>#output file="some/file.txt" { >> #eval $t using { "foo":"a", "bar":"b" } >>} >> >> > >I really don't like this. > >Templates should be able to evaluate to two places: > - the template output > - variables in the context > >That's it. Not only is it a security risk to do otherwise, but its >inviting all sorts of weird side effects. > > > > |
From: Marc P. <ma...@an...> - 2003-06-24 16:15:54
|
On Tue, 24 Jun 2003 09:01:07 -0700, Lane Sharman <la...@op...> wrote: > I do a lot of code generation and I would like to be able to generate WM > code as well. The problem I run into is streaming an block within a > template: > > #setblock $JavaTemplate { > class $ClassName > bla, bla > } > ## how to cleanly evaluate $JavaTemplate and stream this to > home/org/webmacro/dyn/$ClassName.java? > > Maybe someone could propose a practice here. I do not like mine > currently. Possibly a context tool which is a writer? $EvalWriter(Stream, > template, context)??? Well, does Macro implement toString()? If so, then all you need is a StringToFile helper class/context tool/function. $Save( "home/org/webmacro/dyn/$ClassName.java", $JavaTemplate) Trivial? Why not just write an app for this (antwmcompile?). I don't get why WM should be doing this when it's the app that renders templates. Having one page produce multiple outputs is... more like a full language :) -- Marc Palmer Contract Java Consultant/Developer http://www.anyware.co.uk/marc/ http://www.wangjammers.org |
From: Keats <ke...@ea...> - 2003-06-24 16:28:50
|
Yes this is exactly what I had envisioned the #output directive for. It's not something you'd normally use on a Web site, but it has lot's of uses for stand-alone apps. Keats ----- Original Message ----- From: Lane Sharman To: Brian Goetz Cc: Keats ; Sebastian Kanthak ; web...@li... Sent: Tuesday, June 24, 2003 12:01 PM Subject: Re: [Webmacro-devel] #templet directive I do a lot of code generation and I would like to be able to generate WM code as well. The problem I run into is streaming an block within a template: #setblock $JavaTemplate { class $ClassName bla, bla } ## how to cleanly evaluate $JavaTemplate and stream this to home/org/webmacro/dyn/$ClassName.java? Maybe someone could propose a practice here. I do not like mine currently. Possibly a context tool which is a writer? $EvalWriter(Stream, template, context)??? -Lane What is the pattern going to look like Brian Goetz wrote: #output file="some/file.txt" { #eval $t using { "foo":"a", "bar":"b" } } I really don't like this. Templates should be able to evaluate to two places: - the template output - variables in the context That's it. Not only is it a security risk to do otherwise, but its inviting all sorts of weird side effects. |
From: Keats <ke...@ea...> - 2003-06-24 14:10:48
|
----- Original Message ----- > Can a templet contain a templet? > Re: > #output file="some/file.txt" { > #eval $t using { "foo":"a", "bar":"b" } > } > Is the above block evaluate or saved literally for later evaluation? I'm not quite sure what you're asking. If you want to save a literal block you can use setblock. The #templet directive is equivalent to #setblock as macro, that is, it parses the text and stores the macro for later evaluation (by the #eval directive or direct expansion). The (as yet mythical) #output directive directs output to a file or stream. You could use this to dynamically generate templates, program files, SQL scripts, or whatever. Hope this answers your question. Keats |
From: Sebastian K. <seb...@mu...> - 2003-06-25 19:26:42
|
Hi, On Monday 23 June 2003 16:37, Keats wrote: > You could still do this sort of thing with the $Template tool. People > didn't seem to like the template tool syntax, so I came up with the > directive approach which seems a bit more user friendly. > > My approach to the above would be to use a directive for the writer, say > #output ok, let's forget about the output thing. I only used this as an example. Like Brian, I personally do not think think it is necessary, but if Lane has a need for it, it's ok. My problem with the #eval-directive is of a more general nature: In WebMacro we basically have to possibilities to control the result of a template evaluation: 1) We can insert something into the output stream. This is usually done by a property reference $foo.bar 2) We can interact with the template engine and tell it to iterate certain blocks, chose one depending on a condition, set some properties and so on. Intuitively I think, that writing something into the output-stream (point 1) should be done via property references of the form $... and point 2 should be done via directives. Or to put it the other way round: I believe, that directives should not output anything by themselves. Of course the "#foreach" directive outputs a lot, but that comes from the block inside the directive, not from the directive itself. The same holds for "#if" and "#set" does not output anything at all. This is similar to the distinction between statements and expressions in most programming languages. I just realized, that this is how I thought about directives and property-refernces until now. In this picture a #templet directive would fit quite nice, because it just declares a template. However, for evaluating, I would find a $... syntax nicer. However, I must admit, that there exists directives (like those declared from macros), that do not fit in my own schema, so it is probably broken. But perhaps we can have some discussion about it: Do we have a consistent guideline, when to use $... syntax (via tools or macros) and when to use directives? I do not know of one and this is, where my confusion comes from. Sebastian -- Sebastian Kanthak PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html |
From: Brian G. <br...@qu...> - 2003-06-25 19:31:56
|
> Intuitively I think, that writing something into the output-stream > (point 1) should be done via property references of the form > $... and point 2 should be done via directives. How about: #eval $template using $map -> to output stream #eval $template to $variable using $map -> like a #setblock Or, alterantely #setblock $varible { #eval $templet using $map } |
From: Keats <ke...@ea...> - 2003-06-25 21:14:44
|
I think your inference is falacious. Many directives write to the output stream, some use block arguments and some don't. The #include directive writes to the stream without a block arg. (And of course macros do this, but that's another issue.) I do think that a clear distinction between "expansion" -- putting something into the output stream, and "evaluation" -- performing some computation, would be helpful, but I can't think of a good way to do this without radically changing the WM syntax. It seems like the pattern that we've developed is that you use tools or functions for basic value transformations -- HTMLEscape, URLEncode, Math.mod, etc -- and directives for everything else. Better documentation would probably help here. Perhaps a taxonomy of directives, like: Control flow directives: #if/#elseif/#else #foreach #count Context altering directives (variable creation): #set #setblock #const/#attribute/#param #macro #alternate #bean #templet Text expansion directives: #include #eval #text Other: #comment #type #profile Keats ----- Original Message ----- From: "Sebastian Kanthak" <seb...@mu...> To: "Keats" <ke...@ea...> Cc: <web...@li...> Sent: Wednesday, June 25, 2003 3:25 PM Subject: Re: [Webmacro-devel] #templet directive > Hi, > > On Monday 23 June 2003 16:37, Keats wrote: > > You could still do this sort of thing with the $Template tool. People > > didn't seem to like the template tool syntax, so I came up with the > > directive approach which seems a bit more user friendly. > > > > My approach to the above would be to use a directive for the writer, say > > #output > > ok, let's forget about the output thing. I only used this as an example. Like > Brian, I personally do not think think it is necessary, but if Lane has a > need for it, it's ok. > > My problem with the #eval-directive is of a more general nature: > > In WebMacro we basically have to possibilities to control the result of a > template evaluation: > > 1) We can insert something into the output stream. This is usually done by a > property reference $foo.bar > > 2) We can interact with the template engine and tell it to iterate certain > blocks, chose one depending on a condition, set some properties and so on. > > Intuitively I think, that writing something into the output-stream (point 1) > should be done via property references of the form $... and point 2 should be > done via directives. > > Or to put it the other way round: I believe, that directives should not output > anything by themselves. Of course the "#foreach" directive outputs a lot, but > that comes from the block inside the directive, not from the directive > itself. The same holds for "#if" and "#set" does not output anything at all. > > This is similar to the distinction between statements and expressions in most > programming languages. I just realized, that this is how I thought about > directives and property-refernces until now. > > In this picture a #templet directive would fit quite nice, because it just > declares a template. However, for evaluating, I would find a $... syntax > nicer. > > However, I must admit, that there exists directives (like those declared from > macros), that do not fit in my own schema, so it is probably broken. > > But perhaps we can have some discussion about it: Do we have a consistent > guideline, when to use $... syntax (via tools or macros) and when to use > directives? I do not know of one and this is, where my confusion comes from. > > Sebastian > > -- > Sebastian Kanthak > PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel |
From: Lane S. <la...@op...> - 2003-06-26 04:41:35
|
Directives are just that. They provide direction and control over the flow. A Directive is an intrinsic keyword for the WebMacro parser and evaluation engine. A property is an operator returning void, null, or an object. In the latter case, the object's string representation is added to the stream unless we are talking about assignment: #set $foo = $bar. A property is expanded. A directive is interpreted. As to the output directive, I agree that it complicates things. I think we should stick with directives which enhance the language. Property tools are the right place to do transformations and evaluations. I think we could use some that are more utilitarian for those who are creating non-web text and interacting with data flows as occurs in application integration. Can we finalize #templet now? #eval $template using { "foo":"a", "bar":"b" } #eval $template to $variable using { "foo":"a", "bar":"b" } #eval $template #eval $template to $variable Would be the #eval variations as I see them. The first two create an explicit context and the last two use the current context. The using ... option provides a nice way of creating a private context for the templet. The using ... option implies that the templet cannot update the context of the invoker. -Lane Keats wrote: >I think your inference is falacious. Many directives write to the output >stream, some use block arguments and some don't. The #include directive >writes to the stream without a block arg. (And of course macros do this, >but that's another issue.) > >I do think that a clear distinction between "expansion" -- putting something >into the output stream, and "evaluation" -- performing some computation, >would be helpful, but I can't think of a good way to do this without >radically changing the WM syntax. > >It seems like the pattern that we've developed is that you use tools or >functions for basic value transformations -- HTMLEscape, URLEncode, >Math.mod, etc -- and directives for everything else. > >Better documentation would probably help here. Perhaps a taxonomy of >directives, like: > >Control flow directives: > >#if/#elseif/#else >#foreach >#count > >Context altering directives (variable creation): > >#set >#setblock >#const/#attribute/#param >#macro >#alternate >#bean >#templet > >Text expansion directives: > >#include >#eval >#text > >Other: > >#comment >#type >#profile > >Keats > >----- Original Message ----- >From: "Sebastian Kanthak" <seb...@mu...> >To: "Keats" <ke...@ea...> >Cc: <web...@li...> >Sent: Wednesday, June 25, 2003 3:25 PM >Subject: Re: [Webmacro-devel] #templet directive > > > > >>Hi, >> >>On Monday 23 June 2003 16:37, Keats wrote: >> >> >>>You could still do this sort of thing with the $Template tool. People >>>didn't seem to like the template tool syntax, so I came up with the >>>directive approach which seems a bit more user friendly. >>> >>>My approach to the above would be to use a directive for the writer, say >>>#output >>> >>> >>ok, let's forget about the output thing. I only used this as an example. >> >> >Like > > >>Brian, I personally do not think think it is necessary, but if Lane has a >>need for it, it's ok. >> >>My problem with the #eval-directive is of a more general nature: >> >>In WebMacro we basically have to possibilities to control the result of a >>template evaluation: >> >>1) We can insert something into the output stream. This is usually done by >> >> >a > > >>property reference $foo.bar >> >>2) We can interact with the template engine and tell it to iterate certain >>blocks, chose one depending on a condition, set some properties and so on. >> >>Intuitively I think, that writing something into the output-stream (point >> >> >1) > > >>should be done via property references of the form $... and point 2 should >> >> >be > > >>done via directives. >> >>Or to put it the other way round: I believe, that directives should not >> >> >output > > >>anything by themselves. Of course the "#foreach" directive outputs a lot, >> >> >but > > >>that comes from the block inside the directive, not from the directive >>itself. The same holds for "#if" and "#set" does not output anything at >> >> >all. > > >>This is similar to the distinction between statements and expressions in >> >> >most > > >>programming languages. I just realized, that this is how I thought about >>directives and property-refernces until now. >> >>In this picture a #templet directive would fit quite nice, because it just >>declares a template. However, for evaluating, I would find a $... syntax >>nicer. >> >>However, I must admit, that there exists directives (like those declared >> >> >from > > >>macros), that do not fit in my own schema, so it is probably broken. >> >>But perhaps we can have some discussion about it: Do we have a consistent >>guideline, when to use $... syntax (via tools or macros) and when to use >>directives? I do not know of one and this is, where my confusion comes >> >> >from. > > >>Sebastian >> >>-- >>Sebastian Kanthak >>PGP/GnuPG: http://www.muehlheim.de/~skanthak/pgp.html >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: INetU >>Attention Web Developers & Consultants: Become An INetU Hosting Partner. >>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >>_______________________________________________ >>Webmacro-devel mailing list >>Web...@li... >>https://lists.sourceforge.net/lists/listinfo/webmacro-devel >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >Webmacro-devel mailing list >Web...@li... >https://lists.sourceforge.net/lists/listinfo/webmacro-devel > > > |