You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <gm...@xyris.com> on 2000/11/06 16:33:06 UTC
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Christoph Reck :
> I've been thinking of the backslash problem using it as escape
> character. I believe the standard approach taken is in the wrong
> direction, thus causing lateral problems (see gunnar's message
> below).
You both are 100% right, and it's my bug that has us discussing this. I
should have thought it through. :)
To me, the idea behind all of this :
1) that we need to only 'escape' when we want to show the literal
representation of a valid reference and/or directive in the VTL proper.
This is fondly known as 'showing your underwear'. :)
2) Otherwise, we want it to be clear for designers and other content
producers that \ is a \ and only a \
> The simpler solution is to use special context identifiers
> to represent the $ and # symbols. To emit an '$foo' and
> #if' text in schmoo use '$$foo' and '$#if' in the template,
> thus not having to embed another syntax (escape cahracter)
> and keeping in line with the special VTL symbols!
I have a counter proposal that I feel gets us what we want, while :
- preserving the intuition of programmers to escape with \
- preserving the intuition of designers and content people that \ is a \.
- keeping the number of magic characters / sequences for the parser to a
minimum :
$ implies reference
# implies directive
And I note that :
- we already have the notion of 'modifier' in the '!' character which
'quiets' references as in $!foo
so :
Propose: simply to move the \ into the ref or macro as a 'modifier' just
like ! for references
$\<reference> outputs $<reference> if a valid reference, $\<reference>
otherwise
#\<directive> outputs #<directive> if a valid directive, #\<directive>
other
just like :
$!<reference> outputs $<reference> if a valid reference, nothing
otherwise
Beautiful symmetry (to me anyway :)
Working through the possiblities :
- if you want to output \<refvalue> just use \$<reference>.
- to output $foo when $foo is a reference, $\foo
- to output $foo when $foo isn't a reference (therefore schmoo), $foo does
it.
- to output \$foo when $foo isn't a reference (there's that shmoo again...),
\$foo does it
- to output $$foo when $foo is a ref : $$\foo
- am I missing anything?
> The generalization of this would be using ${(#|$)any text and characters}
> to be passed literally.
> Any votes in favour of this change?
> Any objections?
I kinda object because to me, I feel it complicates the VTL syntax. Since
we already have the notion of modifier in !.
It has been noted that this isn't necessarily intuitive, and I agree, but I
believe that my own intuition comes from being a programmer (or at least
playing one on TV), I believe that isn't necessarily the case for content
people and designers that would use the VTL.
Isn't this a special-case use, for either writing Vel documentation or
debugging? Maybe I have the wrong idea about this... Hm.
geir
Escape handling Mk II (new code committed)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Symmetry be damned, indeed.
The code for escape handling v2 is now in. Thanks to all for the
comments and discussion. I hope that this will be satisfactory to
everyone. If not, I am sure that y'all will speak up.
To review, the point of this is to make Velocity / VTL as non-invasive
to the schmoo, the non-VTL content in the template.
Simply put :
1) The '\' character acts as a conventional bind-from-the-left escape
character if and only if it appears on the left side of a VTL reference
or directive.
2) In all other cases, it is just a '\'
VTL reference := a syntax element $<name> such that a <name>,Object pair
is found in the Context.
VTL directive := a control directive or a pluggable directive, currently
including #set, #if, #else, #elsif, #end, #foreach, #include, #parse,
#macro and #stop.
Examples :
With $foo in the Context, it is 'active':
$foo renders as <foo>
\$foo renders as \$foo
\\$foo renders as \<foo> (because it binds from the left)
\\\$foo renders as \\$foo
With $foo NOT in the context, it's just text:
$foo renders as $foo
\$foo renders as \$foo
\\$foo renders as \\$foo
Directives :
#include("a.txt") renders as <contents of a.txt>
\#include("a.txt") renders as \#include("a.txt")
\\#include("a.txt") renders as \<contents of a.txt>
etc
\#if(true) hi \#end renders as #if(true) hi #end
\\#if(true) hi \\#end renders as \ hi \
\\\#if(true) hi \\#end is a parsing error after 'hi' :) (because the #if
is escaped, so there is a #end just sitting there )
Take a look at test/templates/escape2.vm for more good examples.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Escape handling Mk II (new code committed)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Symmetry be damned, indeed.
The code for escape handling v2 is now in. Thanks to all for the
comments and discussion. I hope that this will be satisfactory to
everyone. If not, I am sure that y'all will speak up.
To review, the point of this is to make Velocity / VTL as non-invasive
to the schmoo, the non-VTL content in the template.
Simply put :
1) The '\' character acts as a conventional bind-from-the-left escape
character if and only if it appears on the left side of a VTL reference
or directive.
2) In all other cases, it is just a '\'
VTL reference := a syntax element $<name> such that a <name>,Object pair
is found in the Context.
VTL directive := a control directive or a pluggable directive, currently
including #set, #if, #else, #elsif, #end, #foreach, #include, #parse,
#macro and #stop.
Examples :
With $foo in the Context, it is 'active':
$foo renders as <foo>
\$foo renders as \$foo
\\$foo renders as \<foo> (because it binds from the left)
\\\$foo renders as \\$foo
With $foo NOT in the context, it's just text:
$foo renders as $foo
\$foo renders as \$foo
\\$foo renders as \\$foo
Directives :
#include("a.txt") renders as <contents of a.txt>
\#include("a.txt") renders as \#include("a.txt")
\\#include("a.txt") renders as \<contents of a.txt>
etc
\#if(true) hi \#end renders as #if(true) hi #end
\\#if(true) hi \\#end renders as \ hi \
\\\#if(true) hi \\#end is a parsing error after 'hi' :) (because the #if
is escaped, so there is a #end just sitting there )
Take a look at test/templates/escape2.vm for more good examples.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> I just can't seem to think about escape's clearly in the morning.
>
> #\set and #\\set have the same problem that has plagued people
> implementing escape since the earth cooled... how do I get #\\set in the
> output? and then, how do I implement $\\\set, and then...
>
> So I am going forward with
> \$foo->$foo
> \\$foo -> \<foo>
> \\\$foo -> \$foo
>
> because while I really do like $\foo better, because of the symmetry
> with $!foo, we still have to implement $\foo, $\\foo, $\\\foo etc as a
> bind-from-the-left escape, and then Gunnar's obeservation about
> intuitiveness is 100% right, namely it isn't intuitive. He must have
> assumed that I wasn't an idiot and that I would remember that either way
> we have to support n or n+1 '\' characters if we want to be able to
> produce any desired output. But I didn't, and I expect he won't make
> _that_ mistake again :)
>
> So unless there is an even vaguely compelling argument why I shouldn't
> do this ( ("\\")*$ref ) I am going forward with it a little later after
> caffine has kicked in.
>
> Also, I will repeat what I felt was an important thing from this thread
> :
>
> I believe that something is a reference if and only
> if it has a value in the Context. Otherwise it is schmoo, with the
> exception of
> the $!<ref> construct. This is the way the current parser behaves.
>
> THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
>
> The following VTL :
> $foo
> $!foo
> #set $foo = "hi!"
> $foo
>
> outputs:
> $foo
>
> hi!
>
> (lets not argue about the blank line.... it is correct according to
> precise whitespace handling rules)
>
> I believe it is correct. You have the option of saying to the
> parser with $!foo : "Hey, if this isn't a ref, don't output anything"
> as
> well as "Hey, it's schmoo!" with $foo not backed by something in the
> Context.
>
> Another way: You can take any content, scatter in your VTL, and if
> there
> are and $foo type elements in the original material, you don't have to
> go back and escape them or something so they will appear as they are in
> the original content. So adding VTL is an 'active' thing on the
> designers part, whereas the 'passive' view says that any $foo is a
> reference. This is how WM behaves (or they have fixed it...), and I
> hated it.
>
> I think this discussion is helpful. I came into this project with some
> assumptions that all may not share, and I want to make sure that I am
> aligned with the group on this.
I'm quite happy with what's outlined here. I see no need for $\var
instead of \$var (in this case, symmetry be damned).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> I just can't seem to think about escape's clearly in the morning.
>
> #\set and #\\set have the same problem that has plagued people
> implementing escape since the earth cooled... how do I get #\\set in the
> output? and then, how do I implement $\\\set, and then...
>
> So I am going forward with
> \$foo->$foo
> \\$foo -> \<foo>
> \\\$foo -> \$foo
>
> because while I really do like $\foo better, because of the symmetry
> with $!foo, we still have to implement $\foo, $\\foo, $\\\foo etc as a
> bind-from-the-left escape, and then Gunnar's obeservation about
> intuitiveness is 100% right, namely it isn't intuitive. He must have
> assumed that I wasn't an idiot and that I would remember that either way
> we have to support n or n+1 '\' characters if we want to be able to
> produce any desired output. But I didn't, and I expect he won't make
> _that_ mistake again :)
>
> So unless there is an even vaguely compelling argument why I shouldn't
> do this ( ("\\")*$ref ) I am going forward with it a little later after
> caffine has kicked in.
>
> Also, I will repeat what I felt was an important thing from this thread
> :
>
> I believe that something is a reference if and only
> if it has a value in the Context. Otherwise it is schmoo, with the
> exception of
> the $!<ref> construct. This is the way the current parser behaves.
>
> THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
>
> The following VTL :
> $foo
> $!foo
> #set $foo = "hi!"
> $foo
>
> outputs:
> $foo
>
> hi!
>
> (lets not argue about the blank line.... it is correct according to
> precise whitespace handling rules)
>
> I believe it is correct. You have the option of saying to the
> parser with $!foo : "Hey, if this isn't a ref, don't output anything"
> as
> well as "Hey, it's schmoo!" with $foo not backed by something in the
> Context.
>
> Another way: You can take any content, scatter in your VTL, and if
> there
> are and $foo type elements in the original material, you don't have to
> go back and escape them or something so they will appear as they are in
> the original content. So adding VTL is an 'active' thing on the
> designers part, whereas the 'passive' view says that any $foo is a
> reference. This is how WM behaves (or they have fixed it...), and I
> hated it.
>
> I think this discussion is helpful. I came into this project with some
> assumptions that all may not share, and I want to make sure that I am
> aligned with the group on this.
I'm quite happy with what's outlined here. I see no need for $\var
instead of \$var (in this case, symmetry be damned).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I just can't seem to think about escape's clearly in the morning.
#\set and #\\set have the same problem that has plagued people
implementing escape since the earth cooled... how do I get #\\set in the
output? and then, how do I implement $\\\set, and then...
So I am going forward with
\$foo->$foo
\\$foo -> \<foo>
\\\$foo -> \$foo
because while I really do like $\foo better, because of the symmetry
with $!foo, we still have to implement $\foo, $\\foo, $\\\foo etc as a
bind-from-the-left escape, and then Gunnar's obeservation about
intuitiveness is 100% right, namely it isn't intuitive. He must have
assumed that I wasn't an idiot and that I would remember that either way
we have to support n or n+1 '\' characters if we want to be able to
produce any desired output. But I didn't, and I expect he won't make
_that_ mistake again :)
So unless there is an even vaguely compelling argument why I shouldn't
do this ( ("\\")*$ref ) I am going forward with it a little later after
caffine has kicked in.
Also, I will repeat what I felt was an important thing from this thread
:
I believe that something is a reference if and only
if it has a value in the Context. Otherwise it is schmoo, with the
exception of
the $!<ref> construct. This is the way the current parser behaves.
THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
The following VTL :
$foo
$!foo
#set $foo = "hi!"
$foo
outputs:
$foo
hi!
(lets not argue about the blank line.... it is correct according to
precise whitespace handling rules)
I believe it is correct. You have the option of saying to the
parser with $!foo : "Hey, if this isn't a ref, don't output anything"
as
well as "Hey, it's schmoo!" with $foo not backed by something in the
Context.
Another way: You can take any content, scatter in your VTL, and if
there
are and $foo type elements in the original material, you don't have to
go back and escape them or something so they will appear as they are in
the original content. So adding VTL is an 'active' thing on the
designers part, whereas the 'passive' view says that any $foo is a
reference. This is how WM behaves (or they have fixed it...), and I
hated it.
I think this discussion is helpful. I came into this project with some
assumptions that all may not share, and I want to make sure that I am
aligned with the group on this.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I just can't seem to think about escape's clearly in the morning.
#\set and #\\set have the same problem that has plagued people
implementing escape since the earth cooled... how do I get #\\set in the
output? and then, how do I implement $\\\set, and then...
So I am going forward with
\$foo->$foo
\\$foo -> \<foo>
\\\$foo -> \$foo
because while I really do like $\foo better, because of the symmetry
with $!foo, we still have to implement $\foo, $\\foo, $\\\foo etc as a
bind-from-the-left escape, and then Gunnar's obeservation about
intuitiveness is 100% right, namely it isn't intuitive. He must have
assumed that I wasn't an idiot and that I would remember that either way
we have to support n or n+1 '\' characters if we want to be able to
produce any desired output. But I didn't, and I expect he won't make
_that_ mistake again :)
So unless there is an even vaguely compelling argument why I shouldn't
do this ( ("\\")*$ref ) I am going forward with it a little later after
caffine has kicked in.
Also, I will repeat what I felt was an important thing from this thread
:
I believe that something is a reference if and only
if it has a value in the Context. Otherwise it is schmoo, with the
exception of
the $!<ref> construct. This is the way the current parser behaves.
THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
The following VTL :
$foo
$!foo
#set $foo = "hi!"
$foo
outputs:
$foo
hi!
(lets not argue about the blank line.... it is correct according to
precise whitespace handling rules)
I believe it is correct. You have the option of saying to the
parser with $!foo : "Hey, if this isn't a ref, don't output anything"
as
well as "Hey, it's schmoo!" with $foo not backed by something in the
Context.
Another way: You can take any content, scatter in your VTL, and if
there
are and $foo type elements in the original material, you don't have to
go back and escape them or something so they will appear as they are in
the original content. So adding VTL is an 'active' thing on the
designers part, whereas the 'passive' view says that any $foo is a
reference. This is how WM behaves (or they have fixed it...), and I
hated it.
I think this discussion is helpful. I came into this project with some
assumptions that all may not share, and I want to make sure that I am
aligned with the group on this.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
IMPORTANT STUFF BELOW!
Christoph Reck wrote:
>
> now you get a +1 if you include the 2c of John Castura.
> (having '$/bar' emit '$bar' in both undefined/defined cases).
I think $/bar emits $/bar in *all* cases since \ would be the escape :)
> Note that if the templater wants to ensure that the $-sign is
> emitted (since it is a VTL special character) then he should have
> to (post-)escape it.
Why? What about simply '$$foo'? (I will note that I have a bug and this
doesn't work :)
> Another trick to achieve the same would be to define:
> #set $d = "$"
> ${d}foo => $foo
> Thus doing away wholly with escaping ;)
That would work. These cases, I think, are very specific to debugging
and writing VTL documentation, aren't they? Are there other uses for
escaping VTL elements to literals?
And in HTML, you would just use the entity for '$', $ or something.
(Had to do that many a time in WM...)
> Geir Magnusson Jr. wrote:
> >
> > $\<reference> outputs $<reference> if a valid reference, $\<reference>
> > otherwise
>
> leave away the otherwise.
I can't! It's just plain schmoo if a person puts $\woogie into the
template and they don't have a reference behind it. That's the point
here : if something looks like a VTL element (ref or directive) but
isn't then it isn't, and should be output. Things become VTL by the
active act by the designer of putting in things that are 'backed' by the
context.
Everyone, this is important :
The point is that I believe that something is a reference if and only
if it has a
value in the Context. Otherwise it is schmoo, with the exception of
the $!<ref>
construct. This is the way the current parser behaves.
THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
The following VTL :
$foo
$!foo
#set $foo = "hi!"
$foo
outputs:
$foo
hi!
(lets not argue about the blank line.... it is correct according to
precise whitespace handling rules)
But I believe it is correct. You have the option of saying to the
parser with $!foo : "Hey, if this isn't a ref, don't output anything" as
well as "Hey, it's schmoo!" with $foo not backed by something in the
Context.
Another way: You can take any content, scatter in your VTL, and if there
are and $foo type elements in the original material, you don't have to
go back and escape them or something so they will appear as they are in
the original content. So adding VTL is an 'active' thing on the
designers part, whereas the 'passive' view says that any $foo is a
reference. This is how WM behaves (or they have fixed it...), and I
hated it.
Futher, if you want to output the literal representation of a valid VTL
reference (a real directive, or a context-backed reference), you have to
actively go do that $\foo ( or \\$foo depending on how that debate turns
out.)
> > #\<directive> outputs #<directive> if a valid directive, #\<directive>
> > other
>
> ditto, above.
No. (ditto above above :)
> > Isn't this a special-case use, for either writing Vel documentation or
> > debugging? Maybe I have the wrong idea about this... Hm.
>
> Also for any symbol loaded (HTML-)output, e.g. take a catalog with
> pricelists and serial numbers, eeky example:
> "<th>$\price</th><th>#\Item ID</th>".
Why not just do
<th>$Price</th><th>#ItemID</th>
See my point about non-VTL elements rendering as they are? :D Thanks
for the example!
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
IMPORTANT STUFF BELOW!
Christoph Reck wrote:
>
> now you get a +1 if you include the 2c of John Castura.
> (having '$/bar' emit '$bar' in both undefined/defined cases).
I think $/bar emits $/bar in *all* cases since \ would be the escape :)
> Note that if the templater wants to ensure that the $-sign is
> emitted (since it is a VTL special character) then he should have
> to (post-)escape it.
Why? What about simply '$$foo'? (I will note that I have a bug and this
doesn't work :)
> Another trick to achieve the same would be to define:
> #set $d = "$"
> ${d}foo => $foo
> Thus doing away wholly with escaping ;)
That would work. These cases, I think, are very specific to debugging
and writing VTL documentation, aren't they? Are there other uses for
escaping VTL elements to literals?
And in HTML, you would just use the entity for '$', $ or something.
(Had to do that many a time in WM...)
> Geir Magnusson Jr. wrote:
> >
> > $\<reference> outputs $<reference> if a valid reference, $\<reference>
> > otherwise
>
> leave away the otherwise.
I can't! It's just plain schmoo if a person puts $\woogie into the
template and they don't have a reference behind it. That's the point
here : if something looks like a VTL element (ref or directive) but
isn't then it isn't, and should be output. Things become VTL by the
active act by the designer of putting in things that are 'backed' by the
context.
Everyone, this is important :
The point is that I believe that something is a reference if and only
if it has a
value in the Context. Otherwise it is schmoo, with the exception of
the $!<ref>
construct. This is the way the current parser behaves.
THIS MAY BE AN ASSUMPTION ON MY PART THAT IS INCORRECT.
The following VTL :
$foo
$!foo
#set $foo = "hi!"
$foo
outputs:
$foo
hi!
(lets not argue about the blank line.... it is correct according to
precise whitespace handling rules)
But I believe it is correct. You have the option of saying to the
parser with $!foo : "Hey, if this isn't a ref, don't output anything" as
well as "Hey, it's schmoo!" with $foo not backed by something in the
Context.
Another way: You can take any content, scatter in your VTL, and if there
are and $foo type elements in the original material, you don't have to
go back and escape them or something so they will appear as they are in
the original content. So adding VTL is an 'active' thing on the
designers part, whereas the 'passive' view says that any $foo is a
reference. This is how WM behaves (or they have fixed it...), and I
hated it.
Futher, if you want to output the literal representation of a valid VTL
reference (a real directive, or a context-backed reference), you have to
actively go do that $\foo ( or \\$foo depending on how that debate turns
out.)
> > #\<directive> outputs #<directive> if a valid directive, #\<directive>
> > other
>
> ditto, above.
No. (ditto above above :)
> > Isn't this a special-case use, for either writing Vel documentation or
> > debugging? Maybe I have the wrong idea about this... Hm.
>
> Also for any symbol loaded (HTML-)output, e.g. take a catalog with
> pricelists and serial numbers, eeky example:
> "<th>$\price</th><th>#\Item ID</th>".
Why not just do
<th>$Price</th><th>#ItemID</th>
See my point about non-VTL elements rendering as they are? :D Thanks
for the example!
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: [PROPOSAL] Parser Update with COUNTERPROPOSAL
Posted by Christoph Reck <Ch...@dlr.de>.
now you get a +1 if you include the 2c of John Castura.
(having '$/bar' emit '$bar' in both undefined/defined cases).
Note that if the templater wants to ensure that the $-sign is
emitted (since it is a VTL special character) then he should have
to (post-)escape it.
Another trick to achieve the same would be to define:
#set $d = "$"
${d}foo => $foo
Thus doing away wholly with escaping ;)
Geir Magnusson Jr. wrote:
> I have a counter proposal that I feel gets us what we want, while :
>
> - preserving the intuition of programmers to escape with \
> - preserving the intuition of designers and content people that \ is a \.
> - keeping the number of magic characters / sequences for the parser to a
> minimum :
> $ implies reference
> # implies directive
>
> And I note that :
> - we already have the notion of 'modifier' in the '!' character which
> 'quiets' references as in $!foo
>
> so :
> Propose: simply to move the \ into the ref or macro as a 'modifier' just
> like ! for references
>
> $\<reference> outputs $<reference> if a valid reference, $\<reference>
> otherwise
leave away the otherwise.
> #\<directive> outputs #<directive> if a valid directive, #\<directive>
> other
ditto, above.
>
> just like :
>
> $!<reference> outputs $<reference> if a valid reference, nothing
> otherwise
>
> Beautiful symmetry (to me anyway :)
yes :)
>
> Working through the possiblities :
> - if you want to output \<refvalue> just use \$<reference>.
> - to output $foo when $foo is a reference, $\foo
> - to output $foo when $foo isn't a reference (therefore schmoo),
> $foo does it.
> - to output \$foo when $foo isn't a reference (there's that shmoo again...),
> \$foo does it
> - to output $$foo when $foo is a ref : $$\foo
> - am I missing anything?
>[snip]
> Isn't this a special-case use, for either writing Vel documentation or
> debugging? Maybe I have the wrong idea about this... Hm.
Also for any symbol loaded (HTML-)output, e.g. take a catalog with
pricelists and serial numbers, eeky example:
"<th>$\price</th><th>#\Item ID</th>".
:)
Christoph