Chuck Esterbrook wrote:
> At 10:47 AM 4/23/2001 -0700, Tavis Rudd wrote:
> >What do you think of this in general?
> >- do you like the #if(...), etc. syntax better than
> ><-if $test-> ... <-/if->?
> Um, neither. :-)
> The # thing is almost OK in velocity, but I don't understand why they
> insist on the parens. Also, I prefer "for" instead of "foreach". So:
if(parens) and foreach come from a too-common malady known as "C/Perl on the brain." Fortunately, it is less common in the python community. 8-) (I suffer from a similar malady "Python on the brain". I just hate it when my C/Java compiler calls "if foo is None:" a syntax error.)
> #for $x in $foos
> Also, the Velocity folks complained that at one point webmacro was too
> buggy because of it's hand built parser. Both projects now use a generated
> Although personally, I think their grammar is simple enough that in
> combination with a test suite and some good coding practice, you could nail
> it down just fine.
I, too, prefer small grammars that can be parsed by small, understandable, hand-built parsers. I don't see any reason for a template mini-language to have a non LL(1) grammar -- Pascal does fine without
> >- can someone help me with Webware's relative paths in
> > relation to the #parse and #include directives?
> Many objects have a serverSidePath() method through which you can also pass
> a relative path to append to. The question is, do you want these parsed and
> included files to be relative to the servlet or what?
> If you have a "template engine" object, perhaps the best thing is to
> provide a setting (e.g., attribute) pointing to a method that takes a
> relative (or absolute path) and returns the final path. Then the user can
> hook this up to their application, servlet or whatever.
JSP,PSP, BuildKit and just about any other tool that references files, eventually invents a Context object that will (among other things) bind a name (path, relative or otherwise) to a resource (file) when requested. serverSidePath is a start, but it is far from suitable for the requirements of a template engine. Adding caching, variant bulids, and libraries (important features for a non-toy template engine) quickly increases the complexity of the binding process. Making the Context a first class citizen, (rather than a second-class method) helps it get the attention it deserves in the system design. Also, a Context almost always follows a composite pattern, able to create and reference contained contexts by name.
To get started it could be as simple as:
"""an abstract file
"""return a file-like object representing the resource contents
"""same as in MiscUtils.NamedValueAccess
"""bind the given abstract name ( relative to this context) to a Resource (file)
"""return a dependent context rooted at name
You could do this with a single method like serverSidePath, but you would have a hard time going much further. (I know this from the experience of trying to split up Webware into a distributed filesytem layout.)
Tavis, this is a core concept in BuildKit. I would like to work with you to integrate the two. A template engine is perhaps the most compelling reason I have yet seen for creating BuildKit in the first place. I looked at your code about two weeks ago, but I didn't understand it (BuildKit) well enough to fit it (your code) in right away. I will take another look at it (the integration) now.