From: Chuck E. <ec...@mi...> - 2001-04-23 03:38:12
|
In my current effort to review various templating systems, I read up on webmacro. I definitely liked this part: ---- ---- ---- ---- ---- ---- ---- ---- Extending the Framework WebMacro loads almost all of its implementation from a configuration file at runtime. You can easily override, extend, or change its behavior by naming your own files in the configuration file instead of the defaults WebMacro ships with. Here are some of the things you can plug in via configuration file: o New directives for the script language (pluggable directives) o What default variables are available in every template (Tools) o Where templates are loaded from (template path) o How and when templates are loaded (template provider) o How long and whether templates are cached o How the WebMacro language itself is parsed (pluggable parser) This is what makes WebMacro an extensible framework: almost every aspect of its behavior can be easily overridden. As the developer of an application framework you can take advantage of these features to customize WebMacro to your particular needs. ---- ---- ---- ---- ---- ---- ---- ---- Sounds like Webware philosophy. :-) Here is a hint of feature creep that some have expressed concern over: ---- ---- ---- ---- ---- ---- ---- ---- How do I count in a WebMacro template? With version 0.95 (and later), when using the new parser, basic math operations are supported by the TemplateLanguage?: #set $counter = 1 #foreach $beer in $ListOfBeers? { $counter -- $beer.Name #set $counter = $counter + 1 } ---- ---- ---- ---- ---- ---- ---- ---- Ah, "basic math operations". I wonder when the basic array access, exception catching and other operations will arrive... But it's a hard issue. With no capabilities at all, some very simple things are not possible without going from the designer back to the programmer. On the other hand, my current client uses a language with no basic math and seems to get along fine (so far). The language is described at: http://www.webmacro.org/TemplateScripting Their core set of operations is in the same ball park of a "DTML lite": values, if-else, loops, includes, etc. I think DTML's "in" is more powerful than WebMacro's "foreach" loop in terms of the attributes, tag variables and possibly batching. It's notable that webmacro's top level design is generic enough that this could be implemented in Python and still use the same syntax. -Chuck |
From: Arkaitz B. <ar...@eu...> - 2001-04-23 08:56:21
|
On 22 Apr 2001 23:35:11 -0400, Chuck Esterbrook wrote: [snip] > Ah, "basic math operations". I wonder when the basic array access, > exception catching and other operations will arrive... I realize they are a step forward, but they are probably needed by some templating uses, although I've never needed them. > > But it's a hard issue. With no capabilities at all, some very simple things > are not possible without going from the designer back to the programmer. On > the other hand, my current client uses a language with no basic math and > seems to get along fine (so far). Yeah, and the goal is that the programmer _only_ writes domain/business code, leaving all the presentation stuff to the template writer/designer (who can be the same programmer, but I think it's still an improvement). > > The language is described at: > http://www.webmacro.org/TemplateScripting Have you had a look at Velocity (jakarta.apache.org/velocity)? It's a reimplementation of the Webmacro idea by some of the Turbine people. I think they have cleaned the language up a bit (no more braces! ;-)). > > Their core set of operations is in the same ball park of a "DTML lite": > values, if-else, loops, includes, etc. I think DTML's "in" is more powerful > than WebMacro's "foreach" loop in terms of the attributes, tag variables > and possibly batching. > > It's notable that webmacro's top level design is generic enough that this > could be implemented in Python and still use the same syntax. Yeah, the language is very Python-like (in Velocity more), except for those ugly "$" characters ;-) that seem to be needed. > > > -Chuck Cheers, Arkaitz. |
From: Chuck E. <ec...@mi...> - 2001-04-23 15:14:42
|
At 10:27 AM 4/23/2001 +0200, Arkaitz Bitorika wrote: >Have you had a look at Velocity (jakarta.apache.org/velocity)? It's a >reimplementation of the Webmacro idea by some of the Turbine people. I >think they have cleaned the language up a bit (no more braces! ;-)). Yeah, but they still use parentheses! :-) Thanks for the tip. Here is my review: Key docs are here: http://jakarta.apache.org/velocity/user-guide.html http://jakarta.apache.org/velocity/vtl-reference-guide.html webmacro & velocity both use $ to get values and # for all other directives. The syntax actually looks pretty clean and things like $1 and #10 are not interpreted. velocity supports multiline comments #* ... *# which is nice, although somewhat cryptic if you're not a C programmer. I wonder if a designer would feel more comfortable with #!-- with --# which looks equally hideous, but mirrors HTML's <!-- -->. I wonder why velocity chose curly braces for delineating variables in smooshed situations: ${vice}maniac, when webmacro chose ordinary parens. Hmmm, if you want a blank string rather than the variable name, you throw in an exclamation mark: $!email I find that a little cryptic, although admittedly compact (as most cryptic things are). If velocity can't find "email" for "$email", then it leaves it in place on the site. My HTML designers prefer to see a bigger "[Cannot find $email]" comment wrapped in a span whose style makes the text bold and red. This allows for easy debugging and even complaints by users. We would probably want an optional e-mail notification and/or logging for the production site. Velocity uses the classic shell convention of interpolating double quoted strings "$email" but not single quoted '$email' when these strings are used in expressions in directives. That's great for programmers, but not designers. Some of my designers have problems just grokking quotes in JavaScript. "#stop" is nice: "The #stop script element allows the template designer to stop the execution of the template engine and return. This is useful for debugging purposes." So is #macro which can help reduce a lot of typing in a template. Despite its name, I there is no 'macro' feature in webmacro. :-) A minus: "#set" always produces strings, even if the expression is mathematical. When using the value later in another mathematical expression, you have to convert it like this: $int.valueOf($a). I don't really see the point of that. Zope's DTML does batching and it's dtml-var tag supports things like what to insert if the field is blank, how many chars to truncate at, what to append if the value is truncated, etc. I don't these concepts of batching or advanced substitution operators in velocity or webmacro. They might also be missing to some extent in several of the Python templating modules posted recently, although most are still in my "thorough review queue". And last but not least: Looking at all those bloated Java examples sure makes me feel good that I discovered Python! Whew! |
From: Ian B. <ia...@co...> - 2001-04-23 16:00:54
|
At 11:11 AM 4/23/2001 -0400, Chuck Esterbrook wrote: >I wonder why velocity chose curly braces for delineating variables in >smooshed situations: ${vice}maniac, when webmacro chose ordinary parens. Well, ${var} is conventional for Perl and shell. {$var} for PHP, $(var) for Makefiles. One of the places you'd have to quote would be ${var}(html text) and ${var}[html text], which maybe looks better with {} than (). >Velocity uses the classic shell convention of interpolating double quoted >strings "$email" but not single quoted '$email' when these strings are >used in expressions in directives. That's great for programmers, but not >designers. Some of my designers have problems just grokking quotes in >JavaScript. PHP has this convention too, and I find it very annoying. I almost always want strings to be interpolated, so I always have to use ", but " is a very important character in HTML, so I'm using "<a href=\"$var\">" all the time. Shell needs it more, because things can get interpreted more than once by the shell, and then again by the command you are calling. A template system shouldn't have that problem. Or, rather, you should actively avoid that problem. Actually, the only time I haven't wanted strings to be interpolated in PHP has been when using something like eval, or defining a function dynamically. Again, not features I would advise adding. >A minus: "#set" always produces strings, even if the expression is >mathematical. When using the value later in another mathematical >expression, you have to convert it like this: $int.valueOf($a). don't >really see the point of that. I've never used it as such, but I can see why Tcl is a good language for HTML scripting -- everything is a string, and it was actually thought through enough that it works okay (up to a point). I think the solution probably isn't to change #set, but to make the $int.valueOf() implicit when you are using mathematical operations. (well, actually floats, I suppose) >Zope's DTML does batching and it's dtml-var tag supports things like what >to insert if the field is blank, how many chars to truncate at, what to >append if the value is truncated, etc. I don't these concepts of batching >or advanced substitution operators in velocity or webmacro. They might >also be missing to some extent in several of the Python templating modules >posted recently, although most are still in my "thorough review queue". I think these features are easy to add to any template system if the syntax has a way of easily adding optional keyword arguments. So I think that's what you'd want to look for, more than the actual presence of these particular features. Ian |
From: Ian B. <ia...@co...> - 2001-04-23 16:09:59
|
At 10:27 AM 4/23/2001 +0200, Arkaitz Bitorika wrote: > > Ah, "basic math operations". I wonder when the basic array access, > > exception catching and other operations will arrive... >I realize they are a step forward, but they are probably needed by some >templating uses, although I've never needed them. I'm not surprised that they can be needed. Defining how something should be displayed can easily become an exercise in general programming. You want to show ten items per page, but if there's 12 items you don't want to use up two pages for them. You want to highlight different ranges of numbers in a table with different colors. If you have a thinking person designing the interface, and a thinking person viewing it, there's no limit to the programming that can show up in the template -- and be *appropriate* in the template as well. Well, I think there is a limit -- at no time should the template ever need to do anything that has side effects (except perhaps getting global serial numbers in one form or another, or using a global seed for random numbers, etc). But there's nothing in Webmacro that keeps one from doing this, since just about any function call is allowed. It's only convention. But that's probably all it can be when you are calling arbitrary procedures. Ian |
From: Terrel S. <tsh...@ic...> - 2001-04-23 16:06:30
|
Chuck Esterbrook wrote: > If velocity can't find "email" for "$email", then it leaves it in place on > the site. My HTML designers prefer to see a bigger "[Cannot find $email]" > comment wrapped in a span whose style makes the text bold and red. This > allows for easy debugging and even complaints by users. Leaving it alone allows the template to be processed more than once: foo.template =[bar.data]=> foobar.template =[session.data,request.data]=>output.html This could easily be made an option, e.g. valueForUnknownKey() could be the identity function for the preprocessed template, or """<span class="redbold">[Cannot find %(key)]</span>""" ( 8-) hey, even the error message is a template!) for the final stage. Error notification could be a side effect of either fuction. Quoting becomes a bigger issue for multi-pass templates. |
From: Chuck E. <ec...@mi...> - 2001-04-23 17:29:54
|
At 10:57 AM 4/23/2001 -0500, Ian Bicking wrote: >I think the solution probably isn't to change #set, but to make the >$int.valueOf() implicit when you are using mathematical >operations. (well, actually floats, I suppose) Why? Python gets along great with treating ints like ints and strings like strings. That mathematical expressions are natural and "print" works with everything. >>Zope's DTML does batching and it's dtml-var tag supports things like what >>to insert if the field is blank, how many chars to truncate at, what to >>append if the value is truncated, etc. I don't these concepts of batching >>or advanced substitution operators in velocity or webmacro. They might >>also be missing to some extent in several of the Python templating >>modules posted recently, although most are still in my "thorough review queue". > >I think these features are easy to add to any template system if the >syntax has a way of easily adding optional keyword arguments. So I think >that's what you'd want to look for, more than the actual presence of these >particular features. Well, I want everything, don't you know? :-) But you're right, if the syntax and implementation are extensible then we can add this in. If I remember right, that was one of the major points of your templating effort (which I haven't gotten to yet). -Chuck |
From: Ian B. <ia...@co...> - 2001-04-23 19:13:24
|
Chuck Esterbrook <ec...@mi...> wrote: > >I think the solution probably isn't to change #set, but to make the > >$int.valueOf() implicit when you are using mathematical > >operations. (well, actually floats, I suppose) > > Why? Python gets along great with treating ints like ints and strings like > strings. That mathematical expressions are natural and "print" works with > everything. Because, in HTML (and HTTP), *everything* is a string. There just isn't any other typing, except what you define with markup or mime-types, I suppose. Neither of those typings make sense in this context. Bringing in Python concepts of type demands a whole lot of thought and interfaces that don't seem necessary. > >I think these features are easy to add to any template system if the > >syntax has a way of easily adding optional keyword arguments. So I think > >that's what you'd want to look for, more than the actual presence of these > >particular features. > > Well, I want everything, don't you know? :-) > > But you're right, if the syntax and implementation are extensible then we > can add this in. If I remember right, that was one of the major points of > your templating effort (which I haven't gotten to yet). Well, I said that because most of those features took me like 30 extra minutes to implement for the pseudo-DTML (I wasn't clear on how DTML batching works, so that wasn't included). However, a syntax that looks like {varToInsert} has basic limitations with regards to this (though, I suppose, you could have {varToInsert missing="text"}). Whatever it is, it's not implementing the formatting or whatever that is complicated -- most of those are reducable to functions in the string module. The complexity is in making them easy to plug in. My implementation isn't particularly flexible in this way -- or, at least, I think it's sufficiently flexible, but I was shooting for something else. Ian |
From: Chuck E. <ec...@mi...> - 2001-04-23 19:31:14
|
At 02:13 PM 4/23/2001 -0500, Ian Bicking wrote: >Because, in HTML (and HTTP), *everything* is a string. There just >isn't any other typing, except what you define with markup or >mime-types, I suppose. Neither of those typings make sense in this >context. Bringing in Python concepts of type demands a whole lot of >thought and interfaces that don't seem necessary. I think of it more as a natural concept, not a strict Python concept. 3+2=5, not "5". So if x = 3 + 2, then I can later say x*2 and get 10. I was using Python as an example where types are respected, but "print" is still easy to use. Python invokes str() when it needs a string. So can we. Also, what about formats? $(salary fmt="0.2") If salary is a string, how do we get decimal places and such? I supposed you could convert strings to their context, like Perl, and barf an error msg or exception when the conversion goes bad. I prefer to leave the data as it really is and barf when you try to apply operations that don't make sense. -Chuck |
From: Ian B. <ia...@co...> - 2001-04-23 20:08:45
|
Chuck Esterbrook <ec...@mi...> wrote: > At 02:13 PM 4/23/2001 -0500, Ian Bicking wrote: > >Because, in HTML (and HTTP), *everything* is a string. There just > >isn't any other typing, except what you define with markup or > >mime-types, I suppose. Neither of those typings make sense in this > >context. Bringing in Python concepts of type demands a whole lot of > >thought and interfaces that don't seem necessary. > > I think of it more as a natural concept, not a strict Python concept. > 3+2=5, not "5". So if x = 3 + 2, then I can later say x*2 and get 10. The problem is there's no way to distinguish 5 from "5" in HTML. Also, type information isn't a concept that non-programmers will understand. I'm not entirely opposed to typing in this context, I just think it's good for the template language to be permissive about it. So that 2+3=5, "2"+3=5, etc. "2"+"3"=5 too, unlike Python, but I think Python got this wrong (+ as concatenation). IMHO, & is better, since addition and concatenation are seperate concepts. > Also, what about formats? $(salary fmt="0.2") > If salary is a string, how do we get decimal places and such? If salary is a string, the format implies it should be treated like a number. Yeah, it's kind of like Perl. Huh... I swear I had this conversation a couple years ago, and suddenly found myself defending Perl against all of my natural inclination. I can't remember what it was about, though. Ian |
From: Chuck E. <ec...@mi...> - 2001-04-24 14:22:19
|
At 03:08 PM 4/23/2001 -0500, Ian Bicking wrote: >The problem is there's no way to distinguish 5 from "5" in HTML. Why does that matter? The templating instructions have their own interpretation: #set x = 8; #if x<10: Hello $x #end That 10 is definitely a 10 and not a "10". The content comes out as "Hello 8" just like everyone, whether designer or programmer, woudl expect. >Also, type information isn't a concept that non-programmers will >understand. If they start writing expressions using <, +, etc. then they will have to understand some basic types and likely they already do. Designers aren't mathematicians, but I wouldn't put arithmetic past their capabilities. -Chuck |