Re: Kanarie Template System
Tommy Carlier wrote:
> Juergen Luethje wrote:
<snip>
> The new version (1.1) has an include-element, that you use like this:
> <html>
> <body>
> {language=en:}{$en.txt}
> {:language=nl:}{$nl.txt}
> {:language=fr:}{$fr.txt}{:language}
> </body>
> </html>
That's nice, thank you for the new version! Besides the purpose that I
previously mentioned, I just saw, that it will serve another purpose:
Using Kanarie's include element, it is easy to realize that 'private
include' functionality in Euphoria, that some people (including me)
desire. (AFAIK, the idea for 'private include' originated from Kat.)
I started to write a Kanarie-based preprocessor for Euphoria. When in
the program template Kanarie's include element is used rather than
Euphoria's include statement, the variables in the included .e file
don't have to be declared as global, and so their scope is limited to
the file that *directly* includes the .e file.
Tommy, I think our judgement is correct, that it is hard to tell all the
possible purposes of KTS beforehand. 
In the Kanarie documentation you write, concerning the Conditionals
example:
"If the language-field is set to something different (or not set at all),
none of the versions will be used."
What happens if a field is not set, or a list doesn't contain any items?
It seems to me, that the corresponding entry in the template then also
just will be skipped, but I'm not sure. Perhaps you can include that
info in the documentation, too.
If a "dummy list" in the template simply will be ignored by Kanarie,
then this can be elegantly misused for creating block comments,
e.g.:
{comment:}
This is a block comment, using the revolutionary Kanarie Template System.
{:comment}
Also, the preprocessor will be able to generate different code for
different platforms, of course!
If anything will work as expected, my code for the preprocessor will be
very small, because it will just be a "wrapper" for Kanarie.
Two more questions, for which I didn't find an answer in the
documentation:
It looks to me, as if the *names* of the fields, list items etc. are
case insensitive, and the *values* of the fields, list items etc. are
case sensitive. Is this true?
Generally speaking about redefinitions: Is it sufficient to redefine
only the tag characters for 'open' and for 'close', because any other
Kanarie tag characters are *inside* these characters?
Redefining the other tag characters seems to me just "for optical
reasons". Is this true?
Another idea. :o)
How about an optional 'else' condition?
Your language example then could look like this (using * to indicate
'else'):
<html>
<body>
{language=en:} This is the English version.
{:language=nl:} Dit is de Nederlandse versie.
{:language=fr:} Ceci est la version Fran=E7aise.
{:language=*:} Sorry, this language is currently not supported.{:langu=
age}
</body>
</html>
>> If you like, you could even allow 'en.txt' etc. not only to be plain
>> text files, but also template files themselves!
>
> That's a big step, it would involve recursive parsing & reading, and
> the Kanarie-parser is not really built for this kind of advanced
> handling.
I see. This was just an idea, probably not so important.
If we like, we also can run Kanarie several times. The first run has not
necessarily to produce the "text for the end user". It can produce new
templates, which then can be used by Kanarie in subsequent runs. :o)
<snip>
>> Kanarie is very simple and powerful at the same time, and IMHO its
>> possibilities are mainly limited by the fantasy of its users.
>> Thanks very much again, Tommy!
>
> I'm glad you like it. I designed KTS to be very simple to use,
I appreciate that very much.
> and not
> for a single task, but for things I myself haven't even thought about.
>
>> PS: I also thought of nested fields, but that probably makes things too
>> complicated ...
>
> I don't really understand what you mean with nested fields. You can
> nest lists and conditionals, because they are containers. But fields
> (and includes) are atomic: they have no children.
Sorry for not having expressed myself more clearly.
Currently, we can write contitinals, e.g. by using fields, such as:
<html>
<body>
{language=en:} {text_en} {:language}
{language=nl:} {text_nl} {:language}
{language=fr:} {text_fr} {:language}
</body>
</html>
With nested fields, I mean that the *name* of field A depends on the
*value* of field B, which is included in field A. With 'nested fields',
we can achieve the same as above, by using a template like this:
<html>
<body>
{text_{language}}
</body>
</html>
Please remember, that I wrote myself, that this is probably too
complicated. :o)
Anyway, I wanted to throw it into the discussion.
<snip>
Regards,
Juergen
--=20
I didn't have time to write a short letter,
so I wrote a long one instead.
[Mark Twain]
|
Not Categorized, Please Help
|
|
