1. Kanarie Template System
Juergen, the Kanarie Template System is ready, tested and fully documented.
I've submitted it to the Euphoria-site, and you can download it from
http://users.telenet.be/tommycarlier/eu
--
tommy online: http://users.telenet.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
2. Re: Kanarie Template System
Tommy Carlier wrote:
> Juergen, the Kanarie Template System is ready, tested and fully
> documented.
> I've submitted it to the Euphoria-site, and you can download it from
> http://users.telenet.be/tommycarlier/eu
I've been looking for something like the Kanarie Template System for
a long time. I also wrote something like that myself, but that was
rather primitive, compared to Kanarie. Parsing code [especially parsing
code *reliably* 
] is not the simplest task for a layman.
Kanarie actually looks as flexible and powerful as I was hopeing! It has
even those great 'list' and 'conditionals' elements! Also, the
documentation is very clean, comprehensive and understandable.
Thank you very much!!!
Maybe I have a suggestion for improvement. This is one of the examples
from your documentation:
<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}
</body>
</html
If the text in each language would consist of, say, several hundred
lines, this wouldn't look nice any more, and then it would be rather
difficult to get the overview of the structure of the template.
As far as I understand, we also can use fields, which might be better in
case of long texts:
<html>
<body>
{language=en:}{text_en}
{:language=nl:}{text_nl}
{:language=fr:}{text_fr}{:language}
</body>
</html
Now my new idea.
In the previous example, my program must "fill out" the fields {text_en},
{text_nl}, and {text_fr}. I think it would be nice and powerful, if
Kanarie would accept a file name, and then just 'includes' the content
of that file at that place. Then this example could look something like
this:
<html>
<body>
{language=en:}{include=en.txt}
{:language=nl:}{include=nl.txt}
{:language=fr:}{include=fr.txt}{:language}
</body>
</html
If you like, you could even allow 'en.txt' etc. not only to be plain
text files, but also template files themselves!
Next step ...
Using the naming convention that I used for the files in the previous
example, it would be very cool IMHO, if we also could write something
like this, to achieve the same result:
<html>
<body>
{include={language}.txt}
</body>
</html
What do you think? :o)
I will use Kanarie at least for generating HTML files, and as a
macro-system for Euphoria, for example in order to automatically
generate different code for different platforms (like in one of your
examples). I think also e.g. block comments in Eu code should be easy
to realize using Kanarie, shouldn't it?
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!
Regards,
Juergen
PS: I also thought of nested fields, but that probably makes things too
complicated ...
3. Re: Kanarie Template System
Juergen Luethje wrote:
> In the previous example, my program must "fill out" the fields {text_en},
> {text_nl}, and {text_fr}. I think it would be nice and powerful, if
> Kanarie would accept a file name, and then just 'includes' the content
> of that file at that place. Then this example could look something like
> this:
>
> <html>
> <body>
> {language=en:}{include=en.txt}
> {:language=nl:}{include=nl.txt}
> {:language=fr:}{include=fr.txt}{:language}
> </body>
> </html
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>
> 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.
> Next step ...
> Using the naming convention that I used for the files in the previous
> example, it would be very cool IMHO, if we also could write something
> like this, to achieve the same result:
>
> <html>
> <body>
> {include={language}.txt}
> </body>
> </html
>
> What do you think? :o)
Again, the Kanarie-parser is not that advanced.
> I will use Kanarie at least for generating HTML files, and as a
> macro-system for Euphoria, for example in order to automatically
> generate different code for different platforms (like in one of your
> examples). I think also e.g. block comments in Eu code should be easy
> to realize using Kanarie, shouldn't it?
>
> 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, 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.
You can download the new version from http://users.telenet.be/tommycarlier/eu
I not only added include-elements, but also enhanced the documentation a bit.
Juergen also sent me a modified version of the KTS-diagram picture, which I
modified myself a bit.
--
tommy online: http://users.telenet.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
4. 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]
5. Re: Kanarie Template System
Juergen Luethje wrote:
> 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.
That's right: a field that is not set, and empty lists generate nothing. Will
add it to the documentation.
> 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}
Great idea!
> 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?
Yes it is. I think I might have to change it: it's not logical. What would be it
be: both case-sensitive or both case-insensitive?
> 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?
True. Even the close-character doesn't need to be redefined: only the
open-character is essential to find a tag in text.
> 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>
I like the idea. Just to make things simple, the =* isn't even necessary:
{lang=en:}en{:lang=nl:}nl{:lang=fr:}fr{:lang:}other{:lang}
> 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>
The current parser reads the file, and parses everything in one pass. I think
this requires recursive handling. And I think it would not make programming using
Kanarie any easier.
KISS: Keep It Simple, Sydney.
--
tommy online: http://users.telenet.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
6. Re: Kanarie Template System
Tommy Carlier wrote:
> Juergen Luethje wrote:
<snip>
> That's right: a field that is not set, and empty lists generate nothing.
> Will add it to the documentation.
Thanks.
<snip>
>> 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?
>
> Yes it is. I think I might have to change it: it's not logical. What
> would be it be: both case-sensitive or both case-insensitive?
I think this is mainly a question of habits. Since the first
implementation of KTS is in Euphoria, and Euphoria programmers are used
to case-sensitive coding, I vote for: "both case-sensitive".
<snip>
>> 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>
>
> I like the idea. Just to make things simple, the =* isn't even
> necessary: {lang=en:}en{:lang=nl:}nl{:lang=fr:}fr{:lang:}other{:lang}
Cool, thank you!
<snip>
> KISS: Keep It Simple, Sydney.
Yep.
Regards,
Juergen
7. Re: Kanarie Template System
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Aug 18, 2004
-
Last edited Aug 19, 2004
Tommy Carlier wrote:
> Juergen Luethje wrote:
<snip>
>> 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}
>
> Great idea!
A slightly different kind of "block comments" can be used, in order to
add documentation to source code, that can be saved (and printed or
whatever) separately:
----------------------------------
global function ceil (object x)
{mode=doc:}
ceil is the opposite of floor().
x may be an atom or a sequence.
{:mode=prog:}
return -floor(-x)
end function
{:mode}
----------------------------------
AFAIK there is a program that does a similar job with special comments
in Win32Lib source code. I think using Kanarie, this can be done in a
general way.
<snip>
>> 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?
>
> Yes it is. I think I might have to change it: it's not logical. What
> would be it be: both case-sensitive or both case-insensitive?
In addition to my previous reply, I have another suggestion: How about
an upper() and a lower() function built into Kanarie? See the following
example:
-----------[ demo.ex ]-----------
include kanarie.e
sequence template
integer data
data = createData()
setValue(data, "animal", "hOrSE")
template = loadTemplate("demo.knr")
puts(1, generate(data, template))
closeData(data)
-------------[ end ]-------------
-----------[ demo.knr ]----------
{animal}
{ANIMAL}
{Animal}
{ANiMAL}
-------------[ end ]-------------
The output is currently (KTS 1.2):
hOrSE
hOrSE
hOrSE
hOrSE
Following my suggestion, the output would be:
horse
HORSE
hOrSE
hOrSE
That is, if the field name is completely in lower/upper case, the output
for that field also will be in lower/upper case.
If the field name is *not completely* in lower or upper case, the case
of the value of that field will not be changed.
<snip>
Regards,
Juergen
8. Re: Kanarie Template System
- Posted by Tommy Carlier <tommy.carlier at telenet.be>
Aug 18, 2004
-
Last edited Aug 19, 2004
Juergen Luethje wrote:
> A slightly different kind of "block comments" can be used, in order to
> add documentation to source code, that can be saved (and printed or
> whatever) separately:
>
> ----------------------------------
> global function ceil (object x)
> {mode=doc:}
> ceil is the opposite of floor().
> x may be an atom or a sequence.
> {:mode=prog:}
> return -floor(-x)
> end function
> {:mode}
Very nice. Not just for documenting, but also for other applications:
- Euphoria-code (generates the program to run): {app=exw:}...{:app}
- documentation: {app=doc:}...{:app}
- IDE design: {app=ide:}...{:app}
- ...
Each application can read the file and only extract what it needs.
> >> 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?
> >
> > Yes it is. I think I might have to change it: it's not logical. What
> > would be it be: both case-sensitive or both case-insensitive?
>
> In addition to my previous reply, I have another suggestion: How about
> an upper() and a lower() function built into Kanarie? See the following
> example:
>
> -----------[ demo.ex ]-----------
> include kanarie.e
> sequence template
> integer data
>
> data = createData()
> setValue(data, "animal", "hOrSE")
> template = loadTemplate("demo.knr")
> puts(1, generate(data, template))
> closeData(data)
> -------------[ end ]-------------
>
> -----------[ demo.knr ]----------
> {animal}
> {ANIMAL}
> {Animal}
> {ANiMAL}
> -------------[ end ]-------------
>
>
> The output is currently (KTS 1.2):
> hOrSE
> hOrSE
> hOrSE
> hOrSE
>
> Following my suggestion, the output would be:
> horse
> HORSE
> hOrSE
> hOrSE
>
> That is, if the field name is completely in lower/upper case, the output
> for that field also will be in lower/upper case.
> If the field name is *not completely* in lower or upper case, the case
> of the value of that field will not be changed.
I wouldn't take it that far: it would limit the possibilities and add little
value.
--
tommy online: http://users.telenet.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
9. Re: Kanarie Template System
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Aug 21, 2004
-
Last edited Aug 22, 2004
Tommy Carlier wrote:
> Juergen Luethje wrote:
<snip>
>> How about an upper() and a lower() function built into Kanarie?
<snip>
>> That is, if the field name is completely in lower/upper case, the output
>> for that field also will be in lower/upper case.
>> If the field name is *not completely* in lower or upper case, the case
>> of the value of that field will not be changed.
>
> I wouldn't take it that far: it would limit the possibilities and add
> little value.
After having thought more about it, I do agree. Mostly, I would not need
such a functionality myself, and it would force the user, to follow a
rather unusual convention for creating field names.
However, sooner or later I probably *will* need such a functionality.
I admit, that my example with the {ANIMAL} field was not very convincing.
When I'll have the time, I'll write a citation manager such as "Endnote"
in Euphoria. Such a program helps authors of scientific papers
tremendously in automatically and correctly formatting a list of cited
works. Authors can use the program to maintain a reference database, and
by selecting the appropriate Kanarie template, they can choose a
bibliographic style according to the journal for which the paper is
written.
Then it sometimes will be necessary, that the Kanarie template is able
to determine, that e.g. the family name of an author will be cited in
upper case. But this is possible with Kanarie anyway. In my Euphoria
program, I simply can maintain two versions of the family names, one
version "as is", and the other version in upper case. The template then
determines, which version will be used:
-----------[ demo.ex ]-----------
include kanarie.e
sequence fName, template
integer data
data = createData()
fName = "Smith"
setValue(data, "family_name", fName)
setValue(data, "FAMILY_NAME", upper(fName))
template = loadTemplate("demo.knr")
puts(1, generate(data, template))
closeData(data)
-------------[ end ]-------------
-----------[ demo.knr ]----------
{family_name}
{FAMILY_NAME}
-------------[ end ]-------------
To make a long story short:
I want to thank you for the decision, to make the field names
case-sensitive. I see now, that this is more than just following coding
habits. Things like those mentioned above would also have been possible
with case-insensitive field names, if course. Then the template above
would have looked like this:
-----------[ demo.knr ]----------
{family_name_as_is}
{family_name_upper}
-------------[ end ]-------------
But case-sensitive field names allow choosing much nicer, and more
intuitive names, and, generally speaking, there are much more
possibilities for choosing a name, compared to case-insensitive names.
Regards,
Juergen
