Re: [Webmacro-devel] #templet directive

[Lane S. <la...@op...>]

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
>
>  
>