You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Steven Hugg <hu...@fasterlight.com> on 2002/04/10 01:58:03 UTC
Whitespace, redux
I thought the time was ripe to tackle the albatross that is whitespace
handling, judging by the mail list archives :> It is one of my big
stumbling blocks with Velocity that prevents me from fully enjoying its
charms.
It occurs to me that a very simple rule could be added to solve many
whitespace problems:
* Given a text fragment between two directives, if it is entirely made up of
whitespace, do not output that fragment.
This would let you do things like this:
#if($fooCondition)
#**# whitespace tamed #**#
#end
Which would output " whitespace tamed ". If you omit the comments, it would
read like "\n whitespace tamed \n"
Easy, and probably could be done without even touching the parser. Also nice
because there is precedent -- I have never had a problem with whitespace
behavior in XSL, which has a similar option for gobbling whitespace.
What does everyone think-- can we do it?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/15/02 11:06 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> Hi,
>
> ... just thinking out loud ...
>
> The #output(...) solution seems OK, but is somewhat wordy to use
> for indented/structured #if/#set/#foreach constructs. That's why
> I've placed my proposal.
>
> Geir, if you choose to use it, consider an #output() ... #end
> constuct to restore previous state (the output directive without
> parameters). I guess there will be some problem having one
> directive form that requires an #end, and another without?
> But looking at the directive name #output() w/o paramters is
> somewhat misleading... maybe we can find a better name?
I'm not 'choosing' anything. I just see this as a deep issue that I'm not
sure any one of us can say what the definitive solution is or will be. So I
was going to try and hack out an #output(), push into whiteboard (or leave
it on my apache.org account so people can grab it), and then keep the
discussion going.
>
> Also It seems strange to have the #output(false) strip text
> schmoo in between. Any use for that? Maybe it is to much magic?
>
> That is why something like #stripspaces()...#end would look nicer.
> The opposite would be #literal()...#end.
>
> Again back to my proposal for the enhancing of the whitespace
> handling rules to do what a designer expects. Geir, is there
> a reason for a no-go?
We keep going through this - am I forgetting something? (The last few weeks
have been fairly exhausting...)
Doesn't only doing what a 'designer expects' move us further away from being
a 'clean' template engine?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"We will be judged not by the monuments we build, but by the monuments we
destroy" - Ada Louise Huxtable
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Hi,
... just thinking out loud ...
The #output(...) solution seems OK, but is somewhat wordy to use
for indented/structured #if/#set/#foreach constructs. That's why
I've placed my proposal.
Geir, if you choose to use it, consider an #output() ... #end
constuct to restore previous state (the output directive without
parameters). I guess there will be some problem having one
directive form that requires an #end, and another without?
But looking at the directive name #output() w/o paramters is
somewhat misleading... maybe we can find a better name?
Also It seems strange to have the #output(false) strip text
schmoo in between. Any use for that? Maybe it is to much magic?
That is why something like #stripspaces()...#end would look nicer.
The opposite would be #literal()...#end.
Again back to my proposal for the enhancing of the whitespace
handling rules to do what a designer expects. Geir, is there
a reason for a no-go?
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, April 11, 2002, 7:17:56 AM, Jim Rudnicki wrote:
[snip]
>> Despite of my previous letter I like this approach, but then Velocity
>> should support pluggable preprocessors... but see bellow.
> Maybe the first characters of the template can be
> #preprocess(net.mine.velocity.SpecificRulesTextTemplatePreprocessor)
I think it's +0.75. The problem here is that it is hard to remember
for the view designers. So I would like to specify a default
preprocessor class in the runtime config, and also *optionaly* bind a
preprocessors to extensions in the runtime config (overrides the
default), and then comes the #preprocess in the template which
overrides runtime config.
> Now just make a PreprocessingFileResourceLoader. It checks for the
> #preprocess() directive, and if present runs the remainder through the
> specified class.
Yes. Just would like to note again that text preprocessing with
resource loaders is incorrect (see earlier mail).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Jim Rudnicki <jd...@pacbell.net>.
> [snip]
> > This whole problem strikes me as something that is not an issue for the
> > parser at all. I like Geir's position that the parser just sees a
> character stream. To that end, it already does too much by eating some
line ends.
>
> Despite of my previous letter I like this approach, but then Velocity
> should support pluggable preprocessors... but see bellow.
Maybe the first characters of the template can be
#preprocess(net.mine.velocity.SpecificRulesTextTemplatePreprocessor)
Now just make a PreprocessingFileResourceLoader. It checks for the
#preprocess() directive, and if present runs the remainder through the
specified class.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Monday, April 15, 2002, 7:12:00 PM, Daniel Dekany wrote:
> On Monday, April 15, 2002 2:33 PM "Geir Magnusson Jr." <ge...@optonline.net>
> writen:
[snip]
> Who will write #output("off") and #output("on") for all #if, #else and #end
> when I enframe schomoo with them??? See the example below... to supress line
> feeds I need to write 2 additional #output-s per directive???
> #output("off")
> #if ($option1)
> #output("on")
> jadajada1
> jadajada1
> #output("off")
> #else
> #output("on")
> jadajada2
> jadajada2
> #output("off")
> #end
> #output("on")
Damn it!!! Bill, eat your ****** Outlook Express! I will
not use it anymore. So the example was:
#output("off")
#if ($option1)
#output("on")
jadajada1
jadajada1
#output("off")
#else
#output("on")
jadajada2
jadajada2
#output("off")
#end
#output("on")
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Peter Sojan <il...@gmx.net>.
> ... BOTH useless AND disturbing? I tend to specialize in the
> disturbing, but the integration to get useless in there is quite difficult
> to do in a seamless way.
;-)
Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Error Handling
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/15/02 7:09 AM, "Emyr James" <em...@OrbisUK.com> wrote:
> Dear all,
> I'm writing a servlet application using velocity under tomcat. At the moment
> I'm
> doing something like this...
>
> public class MyServlet extends VelocityServlet {
> public Template handleRequest( HttpServletRequest request,
> HttpServletResponse
> response, Context context ){
> Template template=null;
> try {
> //stuff that may throw an error
> } catch( Exception e ) {
> context.put("error",e.toString());
> try {
> template=getTemplate("error.vm");
> } catch( Exception ee ) {
> ee.printStackTrace();
> System.exit(0);
> }
> }
> return template;
>
> I want to make this complete by changing the System.exit(0) stuff to send
> stuff
> back on the servlets output stream directly, circumventing velocity entirely.
> How can I get access to this stuff so that the servlet behaves like a typical
> servlet under certain circumstances.
That's easy : just use the request/response objects as normal, and return
null.
When the baseclass sees the 'null' returned, it assumes you took care of the
request, and does nothing else.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Error Handling
Posted by Emyr James <em...@OrbisUK.com>.
Dear all,
I'm writing a servlet application using velocity under tomcat. At the moment I'm
doing something like this...
public class MyServlet extends VelocityServlet {
public Template handleRequest( HttpServletRequest request, HttpServletResponse
response, Context context ){
Template template=null;
try {
//stuff that may throw an error
} catch( Exception e ) {
context.put("error",e.toString());
try {
template=getTemplate("error.vm");
} catch( Exception ee ) {
ee.printStackTrace();
System.exit(0);
}
}
return template;
I want to make this complete by changing the System.exit(0) stuff to send stuff
back on the servlets output stream directly, circumventing velocity entirely.
How can I get access to this stuff so that the servlet behaves like a typical
servlet under certain circumstances.
Cheers,
Emyr
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Re[2]: Whitespace, redux
Posted by Kevin Baynes <kb...@seagullsw.com>.
I really like the pluggable preprocessor idea. It's flexible and backwards
compatible. Whitespace handling becomes a matter of choice.
An intriguing part is the ability to write preprocessors that can mimic
other widely used syntaxes: JSP, ASP, ColdFusion, PHP, etc.
If a company has designers that have been working in one of the other
syntaxes it would shorten the learning curve... Velocity would feel natural
because it could mimic their current working environment. Like skins, or
plug-ins.
Then the core can stay clean and simple, but is extensible. Think there
really should be an #output("on/off") directive? Fine, write it into your
preprocessor.
-------------------------------
Kevin Baynes
Software Engineer
SEAGULL Software
kbaynes at seagullsw dot com
> -----Original Message-----
> From: Daniel Dekany [mailto:ddekany@freemail.hu]
> Sent: Friday, April 19, 2002 1:45 PM
> To: Velocity Users List
> Subject: Re[2]: Whitespace, redux
>
>
> Friday, April 19, 2002, 5:44:47 PM, Christoph Reck wrote:
>
> > "Geir Magnusson Jr." wrote:
> >>
> >> On 4/19/02 11:05 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> >> > No, I would really hate those flags. In my proposal vm calls was NOT
> >> > directives, so read the ENBF with Directive+ as such. BTW I have
> >> > changed my mind. What about that the only think that gobbles
> >> > whitespace is: #if, #else, #elsif, #end, #set, #foreach,
> #stop, #macro
> >> > and comments (note that I have omitted #include and #parse).
> >> > Everything else prevents whitespace gobbling in its line. So instead
> >> > of Directive+ I say WhiteSpaceGobbler+.
> >
> > With flags i meant something within the AST nodes for the directives,
> > which you will just the same need if you want to mark the above
> > list as gobbling...
>
> You know the list of whitespace gobbler directives on compile time so
> it is really simple. What would be complicated, say, if we have a
> mechanism to flag user defined vm-s (gobble whitesapce or not to) or
> if we allow users to specify which directive gobbles whitespace but
> this is not the case here.
>
> >>
> >> Doesn't this just keep the problem but move it around a bit?
>
> As we know there is no ultimate solution even if we assume that we
> have HTML templates only (which is not the case). I only say that it
> is far better than the current rule, and also it is IMO somewhat
> better than the rule with "Directive". But read on...
>
> > So it seems to me.
> >
> > How do you avoid leading whitespaces from indented comments?
>
> If you look into the list of whitespace gobblers (WhiteSpaceGobbler+)
> then "comments" are there. But read on...
>
> > This is why I wanted it to be "Directive" without that "+", which
> [snip >:)]
>
> This debate just does not worth the bandwidth/time (I think many
> subscriber will agree). As I'm responsible for this cascade (again...)
> I would like to stop it here. So let it be "Directive" if you like it.
> This is somewhat matter of taste.
>
> Instead, IMO it would better to concentrate on the other subthread
> (OK, that was started by me too... sorry): No whitespace gobbling in
> the core, and add pluggable template preprocessors. No backward
> compatibility problems, no pollution of the core by application
> specific behavior (and miss-design... /-:), allows application/taste
> specific whitespace gobbling, and adds other functionality eg.:
> override default encoding (chatset) based on the content (<?xml ...
> encoding="..."?>), allows JSP-tag-like syntax, allows application
> specific escaping rules (IF we ever add #echo and allow #echo-ing
> non-visual characters...), etc.
>
> So if we would agree in it (no w.s. gobbling etc) then we could look
> into the pluggabe preprocessor proposal, and then everybody can use
> his/her favorite whitespace eater method. OK, a "standard"
> preprocessor for HTML/XML is still needed, and then let it be the
> Christoph Reck whitespace gobbler then, and implement that as a
> preprocessor. Anybody disagree with the Christoph Reck whitespace
> gobbler?
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, April 19, 2002, 5:44:47 PM, Christoph Reck wrote:
> "Geir Magnusson Jr." wrote:
>>
>> On 4/19/02 11:05 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
>> > No, I would really hate those flags. In my proposal vm calls was NOT
>> > directives, so read the ENBF with Directive+ as such. BTW I have
>> > changed my mind. What about that the only think that gobbles
>> > whitespace is: #if, #else, #elsif, #end, #set, #foreach, #stop, #macro
>> > and comments (note that I have omitted #include and #parse).
>> > Everything else prevents whitespace gobbling in its line. So instead
>> > of Directive+ I say WhiteSpaceGobbler+.
>
> With flags i meant something within the AST nodes for the directives,
> which you will just the same need if you want to mark the above
> list as gobbling...
You know the list of whitespace gobbler directives on compile time so
it is really simple. What would be complicated, say, if we have a
mechanism to flag user defined vm-s (gobble whitesapce or not to) or
if we allow users to specify which directive gobbles whitespace but
this is not the case here.
>>
>> Doesn't this just keep the problem but move it around a bit?
As we know there is no ultimate solution even if we assume that we
have HTML templates only (which is not the case). I only say that it
is far better than the current rule, and also it is IMO somewhat
better than the rule with "Directive". But read on...
> So it seems to me.
>
> How do you avoid leading whitespaces from indented comments?
If you look into the list of whitespace gobblers (WhiteSpaceGobbler+)
then "comments" are there. But read on...
> This is why I wanted it to be "Directive" without that "+", which
[snip >:)]
This debate just does not worth the bandwidth/time (I think many
subscriber will agree). As I'm responsible for this cascade (again...)
I would like to stop it here. So let it be "Directive" if you like it.
This is somewhat matter of taste.
Instead, IMO it would better to concentrate on the other subthread
(OK, that was started by me too... sorry): No whitespace gobbling in
the core, and add pluggable template preprocessors. No backward
compatibility problems, no pollution of the core by application
specific behavior (and miss-design... /-:), allows application/taste
specific whitespace gobbling, and adds other functionality eg.:
override default encoding (chatset) based on the content (<?xml ...
encoding="..."?>), allows JSP-tag-like syntax, allows application
specific escaping rules (IF we ever add #echo and allow #echo-ing
non-visual characters...), etc.
So if we would agree in it (no w.s. gobbling etc) then we could look
into the pluggabe preprocessor proposal, and then everybody can use
his/her favorite whitespace eater method. OK, a "standard"
preprocessor for HTML/XML is still needed, and then let it be the
Christoph Reck whitespace gobbler then, and implement that as a
preprocessor. Anybody disagree with the Christoph Reck whitespace
gobbler?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
"Geir Magnusson Jr." wrote:
>
> On 4/19/02 11:05 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> > No, I would really hate those flags. In my proposal vm calls was NOT
> > directives, so read the ENBF with Directive+ as such. BTW I have
> > changed my mind. What about that the only think that gobbles
> > whitespace is: #if, #else, #elsif, #end, #set, #foreach, #stop, #macro
> > and comments (note that I have omitted #include and #parse).
> > Everything else prevents whitespace gobbling in its line. So instead
> > of Directive+ I say WhiteSpaceGobbler+.
With flags i meant something within the AST nodes for the directives,
which you will just the same need if you want to mark the above
list as gobbling...
>
> Doesn't this just keep the problem but move it around a bit?
So it seems to me.
How do you avoid leading whitespaces from indented comments?
This is why I wanted it to be "Directive" without that "+", which
should include anything velocity handles that starts with a "#"
(including comments, macros, etc; bot not references). This way it
is symmetrical and simple.
OK to avoid the gobbling it would sometimes need either:
a) adding a #**# or #nop() on the line (call it a "hack" or
a neat side effect of the "Directive" rule form).
b) a directive like #keepspaces().
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/19/02 11:05 AM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> No, I would really hate those flags. In my proposal vm calls was NOT
> directives, so read the ENBF with Directive+ as such. BTW I have
> changed my mind. What about that the only think that gobbles
> whitespace is: #if, #else, #elsif, #end, #set, #foreach, #stop, #macro
> and comments (note that I have omitted #include and #parse).
> Everything else prevents whitespace gobbling in its line. So instead
> of Directive+ I say WhiteSpaceGobbler+.
>
Doesn't this just keep the problem but move it around a bit?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"The greatest pleasure in life is doing what people say you cannot do."
- Walter Bagehot
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, April 19, 2002, 1:04:14 PM, Christoph Reck wrote:
> Daniel Dekany wrote:
>>
[snip]
>> If you have something like this:
>>
>> <UL>
>> #incrementCounter()#li("Male")
>> #incrementCounter()#li("Female")
>> #incrementCounter()#li("Neither")
>> </UL>
>>
>> then nobody will belive that it will indent. And if you have a
>> dedicated directive to indent, then would not be cleaner to say
>> instead of Directive+ that NonIndentedDirective+?
>
> Does it indent or not? My rule states it will. As far as I used
> to understand your rule it would not, but below you're expanding
With Directive+ it will indent if #incrementCounter() is a vm call,
but will not indent if #incrementCounter() is a directive. If
#incrementCounter() is a vm call, then it will indent with both
Directive and Directive+.
> your rule with a statement that it will indent - inconsistent
> to your #sendSMS(...) example in previous mail.
I see may mistake was that I have used Velocity-like syntax there. So
again, those part with the sendSMS examples was about: What do people
want to gobble whitespace and what not (i.e. to be indented).
[snip]
> Wow! Is this really so?
> So then the AST-nodes for directives need a flag for the runtime
> to decide if it gobbles or not. Then macros, include, parse, and
> echo will be flagged to stop gobbling.
Ops! OK, now I see the big problem in our communication. In may
terminology vm calls are NOT directives. Perhaps in your EBNF
Directive matches to vm calls?
[snip]
>> > I mean: if "Directive+" greedingly gobbles whitespaces, how do you stop it?
>> > OK, an #echo(...) could explicetely be used.
>> > But look at my example above how I believe it could be handled when
>> > just "Directive" applies.
> I meant
> #echo("")#one()#or()#more() #directives() #end
Let say for now that vm-s are considered as directives. Both Direcive
and Direcive+ will stop whitespace (indent) gobbling here. No
difference.
> or
> #echo("#one()#or()#more() #directives() #end")
Let say for now that vm-s are considered as directives. Both Direcive
and Direcive+ will gobble the whitespace before the #echo here, and
neither will gobble the whitespace in the quoted thing. Again, no
difference.
>>
>> I don't understand what you mean. Neither line above will gobble
>> whitespace. Note that #foo above is a vm.
>>
>> <html>
>> #foo#include('xyz')
>> #if($bar)#foo#end
>> #if($bar)baaz#end
>> </html>
> (note: #foo() needs parenthesis otherwise its schmoo)
>
> If you state that macro calls should stop the "Directive+" gobbling,
> then thats right.
> No additional rule/statement needed to achieve this using plain "Directive".
But... no. When you use "Direcive" then you still should guess if that
1 directive or vm call should gobble whitespace or not. Your
argument is that you should not guess it, because the template writer
will put another "nop" vm call there, just to stop whitespace
gobbling! Don't you feel that it is very very awkward?
> Summary:
> If the "Directive+" for of the rule should work, we need to add a flag
> to directives that indicate gobbling desired (or a flag that indicates
> it may emit something - which would stop the gobbling). If others agree
> with this approach, I also can agree with your "Directive+" proposal.
No, I would really hate those flags. In my proposal vm calls was NOT
directives, so read the ENBF with Directive+ as such. BTW I have
changed my mind. What about that the only think that gobbles
whitespace is: #if, #else, #elsif, #end, #set, #foreach, #stop, #macro
and comments (note that I have omitted #include and #parse).
Everything else prevents whitespace gobbling in its line. So instead
of Directive+ I say WhiteSpaceGobbler+.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
OK, misunderstandings are clearing up...
My contributions to clear things up (as from my side) are embedded...
Daniel Dekany wrote:
>
> Friday, April 19, 2002, 10:44:46 AM, Christoph Reck wrote:
>
> > Daniel Dekany wrote:
> [snip]
> >> Some more explanation. The idea is that "non-visual" entities (flow
> >> control, etc) are whitespace eaters, while "visual" entities are not.
> >> Eg. if you have a <LI>-like entity, you want it not to eat
> >> whitespace:
> >>
> >> <UL>
> >> #li("Male")
> >> #li("Female")
> >> #li("Neither")
> >> </UL>
>
> > The rule with "Directive+" or just "Directive" would output the same:
>
> There is little misuderstading here. The whole "some more explanation"
> part of the mail was not about how "Directive+ preforms better as
> Directive in velocity", but about what do I think about whitespace
> gobbling. So the point is that you want to gobble whitespace in a line
> if you have there non-visual entities only, and you don't want to
> gobble whitespace if you have visual entities too.
Yup! these are the two point of views, and more clarity follows below...
>
> [snip]
> > <UL>
> > #indented()#li("Male")
> > #indented()#li("Female")
> > #indented()#li("Neither")
> > </UL>
> > and the latter would not work with the "Directive+" rule.
>
> This is a hack, which exploits an (IMO illogical) consequence of
> "Directive". This is a case where "Directive" happens accidentally
> work better.
That was exactly my pont. Geir also called it a "hack" ;D
> If you have something like this:
>
> <UL>
> #incrementCounter()#li("Male")
> #incrementCounter()#li("Female")
> #incrementCounter()#li("Neither")
> </UL>
>
> then nobody will belive that it will indent. And if you have a
> dedicated directive to indent, then would not be cleaner to say
> instead of Directive+ that NonIndentedDirective+?
Does it indent or not? My rule states it will. As far as I used
to understand your rule it would not, but below you're expanding
your rule with a statement that it will indent - inconsistent
to your #sendSMS(...) example in previous mail.
#incrementCounter is a clear directive that should be standalone
in a line accroding to most coding standards. Then it would not
indent. Neither would the remaining standalone #li(...) with both
our rules.
>
> But if you really need this hack, then if #indented is a Velocymacro
> call, then your example will work with Directive+ too!
Wow! Is this really so?
So then the AST-nodes for directives need a flag for the runtime
to decide if it gobbles or not. Then macros, include, parse, and
echo will be flagged to stop gobbling.
What hurts me with this is the "non-orthogonality" - it makes
exceptions to a simple rule: an #xyz... standalone in a line
gobbles, otherwise keep whitespaces.
>
> [snip]
> > I mean: if "Directive+" greedingly gobbles whitespaces, how do you stop it?
> > OK, an #echo(...) could explicetely be used.
> > But look at my example above how I believe it could be handled when
> > just "Directive" applies.
I meant
#echo("")#one()#or()#more() #directives() #end
or
#echo("#one()#or()#more() #directives() #end")
could be used to stop the indent gobbling.
>
> I don't understand what you mean. Neither line above will gobble
> whitespace. Note that #foo above is a vm.
>
> <html>
> #foo#include('xyz')
> #if($bar)#foo#end
> #if($bar)baaz#end
> </html>
(note: #foo() needs parenthesis otherwise its schmoo)
If you state that macro calls should stop the "Directive+" gobbling,
then thats right.
No additional rule/statement needed to achieve this using plain "Directive".
Summary:
If the "Directive+" for of the rule should work, we need to add a flag
to directives that indicate gobbling desired (or a flag that indicates
it may emit something - which would stop the gobbling). If others agree
with this approach, I also can agree with your "Directive+" proposal.
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Friday, April 19, 2002, 10:44:46 AM, Christoph Reck wrote:
> Daniel Dekany wrote:
[snip]
>> Some more explanation. The idea is that "non-visual" entities (flow
>> control, etc) are whitespace eaters, while "visual" entities are not.
>> Eg. if you have a <LI>-like entity, you want it not to eat
>> whitespace:
>>
>> <UL>
>> #li("Male")
>> #li("Female")
>> #li("Neither")
>> </UL>
> The rule with "Directive+" or just "Directive" would output the same:
There is little misuderstading here. The whole "some more explanation"
part of the mail was not about how "Directive+ preforms better as
Directive in velocity", but about what do I think about whitespace
gobbling. So the point is that you want to gobble whitespace in a line
if you have there non-visual entities only, and you don't want to
gobble whitespace if you have visual entities too.
[snip]
> <UL>
> #indented()#li("Male")
> #indented()#li("Female")
> #indented()#li("Neither")
> </UL>
> and the latter would not work with the "Directive+" rule.
This is a hack, which exploits an (IMO illogical) consequence of
"Directive". This is a case where "Directive" happens accidentally
work better. If you have something like this:
<UL>
#incrementCounter()#li("Male")
#incrementCounter()#li("Female")
#incrementCounter()#li("Neither")
</UL>
then nobody will belive that it will indent. And if you have a
dedicated directive to indent, then would not be cleaner to say
instead of Directive+ that NonIndentedDirective+?
But if you really need this hack, then if #indented is a Velocymacro
call, then your example will work with Directive+ too!
[snip]
> I mean: if "Directive+" greedingly gobbles whitespaces, how do you stop it?
> OK, an #echo(...) could explicetely be used.
> But look at my example above how I believe it could be handled when
> just "Directive" applies.
I don't understand what you mean. Neither line above will gobbles
whitespace. Note that #foo above is a vm.
<html>
#foo#include('xyz')
#if($bar)#foo#end
#if($bar)baaz#end
</html>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Daniel Dekany wrote:
>
> Wednesday, April 17, 2002, 9:08:11 AM, Christoph Reck wrote:
>
> > Daniel Dekany wrote:
> [snip]
> >> I see a very little problem here. Should not it be:
> >>
> >> DirectiveLine ::= LineEnd TabsAndSpaces? Directive+ TabsAndSpaces? LineEnd
> >>
> >> Note the "Directive+"
>
> > Nope, "Directive+" would:
>
> I disagree but it is an unimportant detail, so let it be "Directive"
> without "+" if you prefer that.
>
> But still, let me tell why I disagree with your arguments.
>
> > a) make the rule more complex
>
> (Well, this is perhaps just my twisted logic, but "Directive+" is the
> less special case, so it is simpler that "Directive" which is a subset
> (special case) of "Directive+". The rule with "Directive+" occupies
> less memory in my brain.)
This is relative to the POV.
>
> > b) I see a "directive between other directives" the same as
> > "directive within text schmoo" and thus embedded and not
> > standalone; therefore, it should leave the schmoo around
> > it untouched.
>
> Directives do not print to the output. Velocimacros do, but
> directives don't. (The introduction of an #echo-like directive could
> render this false, but then, what is if you have a line even with one
> whitespace surrounded #echo?) So why should one handle a directive (eg.
> an #end) similarly to a text schomoo?
In my original proposal about 1.5 years back, I thought of requiring
the directive to specify if it gobbles or not (#macro-calls, #parse,
#include would be nice if they do not gobble), but with a simple
#keepIndent()#callMacro()
trick (and "Directive" without the "+") you can live with it. (I have
several multi-line macros that require indenting, e.g.:
#macro(td $indent $text)
$indent<td align="top">
$indent $text
$indent</td>
#end
...
## and this will produce nice output:
<table>
<tr>
#td(" " $foo)
</tr>
</table>
>
> Some more explanation. The idea is that "non-visual" entities (flow
> control, etc) are whitespace eaters, while "visual" entities are not.
> Eg. if you have a <LI>-like entity, you want it not to eat
> whitespace:
>
> <UL>
> #li("Male")
> #li("Female")
> #li("Neither")
> </UL>
The rule with "Directive+" or just "Directive" would output the same:
<UL>
<li>Male</li>
<li>Female</li>
<li>Neither</li>
</UL>
To get what anyone would want and expect, I would do:
<UL>
#li(" " "Male")
#li(" " "Female")
#li(" " "Neither")
</UL>
or
<UL>
#indented()#li("Male")
#indented()#li("Female")
#indented()#li("Neither")
</UL>
and the latter would not work with the "Directive+" rule.
>
> while for non-visual entities you want to eat whitespace:
>
> #* Should gobble all whitespace *#
> #if($wantNotify)
> #sendSMS("30122445", "page visited")
> #end
Ditto with just "Directive".
>
> even if they are in one pack:
>
> #* Should gobble all whitespace *#
> #if($foo)
> #if($wantNotify)#sendSMS("30122445", "page visited")#end
> #end
This is not using any coding standards, and thus you cannot
imply any handling.
Put the #sendSMS(...) in its own line, then it is structured,
clean and would do what you expect.
>
> This is something that in practice cannot be solved in compile (parse)
> time (since you can't tell if #sendSMS or #li is a visual entity or
> not), and require runtime decisions about whitespace gobbling. A far
> too expensive solution... so I don't think velocity should implement
> it, but I think that "Directive+" gives a more similar behavior
> compared to "Directive".
I think I gave good examples above why "Directive" outperforms "Directive+".
>
> > The coding conventions for Java in many projects (even Jakarta
> > land) require that the curly brackets be on its own line:
> > if( foo )
> > {
> > // block
> > }
> > Applying this to vel, it means that standalone directives
> > shall really be in its own line.
>
> True. This is why I think it is an unimportant issue.
The same unimportantness as the unstructured #sendSMS(...) example.
>
> > c) be in the way of marking whitespaces around a directive to go through.
>
> Sorry? (My English is too weak.)
I mean: if "Directive+" greedingly gobbles whitespaces, how do you stop it?
OK, an #echo(...) could explicetely be used.
But look at my example above how I believe it could be handled when
just "Directive" applies.
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Wednesday, April 17, 2002, 9:08:11 AM, Christoph Reck wrote:
> Daniel Dekany wrote:
[snip]
>> I see a very little problem here. Should not it be:
>>
>> DirectiveLine ::= LineEnd TabsAndSpaces? Directive+ TabsAndSpaces? LineEnd
>>
>> Note the "Directive+"
> Nope, "Directive+" would:
I disagree but it is an unimportant detail, so let it be "Directive"
without "+" if you prefer that.
But still, let me tell why I disagree with your arguments.
> a) make the rule more complex
(Well, this is perhaps just my twisted logic, but "Directive+" is the
less special case, so it is simpler that "Directive" which is a subset
(special case) of "Directive+". The rule with "Directive+" occupies
less memory in my brain.)
> b) I see a "directive between other directives" the same as
> "directive within text schmoo" and thus embedded and not
> standalone; therefore, it should leave the schmoo around
> it untouched.
Directives do not print to the output. Velocimacros do, but
directives don't. (The introduction of an #echo-like directive could
render this false, but then, what is if you have a line even with one
whitespace surrounded #echo?) So why should one handle a directive (eg.
an #end) similarly to a text schomoo?
Some more explanation. The idea is that "non-visual" entities (flow
control, etc) are whitespace eaters, while "visual" entities are not.
Eg. if you have a <LI>-like entity, you want it not to eat
whitespace:
<UL>
#li("Male")
#li("Female")
#li("Neither")
</UL>
while for non-visual entities you want to eat whitespace:
#* Should gobble all whitespace *#
#if($wantNotify)
#sendSMS("30122445", "page visited")
#end
even if they are in one pack:
#* Should gobble all whitespace *#
#if($foo)
#if($wantNotify)#sendSMS("30122445", "page visited")#end
#end
This is something that in practice cannot be solved in compile (parse)
time (since you can't tell if #sendSMS or #li is a visual entity or
not), and require runtime decisions about whitespace gobbling. A far
too expensive solution... so I don't think velocity should implement
it, but I think that "Directive+" gives a more similar behavior
compared to "Directive".
> The coding conventions for Java in many projects (even Jakarta
> land) require that the curly brackets be on its own line:
> if( foo )
> {
> // block
> }
> Applying this to vel, it means that standalone directives
> shall really be in its own line.
True. This is why I think it is an unimportant issue.
> c) be in the way of marking whitespaces around a directive to go through.
Sorry? (My English is too weak.)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Daniel Dekany wrote:
>
> Tuesday, April 16, 2002, 7:18:56 PM, Christoph Reck wrote:
>
> > Anyone (within those thousands of eyes and brains) out there sees soemthing
> > wrong with my proposed (update of Daniel Dekany proposal):
> >
> > If a line is looks like this:
> > DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> > TabsAndSpaces ::= (#x20 | #x09)+
> > LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
>
> I see a very little problem here. Should not it be:
>
> DirectiveLine ::= LineEnd TabsAndSpaces? Directive+ TabsAndSpaces? LineEnd
>
> Note the "Directive+"
Nope, "Directive+" would:
a) make the rule more complex
b) I see a "directive between other directives" the same as
"directive within text schmoo" and thus embedded and not
standalone; therefore, it should leave the schmoo around
it untouched.
The coding conventions for Java in many projects (even Jakarta
land) require that the curly brackets be on its own line:
if( foo )
{
// block
}
Applying this to vel, it means that standalone directives
shall really be in its own line.
c) be in the way of marking whitespaces around a directive to go through.
There is an error in what I wanted to say in my BNF: indented comments
should be handled just like directives. So here an update:
If a line is looks like this:
DirectiveLine ::= LineEnd TabsAndSpaces? Markup TabsAndSpaces? LineEnd
TabsAndSpaces ::= (#x20 | #x09)+
LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
Markup ::= Directive | ## | Multi-line-comment
Multi-line-comment ::= (#**? ((#x0D #x0A) | #x0D | #x0A) *?*#)
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Tuesday, April 16, 2002, 7:18:56 PM, Christoph Reck wrote:
> Anyone (within those thousands of eyes and brains) out there sees soemthing
> wrong with my proposed (update of Daniel Dekany proposal):
>
> If a line is looks like this:
> DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> TabsAndSpaces ::= (#x20 | #x09)+
> LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
I see a very little problem here. Should not it be:
DirectiveLine ::= LineEnd TabsAndSpaces? Directive+ TabsAndSpaces? LineEnd
Note the "Directive+"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/19/02 4:20 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> "Geir Magnusson Jr." wrote:
>>
>> On 4/16/02 1:18 PM, "Christoph Reck" <Ch...@dlr.de> wrote:
>>
>>>
>>> Anyone (within those thousands of eyes and brains) out there sees soemthing
>>> wrong with my proposed (update of Daniel Dekany proposal):
>>>
>>> If a line is looks like this:
>>> DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
>>> TabsAndSpaces ::= (#x20 | #x09)+
>>> LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
>>> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
>>> should be gobbled. (Note that it supports multiline directives, that is
>>> why "DirectiveLine" is not simply "Line".) If you whant the first
>>> "LineEnd" to be gobbled prepend a ## before it (it is part of the
>>> previous line!).
>>>
>>> I guess this is the nearest we can get a perfect solution.
>>
>> I seem to be on the path to having this work, sort of. I'll post a jar that
>> does this soon so we can play and decide if we really want to do this. I
>> still don't think we want to.
>
> Great!
> (but for some weeks I won't be able to test it, busy with Swing application
> - anyway I'll be using it in the future, it is an important issue and thats
> why I'm taking the trouble to find a proper solution. For my past 4 velocity
> applications I used the comment-escaping and indenting workaround).
And for my past 'N' major projects involving velocity, I didn't have to do
squat...
>>
>>>
>>> It has a *very* small (but defined) impact on existing templates:
>>> existing standalone directives will gobble leading whitespaces
>>> (currently they gobble trailing whitespaces).
>>> This does not make things more convoluted, but makes it simpler
>>> and orthogonal.
>>
>> Not sure I agree with the last sentence... I am not sure I even understand
>> the last sentence.
>
> Orthogonal means right-angled, so same in both directions.
> In velocity: I'm referring that it acts the same in both directions -
> gobble not only trailing whitespaces but handle leading ones also
> equally.
Hm - if something is orthogonal, it means that it's different - it goes in a
completely different direction. In terms of some kind of decomposition to
basis vectors, two orthogonal vectors share nothing in common...
>
> Orthogonal color components means that the 3 colors are at right angle
> in a 3D space; changing a component value does not affect the others
> - e.g. RGB, HSV, etc.
> In this sense, changing the whitespace handling in velocity should not
> affect other (velocity-) functionality.
>
> Orthogonal command set in a CPU means that a command can be applied
> to any operand and register. This was the great improvement of a
> 68000 (early MAC) and RISC vs. Intel and other CPUs. An "add" could
> be done on any two registers, not only with the accumulator. A
> pre/post-increment after any operation with any register, not only
> with the counter register, etc.
> In velocity: the whitespace handling should be the same for EVERY
> directive, not different for an #end, #set, #parse, etc.
>
> With orthogonal I mean "describe once and use/apply everywhere in a
> symmetrical form". KISS and you know what you will get.
>
> Does this make sense now?
I think you might have meant to say 'symmetric' or 'internally
self-consistent'...
:)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The obvious solutions are challenging
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
"Geir Magnusson Jr." wrote:
>
> On 4/16/02 1:18 PM, "Christoph Reck" <Ch...@dlr.de> wrote:
>
> >
> > Anyone (within those thousands of eyes and brains) out there sees soemthing
> > wrong with my proposed (update of Daniel Dekany proposal):
> >
> > If a line is looks like this:
> > DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> > TabsAndSpaces ::= (#x20 | #x09)+
> > LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
> > then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> > should be gobbled. (Note that it supports multiline directives, that is
> > why "DirectiveLine" is not simply "Line".) If you whant the first
> > "LineEnd" to be gobbled prepend a ## before it (it is part of the
> > previous line!).
> >
> > I guess this is the nearest we can get a perfect solution.
>
> I seem to be on the path to having this work, sort of. I'll post a jar that
> does this soon so we can play and decide if we really want to do this. I
> still don't think we want to.
Great!
(but for some weeks I won't be able to test it, busy with Swing application
- anyway I'll be using it in the future, it is an important issue and thats
why I'm taking the trouble to find a proper solution. For my past 4 velocity
applications I used the comment-escaping and indenting workaround).
>
> >
> > It has a *very* small (but defined) impact on existing templates:
> > existing standalone directives will gobble leading whitespaces
> > (currently they gobble trailing whitespaces).
> > This does not make things more convoluted, but makes it simpler
> > and orthogonal.
>
> Not sure I agree with the last sentence... I am not sure I even understand
> the last sentence.
Orthogonal means right-angled, so same in both directions.
In velocity: I'm referring that it acts the same in both directions -
gobble not only trailing whitespaces but handle leading ones also
equally.
Orthogonal color components means that the 3 colors are at right angle
in a 3D space; changing a component value does not affect the others
- e.g. RGB, HSV, etc.
In this sense, changing the whitespace handling in velocity should not
affect other (velocity-) functionality.
Orthogonal command set in a CPU means that a command can be applied
to any operand and register. This was the great improvement of a
68000 (early MAC) and RISC vs. Intel and other CPUs. An "add" could
be done on any two registers, not only with the accumulator. A
pre/post-increment after any operation with any register, not only
with the counter register, etc.
In velocity: the whitespace handling should be the same for EVERY
directive, not different for an #end, #set, #parse, etc.
With orthogonal I mean "describe once and use/apply everywhere in a
symmetrical form". KISS and you know what you will get.
Does this make sense now?
>
> > Geir, for character stream users that cannot predict if important
> > spaces will follow a NL, they should just put a #**# upfront any
> > directive to inhibit gobbling.
>
> I really wouldn't advocate that as a solution to anyone... It's just
> downright bizarre... The problem is that streams tend to be mechanically
> generated - you might get content from some news feed (ok, that wouldn't be
> marked up...) but you also might produce content mechanically from XSLT or
> DVSL or something. I have a client that produces 'velocitized' content this
> way, and believe that others must too....
XSLT has similar whitespace handling problems, but also some mechanisms
to control them (not very elegant as presented early in this thread).
The whitespace handling problem is imminent to template processing
and needs clear rules and override mechanisms.
Currently the only override mechanism velocity provides is
#* *# indent escaping with comments #*
*# comments including EOL
and ## eol escaping.
and this is also not very elegant.
Adding my proposed symmetrical rule, plus maybe a #keepspaces directive
would solve 99.99% of all problems ans still be elegant.
>[snip]
> > Only the #output(true|false|"hold") thread
> > raised another possible approach, but as others stated it does not
> > solve the problem of proper whitespace handling and can get to be a
> > PITA when doing structured constructs in templates.
>
> I'll take issue with the phrase 'proper whitespace handling' as I think the
> definition of 'proper' is what we are arguing about.
yeah, thats the point.
>
> I agree that #output() would be a PITA for certain things, but it certainly
> is a nice way to solve a whole raft of issues, including removing whole
> blocks of code for debugging.
Thats another issue.
#keepspaces() vs. #gobblespaces() is the issue here.
>
> > I'm trying to obtain a consensus to resolve velocitys stray whitespace
> > problem.
> >
> > Herewith I'm requesting everyone that sees *real* problems with the
> > proposal should yell up. Others that second my proposal should vote
> > a +1 even though they are not committers (nope - this should not
> > lead to a revolution to the jakarta rules).
>
> Getting a sense of what people want is the right thing. I am not really
> sure that what you want is the Right Thing - but I am trying it to see how
> it will work...
Great.
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, April 18, 2002, 7:05:45 PM, Denis wrote:
[snip]
>> this just an unimportant detail here.) The problem with this approach
>> is that it is a paradox. You can't parse the template without
>> preprocessing, so you can't read the entries which chose the
>> preprocessor. E.g. if you template is Base64 encoded (for no good
>> reason...), and the preprocessor should decode it, Velocity can't
>> understand the template without the preprocessor.
>
> No paradox that fuzzy logic can't solve ;-)
>
> Let's suppose there is a predefined preprocessor manager.
>
> If the parser encounters #preprocessor("RAW"), what can stop
> Velocity from asking the pp manager to switch hands to the "RAW"
> preprocessor?
>
> AFAIK there is no need to look-ahead for a directive. In Java, if I
> have a Reader 'first', I use it to read 200 bytes. Then I create a
> 'second = new MyReader(first)', it will carry on reading at the
> 201th byte won't it?
> Technically, it looks like I can switch preprocessor while reading
> the template.
Yes. As I said it is possible to write pp (pp manager) which does
this, but there are situations where it is not possible. However it is
possible in the 99.9% of cases. So we can discuss about a "standard"
pp manager which will satisfy most users, and in that 0.1% user can
use his/her own preprocessor. I only say that IMO preprocessor
choosing logic should not be in the Velocity core.
BTW: For XML files, the preprocessor can read the <?xml ...?> line,
and if you look into the p.p. proposal the you can see that the
preprocessor can chose encoding (charset) based on the encoding
specified there. Yeah! :)
So how should the "standard" pp manager looks like. I would like to
note that we are too hurry here, since not even the preprocessor idea
is accepted by the community (and last not least, by Geir).
<standard_pp_proposal state="very early draft">
The StandardPreprocessor does nothing but instantiates other
preprocessors and dispatch the work to those preprocessors. Note that
it uses a preprocessor instance pool. The std pp chose a preprocessor
based on the resource name, then it can be overridden in the very
first line of template with:
StartOfStream '#preprocessor(' preprocessor_name ')' NewLine|EndOfStream.
In the runtime config there is only one property that the Velocity
core defines, it is: "preprocessor.class". Here we specify the
standard pp class. Then we can put preprocessor specific properties
into the config. Namely:
- "preprocessor.std.priority" = preprocessor priority list. Mandatory.
- "preprocessor.std." + preprocessor_name ".class" = pp class. Mandatory.
- "preprocessor.std." + preprocessor_name ".mask" = resource name mask.
Optional. When omitted you can choose this pp with #preprocessor only.
- "preprocessor.std." + preprocessor_name ".checkFistLine" =
true/false. Optional. When omitted, it is considered as true.
Eg.:
-------------
preprocessor.class = org.apache.velocity.app.preprocessor.StandardPreprocessor
# StandardPreprocessor specific:
preprocessor.std.priority = xml;html;rtf;raw
preprocessor.std.raw.class = com.foo.velocity.RawPreprocessor
preprocessor.std.raw.mask = *
preprocessor.std.xml.class = com.foo.velocity.XmlPreprocessor
preprocessor.std.xml.mask = *.xml;*.xls;*.wml;
preprocessor.std.html.class = com.foo.velocity.HtmlPreprocessor
preprocessor.std.html.mask = *.htm;*.html
preprocessor.std.rtf.class = com.foo.velocity.RtfPreprocessor
preprocessor.std.rtf.mask = *.rtf
-------------
Based on preprocessor.std.priority the StandardPreprocessor checks
first if the resource name is xml, then if it is html, etc. Unless the
checkFirstLine for the chosen preprocessor is false,
StandardPreprocessor will check if the first line of the template is
'#preprocessor(' preprocessor_name ')' and if it is, then it will
skip that line and dispatch the work to the pp named there.
</standard_pp_proposal>
> The example you gave (Base64 encoded) suggests there should be some
> mechanism to chain preprocessors. That's something for the pp
> manager probably.
[snip]
Yes, and as I have written in the Pluggable Preprocessor Proposal
thread, it is easy to chain arbitrary preprocessors by the pp manager.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Denis <ji...@respublica.fr>.
> (Well, IMO it should not be #set, but rather #preprocessor("foo"), but
> this just an unimportant detail here.) The problem with this approach
> is that it is a paradox. You can't parse the template without
> preprocessing, so you can't read the entries which chose the
> preprocessor. E.g. if you template is Base64 encoded (for no good
> reason...), and the preprocessor should decode it, Velocity can't
> understand the template without the preprocessor.
No paradox that fuzzy logic can't solve ;-)
Let's suppose there is a predefined preprocessor manager.
If the parser encounters #preprocessor("RAW"), what can stop
Velocity from asking the pp manager to switch hands to the "RAW"
preprocessor?
AFAIK there is no need to look-ahead for a directive. In Java, if I
have a Reader 'first', I use it to read 200 bytes. Then I create a
'second = new MyReader(first)', it will carry on reading at the
201th byte won't it?
Technically, it looks like I can switch preprocessor while reading
the template.
The example you gave (Base64 encoded) suggests there should be some
mechanism to chain preprocessors. That's something for the pp
manager probably.
Cheers,
-- Denis.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[4]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, April 18, 2002, 12:23:41 PM, Denis wrote:
>> Geir, what about this: Remove whitespace
>> gobbling from the "core", add pluggable preprocessor support, and then
>> pack two preprocessor classes with the Velocity releases:
>>
>> - CompatibilityPreprocessor: A preprocessor which gobbles whitespace
>> exactly like old velocity (I mean velocity 1.3 here) did.
>>
>> - SGMLPreprocessor: A preprocessor which gobbles whitespace based on
>> the method proposed by Christoph and me. This is for HTML/XML maker
>> users.
>>
>> and then let the CompatibilityPreprocessor by the default in the
>> org\apache\velocity\runtime\velocity.properties:
>> preprocessor.class =
>> org.apache.velocity.app.preprocessor.CompatibilityPreprocessor
>>
>>
>> Ideas? Votes? Come on! :)
>
> "Immediate satisfaction" solution!
> +1
>
> There is still the issue on how we decide which preprocessor to use
> though. The designer wants to set it in the template (?), the programmer
> doesn't care and the 'deployer' wants it application-specific.
Yes. I have started earlier a "Pluggable Preprocessor Proposal" thread
and there I have given a possible answer on this issue. So the idea is
that from the view point of Velocity there is exactly one preprocessor
instance per Velocity engine instance. But that instance can act as a
dispatcher to other preprocessors. So you allow application developer
to develop his/her own Preprocessor, which is *maybe* a dispatcher to
other preprocessors. E.g. it chooses a preprocessor instance depending
on the file extension. It's the matter of creativity of developer. By
this, you remove the "which preprocessor to use" issue from the
Velocity core.
This does not mean that you have to "reinvent the wheel" again and
again, since widely usable "dispatcher preprocessors" can be placed
into org.apache.velocity.app.preprocessor package.
> What if one can name a set of preprocessor in the config files, then the
> designer can switch easily between them with a directive:
>
> #set($format = "RAW")
> #set($format = "GobbleWhitespace")
> #set($format = "XMLFile")
(Well, IMO it should not be #set, but rather #preprocessor("foo"), but
this just an unimportant detail here.) The problem with this approach
is that it is a paradox. You can't parse the template without
preprocessing, so you can't read the entries which chose the
preprocessor. E.g. if you template is Base64 encoded (for no good
reason...), and the preprocessor should decode it, Velocity can't
understand the template without the preprocessor.
However it can be useful in many situations if you can chose
preprocessor based on the content of template, but IMO it is not
solvable in a general way. So I say that let it leave to the
preprocessor. You can write a preprocessor which reads the first line
of the template, and if it found "#preprocessor('foo')" there, then it
will continue preprocessing in 'foo' mode.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[2]: Whitespace, redux
Posted by Denis <ji...@respublica.fr>.
> Geir, what about this: Remove whitespace
> gobbling from the "core", add pluggable preprocessor support, and then
> pack two preprocessor classes with the Velocity releases:
>
> - CompatibilityPreprocessor: A preprocessor which gobbles whitespace
> exactly like old velocity (I mean velocity 1.3 here) did.
>
> - SGMLPreprocessor: A preprocessor which gobbles whitespace based on
> the method proposed by Christoph and me. This is for HTML/XML maker
> users.
>
> and then let the CompatibilityPreprocessor by the default in the
> org\apache\velocity\runtime\velocity.properties:
> preprocessor.class =
> org.apache.velocity.app.preprocessor.CompatibilityPreprocessor
>
>
> Ideas? Votes? Come on! :)
"Immediate satisfaction" solution!
+1
There is still the issue on how we decide which preprocessor to use
though. The designer wants to set it in the template (?), the programmer
doesn't care and the 'deployer' wants it application-specific.
What if one can name a set of preprocessor in the config files, then the
designer can switch easily between them with a directive:
#set($format = "RAW")
#set($format = "GobbleWhitespace")
#set($format = "XMLFile")
-- Denis.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, April 18, 2002, 2:40:48 AM, Tim Colson wrote:
> Christoph said:
>> Only the #output(true|false|"hold") thread
>> raised another possible approach, but as others stated it does not
>> solve the problem of proper whitespace handling and can get to be a
>> PITA when doing structured constructs in templates.
> Geir:
>> I'll take issue with the phrase 'proper whitespace handling'
>> as I think the definition of 'proper' is what we are arguing about.
> Indeed.
> And just for the record, darned if I know what the proper way really
> should be :-)
> It changes for me day to day depending on the templates desired output
> content type.
[snip]
So what to do then. I think the desirable behavior would be if
Velocity does not gobble whitespace at all, and if velocity supports
pluggable template preprocessors. So the plugged template
preprocessors can (among other tasks) gobble whitespace in an
application specific (content type specific) way. But unfortunately
it's too late now, since Velocity already does gobble whitespace, and
we want backward compatibility. However I see an escape from the evil
backward compatibility. Geir, what about this: Remove whitespace
gobbling from the "core", add pluggable preprocessor support, and then
pack two preprocessor classes with the Velocity releases:
- CompatibilityPreprocessor: A preprocessor which gobbles whitespace
exactly like old velocity (I mean velocity 1.3 here) did.
- SGMLPreprocessor: A preprocessor which gobbles whitespace based on
the method proposed by Christoph and me. This is for HTML/XML maker
users.
and then let the CompatibilityPreprocessor by the default in the
org\apache\velocity\runtime\velocity.properties:
preprocessor.class = org.apache.velocity.app.preprocessor.CompatibilityPreprocessor
Ideas? Votes? Come on! :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Tim Colson <tc...@cisco.com>.
Christoph said:
> Only the #output(true|false|"hold") thread
> raised another possible approach, but as others stated it does not
> solve the problem of proper whitespace handling and can get to be a
> PITA when doing structured constructs in templates.
Geir:
> I'll take issue with the phrase 'proper whitespace handling'
> as I think the definition of 'proper' is what we are arguing about.
Indeed.
And just for the record, darned if I know what the proper way really
should be :-)
It changes for me day to day depending on the templates desired output
content type.
There seems to be a big difference especially between content types that
mostly ignore whitespace those that are highly sensitive to whitespace
for formatting.
Geir continued:
> I agree that #output() would be a PITA for certain things,
> but it certainly is a nice way to solve a whole raft of issues,
> including removing whole blocks of code for debugging.
Assuming for a minute this design was chosen (I'm a fan, I think, maybe,
today...), I believe Christoph has a sound point saying there are still
whitespace issues to consider.
Christoph quipped:
> [Revised whitespace gobbling rule] does not make things more
convoluted,
> but makes it simpler and orthogonal.
Geir replied:
>I am not sure I even understand the last sentence.
I am Vroomfondel! And I demand that I do not understand that sentence
either! <grin>
(Please check out Websters.com for 'orthogonal' and HHGTHG for
Vroomfondel http://www.geocities.com/Area51/2202/vroom.htm)
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/16/02 1:18 PM, "Christoph Reck" <Ch...@dlr.de> wrote:
>
> Anyone (within those thousands of eyes and brains) out there sees soemthing
> wrong with my proposed (update of Daniel Dekany proposal):
>
> If a line is looks like this:
> DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> TabsAndSpaces ::= (#x20 | #x09)+
> LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> should be gobbled. (Note that it supports multiline directives, that is
> why "DirectiveLine" is not simply "Line".) If you whant the first
> "LineEnd" to be gobbled prepend a ## before it (it is part of the
> previous line!).
>
> I guess this is the nearest we can get a perfect solution.
I seem to be on the path to having this work, sort of. I'll post a jar that
does this soon so we can play and decide if we really want to do this. I
still don't think we want to.
>
> It has a *very* small (but defined) impact on existing templates:
> existing standalone directives will gobble leading whitespaces
> (currently they gobble trailing whitespaces).
> This does not make things more convoluted, but makes it simpler
> and orthogonal.
Not sure I agree with the last sentence... I am not sure I even understand
the last sentence.
> Geir, for character stream users that cannot predict if important
> spaces will follow a NL, they should just put a #**# upfront any
> directive to inhibit gobbling.
I really wouldn't advocate that as a solution to anyone... It's just
downright bizarre... The problem is that streams tend to be mechanically
generated - you might get content from some news feed (ok, that wouldn't be
marked up...) but you also might produce content mechanically from XSLT or
DVSL or something. I have a client that produces 'velocitized' content this
way, and believe that others must too....
>
>>> Again back to my proposal for the enhancing of the whitespace
>>> handling rules to do what a designer expects. Geir, is there
>>> a reason for a no-go?
>
>> We keep going through this - am I forgetting something? (The last few weeks
>> have been fairly exhausting...)
>
> Geir, I don't know how many (Jakarta + others) lists you are
> subscribed, but the commons-list is saturating enough!
Only in bursts, it seems, and I always seem to wind up on the losing end...
> I don't see you forgetting anything, but I'm pointing out that my
> proposal is just getting responses that are "beating around the bush"
> without getting anywhere.
I don't understand this sentence.
> Only the #output(true|false|"hold") thread
> raised another possible approach, but as others stated it does not
> solve the problem of proper whitespace handling and can get to be a
> PITA when doing structured constructs in templates.
I'll take issue with the phrase 'proper whitespace handling' as I think the
definition of 'proper' is what we are arguing about.
I agree that #output() would be a PITA for certain things, but it certainly
is a nice way to solve a whole raft of issues, including removing whole
blocks of code for debugging.
> I'm trying to obtain a consensus to resolve velocitys stray whitespace
> problem.
>
> Herewith I'm requesting everyone that sees *real* problems with the
> proposal should yell up. Others that second my proposal should vote
> a +1 even though they are not committers (nope - this should not
> lead to a revolution to the jakarta rules).
Getting a sense of what people want is the right thing. I am not really
sure that what you want is the Right Thing - but I am trying it to see how
it will work...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Hi again,
"Geir Magnusson Jr." wrote:
>[snip]
> I certainly understand the need, I certainly want to find a solution,
> but I am not going to help break stuff or make things even more convoluted.
> Velocity isn't perfect, but I think we have a situation where there is no
> perfect solution - but we will find the best that we can. It may not be
> yours - it many not be mine - but we'll find one.
>[snip]
Anyone (within those thousands of eyes and brains) out there sees soemthing
wrong with my proposed (update of Daniel Dekany proposal):
If a line is looks like this:
DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
TabsAndSpaces ::= (#x20 | #x09)+
LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
should be gobbled. (Note that it supports multiline directives, that is
why "DirectiveLine" is not simply "Line".) If you whant the first
"LineEnd" to be gobbled prepend a ## before it (it is part of the
previous line!).
I guess this is the nearest we can get a perfect solution.
It has a *very* small (but defined) impact on existing templates:
existing standalone directives will gobble leading whitespaces
(currently they gobble trailing whitespaces).
This does not make things more convoluted, but makes it simpler
and orthogonal.
Geir, for character stream users that cannot predict if important
spaces will follow a NL, they should just put a #**# upfront any
directive to inhibit gobbling.
> > Again back to my proposal for the enhancing of the whitespace
> > handling rules to do what a designer expects. Geir, is there
> > a reason for a no-go?
> We keep going through this - am I forgetting something? (The last few weeks
> have been fairly exhausting...)
Geir, I don't know how many (Jakarta + others) lists you are
subscribed, but the commons-list is saturating enough!
I don't see you forgetting anything, but I'm pointing out that my
proposal is just getting responses that are "beating around the bush"
without getting anywhere. Only the #output(true|false|"hold") thread
raised another possible approach, but as others stated it does not
solve the problem of proper whitespace handling and can get to be a
PITA when doing structured constructs in templates.
I'm trying to obtain a consensus to resolve velocitys stray whitespace
problem.
Herewith I'm requesting everyone that sees *real* problems with the
proposal should yell up. Others that second my proposal should vote
a +1 even though they are not committers (nope - this should not
lead to a revolution to the jakarta rules).
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/15/02 1:12 PM, "Daniel Dekany" <dd...@freemail.hu> wrote:
> On Monday, April 15, 2002 2:33 PM "Geir Magnusson Jr." <ge...@optonline.net>
> writen:
>
> [snip]
>>> #output("off")
>>> #if ($option1)
>>> #echo("hello")
>>> #else
>>> #echo("goodbye")
>>> #end
>>> #output("on") ## restoring output
>>>
>>
>> This is *damn* cute. :) Further, I would bet that this could be done
>> completely outside of the Velocity core. No, not "yet another wet-blanket
> [snip]
>
> For those of you who don't know:
>
> ***
> VELOCITY ALREADY GOBBLES WHITESPACE FOR A LONG TIME!
You don't have to shout. Believe it or not, many of us had an idea about
this stuff long before you showed up - we understand the problems and are
concerned.
> However it does it in a really *useless* and *disturbing* way.
And some, I am *sure*, don't appreciate the tone. There are plenty of
reasons why things were done - do you think we went out of our way to make
something that was BOTH useless AND disturbing? I tend to specialize in the
disturbing, but the integration to get useless in there is quite difficult
to do in a seamless way.
> (Eg. it gobbles whitespace around #set but does not gobble whitespace around
> #if)
> ***
>
> Geir. Why don't you fix the current whitespace gobbling rules first? Why why
> why? Or if you don't want to then disable whitespace gobbling.
The problem is that
1) We don't want to break existing things
2) We don't want to jump into yet another problematic behavior.
The ideal solution is something where xformations are pluggable or
determined by designer. Personally, I can't figure which is better.
Pluggable is nice and transparent, but now separate from the template. In
hands of designer is, of course, not transparent.
>
> And what do I think about #output("off")... IMO
> #output("off")/#output("on") can be a very useful directive but it does not
> solve the problem what whitespace gobbling should.
In my opinion, specific whitespace gobbling algorithms just to make HTML
authors happy isn't something that Velocity should do. I certainly
understand the need, I certainly want to find a solution, but I am not going
to help break stuff or make things even more convoluted. Velocity isn't
perfect, but I think we have a situation where there is no perfect solution
- but we will find the best that we can. It may not be yours - it many not
be mine - but we'll find one.
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
My inner cowboy needs to yodel.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
On Monday, April 15, 2002 2:33 PM "Geir Magnusson Jr." <ge...@optonline.net>
writen:
[snip]
> > #output("off")
> > #if ($option1)
> > #echo("hello")
> > #else
> > #echo("goodbye")
> > #end
> > #output("on") ## restoring output
> >
>
> This is *damn* cute. :) Further, I would bet that this could be done
> completely outside of the Velocity core. No, not "yet another wet-blanket
[snip]
For those of you who don't know:
***
VELOCITY ALREADY GOBBLES WHITESPACE FOR A LONG TIME!
However it does it in a really *useless* and *disturbing* way.
(Eg. it gobbles whitespace around #set but does not gobble whitespace around
#if)
***
Geir. Why don't you fix the current whitespace gobbling rules first? Why why
why? Or if you don't want to then disable whitespace gobbling.
And what do I think about #output("off")... IMO
#output("off")/#output("on") can be a very useful directive but it does not
solve the problem what whitespace gobbling should.
Who will write #output("off") and #output("on") for all #if, #else and #end
when I enframe schomoo with them??? See the example below... to supress line
feeds I need to write 2 additional #output-s per directive???
#output("off")
#if ($option1)
#output("on")
jadajada1
jadajada1
#output("off")
#else
#output("on")
jadajada2
jadajada2
#output("off")
#end
#output("on")
And let's see the original example:
#if ($option1)
#echo("hello")
#else
#echo("goodbye")
#end
Do you think that here I want to print: CR LF SPACE SPACE 'hello' CR LF?
Very likely I don't. So is it practical to write out that #output("off") and
#output("on")?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Tim Colson <tc...@cisco.com>.
Geir wrote:
> Well, it doesn't impose any One True Whitespace Rule :)
Agreed. That's the tricky issue with everyone's suggestions on "The
Rule", and so I can understand why this issue has/will take a long time
to address.
> Not chopped liver, but it is slightly different. It's not
> just whitespace off, but *output* off.
> So that approach can be used for more than just the whitespace issues.
Doh! Actually - it isn't different, I just fub'd the explanation. :-)
The Cold Fusion tag was actually <CF_SETTING EnableCFOutputOnly="YES"> -
but if I'd used that in my Nov. example, I'm was worried folks would
have ignored the post.
Obviously by switching to a combo of #space_off + #out(), I confused the
issue of whitespace handling and engine output. :-(
Thanks Joaquim for clearly stating what I meant to say. :-)
+1
BTW - there would still be The One Rule, it would just be far less
complmex, i.e.
"If you type it, the engine will output it. No gobbling."
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/15/02 11:45 AM, "Tim Colson" <tc...@cisco.com> wrote:
>
>> On 4/13/02 5:35 AM, "Joaquim Carvalho" <jr...@bookmarc.pt> wrote:
> ... about explicitly turning on/off whitespace gobbling by Velocity,
> coupled with an explicit way to 'print' ouput using "#echo"
>
> Geir replied to this approach:
>> This is *damn* cute. :)
>
> ...which is far more warmth than -most- other suggestions on how to
> gobble whitespace according to a set of complex rules.
Well, it doesn't impose any One True Whitespace Rule :)
>
>
> Uh, no slight meant to Joaquim, but am I chopped liver!?? <grin>
>
> From Nov 2001 - pretty much the exact same idea. ;-)
> http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg04134.ht
> ml
Not chopped liver, but it is slightly different. It's not just whitespace
off, but *output* off.
So that approach can be used for more than just the whitespace issues.
For example
#output($debugOutput)
#end
:)
> And more recently from March 2002 (see #gobblewhitespace(off) )
> http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg05992.ht
> ml
>
>
>> 3. In macros and #parsed templates it is necessary to save
>> and restore the previous output status so that other templates can
>> safely use code in other files:
>>
>> #output("hold") ## Sames as "off" but the current output state is
>> remembered
>
> This additional idea is worth it's weight in latinum!
I always wondered how Farengi reconciled their rules of trade with
technological design....
> I always had this problem with "included" pages in Cold Fusion, and this
> would be such a simple way to overcome that.
> +1
>
>
> BTW - for all the folks worried about templates looking JSP-ish, I
> wouldn't worry too much.
>
> I estimate that in 90% of our templates, extra whitespace can be ignored
> and so #output("off") (or #spaces_off or #gobblewhitespace("off")
> <grin>) wouldn't be needed. But for the few times when whitespace is
> realllly important, it can be explicitly output.
>
> Cheers! :-)
> Timo
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Tim Colson <tc...@cisco.com>.
> On 4/13/02 5:35 AM, "Joaquim Carvalho" <jr...@bookmarc.pt> wrote:
... about explicitly turning on/off whitespace gobbling by Velocity,
coupled with an explicit way to 'print' ouput using "#echo"
Geir replied to this approach:
> This is *damn* cute. :)
...which is far more warmth than -most- other suggestions on how to
gobble whitespace according to a set of complex rules.
Uh, no slight meant to Joaquim, but am I chopped liver!?? <grin>
>From Nov 2001 - pretty much the exact same idea. ;-)
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg04134.ht
ml
And more recently from March 2002 (see #gobblewhitespace(off) )
http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg05992.ht
ml
> 3. In macros and #parsed templates it is necessary to save
> and restore the previous output status so that other templates can
> safely use code in other files:
>
> #output("hold") ## Sames as "off" but the current output state is
> remembered
This additional idea is worth it's weight in latinum!
I always had this problem with "included" pages in Cold Fusion, and this
would be such a simple way to overcome that.
+1
BTW - for all the folks worried about templates looking JSP-ish, I
wouldn't worry too much.
I estimate that in 90% of our templates, extra whitespace can be ignored
and so #output("off") (or #spaces_off or #gobblewhitespace("off")
<grin>) wouldn't be needed. But for the few times when whitespace is
realllly important, it can be explicitly output.
Cheers! :-)
Timo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/13/02 5:35 AM, "Joaquim Carvalho" <jr...@bookmarc.pt> wrote:
>
> I have worked a long time ago in a templating language for web apps used
> in house for over 5 years.
>
> We had a similar whitespace problem (control flow directives created
> zones on the templates that produced undesired white space on the
> output).
>
> The solution we found was to add two whitespace related directives,
> "output" and "echo", that in Velocity would look something like this:
>
> 1. "output" switches output on and off (this applies to ALL output from
> the template to the output stream)
>
> #output("off") ## from now on there is no output from the template but
> the enclosed directives still are executed
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("on") ## restoring output
> $a
>
>
> 2.After a #output("off") text could be forced to the output stream by
> using #echo:
>
> #output("off")
> #if ($option1)
> #echo("hello")
> #else
> #echo("goodbye")
> #end
> #output("on") ## restoring output
>
This is *damn* cute. :) Further, I would bet that this could be done
completely outside of the Velocity core. No, not "yet another wet-blanket
attempt by Geir" :) but certainly we could evaluate this approach
independent of changes to the core.
> 3. In macros and #parsed templates it is necessary to save and restore
> the previous output status so that other templates can safely use code
> in other files:
>
>
> $macro ( testOption, $option1)
>
> #output("hold") ## Sames as "off" but the current output state is
> remembered
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("restore") ## restoring output to previous status
> #end
>
>
Good - I was thinking that you might always want to restore previous state,
but I guess the downside is that you could get into trouble by forgetting.
Still...
>
> this has dealt with our whitespace handling problems for good. When
> writing sequences of directives, specially involving control structures
> that need to be indented for readability we just backet that part of the
> template with #output("off") #output("on") with an ocasional #echo
> inside if something needs to go out the stream.
And with #echo("...") you would get full Velocity interpolation in the
output :
#echo("Hello $foo : #woogie($bar)")
>
> This also is nice for Velocity usage just as aruntime scripting
> language not related to any type of outputing. We are using Velocity
> right now in such a setting: a bibliographic application needs to do
> some manipulation of library records according to transformation rules
> that are defined at runtime. By adding specially designed objects to the
> context we can use velocity as the rule language and templates just
> specify how an object is transformed into another one. The output from
> the template is irrelevant, so we could just as well avoida its
> production.
>
> As far as velocity goes I think such a solution would be backwards
> compatible; an implicit #output("on") is assumed for evey template (but
> not for the parsed ones).
>
> I think even if a template using #output and #echo would find itself
> being rendered by an older version of Velocity it would still work, I
> think, because #output and #echo would just be ignored (although of
> course the ouput would not be quite the desired one).
>
> This is not a request for modification, just a contribution to the
> discussion.
And a good one. Thanks!
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"The greatest pleasure in life is doing what people say you cannot do."
- Walter Bagehot
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Paulo Gaspar <pa...@krankikom.de>.
Looks simple and elegant.
=:o)
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Joaquim Carvalho [mailto:jrc@bookmarc.pt]
> Sent: Saturday, April 13, 2002 11:36 AM
> To: Velocity Users List
> Subject: Re: Whitespace, redux
>
>
>
> I have worked a long time ago in a templating language for web apps used
> in house for over 5 years.
>
> We had a similar whitespace problem (control flow directives created
> zones on the templates that produced undesired white space on the
> output).
>
> The solution we found was to add two whitespace related directives,
> "output" and "echo", that in Velocity would look something like this:
>
> 1. "output" switches output on and off (this applies to ALL output from
> the template to the output stream)
>
> #output("off") ## from now on there is no output from the template but
> the enclosed directives still are executed
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("on") ## restoring output
> $a
>
>
> 2.After a #output("off") text could be forced to the output stream by
> using #echo:
>
> #output("off")
> #if ($option1)
> #echo("hello")
> #else
> #echo("goodbye")
> #end
> #output("on") ## restoring output
>
> 3. In macros and #parsed templates it is necessary to save and restore
> the previous output status so that other templates can safely use code
> in other files:
>
>
> $macro ( testOption, $option1)
>
> #output("hold") ## Sames as "off" but the current output state is
> remembered
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("restore") ## restoring output to previous status
> #end
>
>
>
> this has dealt with our whitespace handling problems for good. When
> writing sequences of directives, specially involving control structures
> that need to be indented for readability we just backet that part of the
> template with #output("off") #output("on") with an ocasional #echo
> inside if something needs to go out the stream.
>
> This also is nice for Velocity usage just as aruntime scripting
> language not related to any type of outputing. We are using Velocity
> right now in such a setting: a bibliographic application needs to do
> some manipulation of library records according to transformation rules
> that are defined at runtime. By adding specially designed objects to the
> context we can use velocity as the rule language and templates just
> specify how an object is transformed into another one. The output from
> the template is irrelevant, so we could just as well avoida its
> production.
>
> As far as velocity goes I think such a solution would be backwards
> compatible; an implicit #output("on") is assumed for evey template (but
> not for the parsed ones).
>
> I think even if a template using #output and #echo would find itself
> being rendered by an older version of Velocity it would still work, I
> think, because #output and #echo would just be ignored (although of
> course the ouput would not be quite the desired one).
>
> This is not a request for modification, just a contribution to the
> discussion.
>
> Joaquim
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/15/02 6:55 AM, "Peter Romianowski" <me...@gmx.de> wrote:
> Hi there,
>
> I have to say the whitespace problem is the ONE which
> I would love to see fixed (in any way). It's the (only)
> "PITA" :) with it from the very beginning...
> And I think that a <? ?> solution would be great.
> Although the #output("off") - thing would perhaps be more
> in the velocity-style.
The cool thing about the #output()/#echo() is that it appears to solve quite
a few problems at once.
Now, I haven't played with it, and still have some suspicions, but I
certainly am going to implement it (outside of Vel core) and see what
happens.
The use of a preprocessor of some type also may be a solution but moves
control away from the designer. Note, the preprocessor idea is a specific
usecase for the more general input/output filters that we have discussed
since the earth cooled....
Also, I have been playing (just playing) with AST xformations. Again, an
interesting approach, but also has the downside that the control is taken
away from the designer.
Hm. Much to consider.
> And since the use of it would be optional, you would not
> break anything...
>
> Are there plans on implementing such thing at all? I see
> discussions about that come and go for a while now...
>
> Having such a thing would make velocity REALLY the best
> choice over JSP and stuff!
:)
>--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Peter Romianowski <me...@gmx.de>.
Hi there,
I have to say the whitespace problem is the ONE which
I would love to see fixed (in any way). It's the (only)
"PITA" :) with it from the very beginning...
And I think that a <? ?> solution would be great.
Although the #output("off") - thing would perhaps be more
in the velocity-style.
And since the use of it would be optional, you would not
break anything...
Are there plans on implementing such thing at all? I see
discussions about that come and go for a while now...
Having such a thing would make velocity REALLY the best
choice over JSP and stuff!
Peter
> -----Original Message-----
> From: Huy Do [mailto:huy@tramada.com.au]
> Sent: Monday, April 15, 2002 12:53 AM
> To: Velocity Users List
> Subject: RE: Whitespace, redux
>
>
> This is starting to look a bit like
>
> <?
> if ($option1) {
> $a = "hello"
> } else {
> $a = "goodbye"
> }
> echo("$a")
> ?>
>
> and replace the <? with <% (don't mind the syntax) and look what we have.
> Hope we're not going backwards now :-)
>
> Huy
>
> > -----Original Message-----
> > From: Joaquim Carvalho [mailto:jrc@bookmarc.pt]
> > Sent: Saturday, 13 April 2002 7:36 PM
> > To: Velocity Users List
> > Subject: Re: Whitespace, redux
> >
> >
> >
> > I have worked a long time ago in a templating language for web apps used
> > in house for over 5 years.
> >
> > We had a similar whitespace problem (control flow directives created
> > zones on the templates that produced undesired white space on the
> > output).
> >
> > The solution we found was to add two whitespace related directives,
> > "output" and "echo", that in Velocity would look something like this:
> >
> > 1. "output" switches output on and off (this applies to ALL output from
> > the template to the output stream)
> >
> > #output("off") ## from now on there is no output from the template but
> > the enclosed directives still are executed
> > #if ($option1)
> > #set( $a = "hello")
> > #else
> > #set($a = "goodbye")
> > #end
> > #output("on") ## restoring output
> > $a>
> >
> > 2.After a #output("off") text could be forced to the output stream by
> > using #echo:
> >
> > #output("off")
> > #if ($option1)
> > #echo("hello")
> > #else
> > #echo("goodbye")
> > #end
> > #output("on") ## restoring output
> >
> > 3. In macros and #parsed templates it is necessary to save and restore
> > the previous output status so that other templates can safely use code
> > in other files:
> >
> >
> > $macro ( testOption, $option1)
> >
> > #output("hold") ## Sames as "off" but the current output state is
> > remembered
> > #if ($option1)
> > #set( $a = "hello")
> > #else
> > #set($a = "goodbye")
> > #end
> > #output("restore") ## restoring output to previous status
> > #end
> >
> >
> >
> > this has dealt with our whitespace handling problems for good. When
> > writing sequences of directives, specially involving control structures
> > that need to be indented for readability we just backet that part of the
> > template with #output("off") #output("on") with an ocasional #echo
> > inside if something needs to go out the stream.
> >
> > This also is nice for Velocity usage just as aruntime scripting
> > language not related to any type of outputing. We are using Velocity
> > right now in such a setting: a bibliographic application needs to do
> > some manipulation of library records according to transformation rules
> > that are defined at runtime. By adding specially designed objects to the
> > context we can use velocity as the rule language and templates just
> > specify how an object is transformed into another one. The output from
> > the template is irrelevant, so we could just as well avoida its
> > production.
> >
> > As far as velocity goes I think such a solution would be backwards
> > compatible; an implicit #output("on") is assumed for evey template (but
> > not for the parsed ones).
> >
> > I think even if a template using #output and #echo would find itself
> > being rendered by an older version of Velocity it would still work, I
> > think, because #output and #echo would just be ignored (although of
> > course the ouput would not be quite the desired one).
> >
> > This is not a request for modification, just a contribution to the
> > discussion.
> >
> > Joaquim
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Huy Do <hu...@tramada.com.au>.
This is starting to look a bit like
<?
if ($option1) {
$a = "hello"
} else {
$a = "goodbye"
}
echo("$a")
?>
and replace the <? with <% (don't mind the syntax) and look what we have.
Hope we're not going backwards now :-)
Huy
> -----Original Message-----
> From: Joaquim Carvalho [mailto:jrc@bookmarc.pt]
> Sent: Saturday, 13 April 2002 7:36 PM
> To: Velocity Users List
> Subject: Re: Whitespace, redux
>
>
>
> I have worked a long time ago in a templating language for web apps used
> in house for over 5 years.
>
> We had a similar whitespace problem (control flow directives created
> zones on the templates that produced undesired white space on the
> output).
>
> The solution we found was to add two whitespace related directives,
> "output" and "echo", that in Velocity would look something like this:
>
> 1. "output" switches output on and off (this applies to ALL output from
> the template to the output stream)
>
> #output("off") ## from now on there is no output from the template but
> the enclosed directives still are executed
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("on") ## restoring output
> $a>
>
> 2.After a #output("off") text could be forced to the output stream by
> using #echo:
>
> #output("off")
> #if ($option1)
> #echo("hello")
> #else
> #echo("goodbye")
> #end
> #output("on") ## restoring output
>
> 3. In macros and #parsed templates it is necessary to save and restore
> the previous output status so that other templates can safely use code
> in other files:
>
>
> $macro ( testOption, $option1)
>
> #output("hold") ## Sames as "off" but the current output state is
> remembered
> #if ($option1)
> #set( $a = "hello")
> #else
> #set($a = "goodbye")
> #end
> #output("restore") ## restoring output to previous status
> #end
>
>
>
> this has dealt with our whitespace handling problems for good. When
> writing sequences of directives, specially involving control structures
> that need to be indented for readability we just backet that part of the
> template with #output("off") #output("on") with an ocasional #echo
> inside if something needs to go out the stream.
>
> This also is nice for Velocity usage just as aruntime scripting
> language not related to any type of outputing. We are using Velocity
> right now in such a setting: a bibliographic application needs to do
> some manipulation of library records according to transformation rules
> that are defined at runtime. By adding specially designed objects to the
> context we can use velocity as the rule language and templates just
> specify how an object is transformed into another one. The output from
> the template is irrelevant, so we could just as well avoida its
> production.
>
> As far as velocity goes I think such a solution would be backwards
> compatible; an implicit #output("on") is assumed for evey template (but
> not for the parsed ones).
>
> I think even if a template using #output and #echo would find itself
> being rendered by an older version of Velocity it would still work, I
> think, because #output and #echo would just be ignored (although of
> course the ouput would not be quite the desired one).
>
> This is not a request for modification, just a contribution to the
> discussion.
>
> Joaquim
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Joaquim Carvalho <jr...@bookmarc.pt>.
I have worked a long time ago in a templating language for web apps used
in house for over 5 years.
We had a similar whitespace problem (control flow directives created
zones on the templates that produced undesired white space on the
output).
The solution we found was to add two whitespace related directives,
"output" and "echo", that in Velocity would look something like this:
1. "output" switches output on and off (this applies to ALL output from
the template to the output stream)
#output("off") ## from now on there is no output from the template but
the enclosed directives still are executed
#if ($option1)
#set( $a = "hello")
#else
#set($a = "goodbye")
#end
#output("on") ## restoring output
$a
2.After a #output("off") text could be forced to the output stream by
using #echo:
#output("off")
#if ($option1)
#echo("hello")
#else
#echo("goodbye")
#end
#output("on") ## restoring output
3. In macros and #parsed templates it is necessary to save and restore
the previous output status so that other templates can safely use code
in other files:
$macro ( testOption, $option1)
#output("hold") ## Sames as "off" but the current output state is
remembered
#if ($option1)
#set( $a = "hello")
#else
#set($a = "goodbye")
#end
#output("restore") ## restoring output to previous status
#end
this has dealt with our whitespace handling problems for good. When
writing sequences of directives, specially involving control structures
that need to be indented for readability we just backet that part of the
template with #output("off") #output("on") with an ocasional #echo
inside if something needs to go out the stream.
This also is nice for Velocity usage just as aruntime scripting
language not related to any type of outputing. We are using Velocity
right now in such a setting: a bibliographic application needs to do
some manipulation of library records according to transformation rules
that are defined at runtime. By adding specially designed objects to the
context we can use velocity as the rule language and templates just
specify how an object is transformed into another one. The output from
the template is irrelevant, so we could just as well avoida its
production.
As far as velocity goes I think such a solution would be backwards
compatible; an implicit #output("on") is assumed for evey template (but
not for the parsed ones).
I think even if a template using #output and #echo would find itself
being rendered by an older version of Velocity it would still work, I
think, because #output and #echo would just be ignored (although of
course the ouput would not be quite the desired one).
This is not a request for modification, just a contribution to the
discussion.
Joaquim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Denis <ji...@respublica.fr>.
+1 for this proposition.
Advantages:
* backward-compatibility --set the default preprocessor to
"CompatibilityPP" and no modification to templates/code is needed
* allows different policies depending on the needs
* allows different policies according to the type of template (in
the same app)
* easy to implement
* still efficient
-- Denis.
On Wednesday, April 10, 2002, at 11:20 pm, Daniel Dekany wrote:
> I think the solution would be pluggable template preprocessors.
> This will be
> useful for implementing JSP custom tag style tool calls too.
> I have looked into the soruce code (sorry if I have misinterpreted
> it, this
> was just a quick action...) and the Template class I see this:
>
> is = resourceLoader.getResourceStream(name);
> ... // snip
> BufferedReader br = new BufferedReader( new InputStreamReader( is,
> encoding ) );
> data = rsvc.parse( br, name);
>
> My idea with pseudo code is that:
>
> BufferedReader br = new BufferedReader(myPluggabeParser.getReader
> ( is,
> encoding ) );
>
> where the myPluggabeParser comes from the runtime configuration.
> So that I
> can preprocess templates in a obvious and efficient way.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Jim Rudnicki" <jd...@pacbell.net>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Wednesday, April 10, 2002 10:50 AM
[snip]
> This whole problem strikes me as something that is not an issue for the
> parser at all. I like Geir's position that the parser just sees a
character
> stream. To that end, it already does too much by eating some line ends.
Despite of my previous letter I like this approach, but then Velocity
should support pluggable preprocessors... but see bellow.
> You're problem and many other similar ones could be resolved with a
> preprocessor that converts from what the developer likes to type to what
the
> parser should see. Couldn't this easily be done with a
> MyWhitespaceResolvingFileResourceLoader ? With this approach everyone who
> needs to have their own code format be interpreted as something else just
> make a JoeSmoesFileResourceLoader.
[snip]
The problem here is that you try to do the preprocessing with the resource
loader. This is IMO awkward since resource loader is to load raw byte
streams, and it should not deal with the meaning of that byte stream. One
problem caused by this is that you have to know the charset of temaplate or
else you can't interprete and preprocess it. And AFAIK this (i.e. choosing
the charset) hapens independently of the resource loader. Then, you still
must return a byte stream so you have to encode the text back to byte
stream.
I think the solution would be pluggable template preprocessors. This will be
useful for implementing JSP custom tag style tool calls too.
I have looked into the soruce code (sorry if I have misinterpreted it, this
was just a quick action...) and the Template class I see this:
is = resourceLoader.getResourceStream(name);
... // snip
BufferedReader br = new BufferedReader( new InputStreamReader( is,
encoding ) );
data = rsvc.parse( br, name);
My idea with pseudo code is that:
BufferedReader br = new BufferedReader(myPluggabeParser.getReader( is,
encoding ) );
where the myPluggabeParser comes from the runtime configuration. So that I
can preprocess templates in a obvious and efficient way.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Jim Rudnicki <jd...@pacbell.net>.
> I thought the time was ripe to tackle the albatross that is whitespace
> handling, judging by the mail list archives :> It is one of my big
> stumbling blocks with Velocity that prevents me from fully enjoying its
> charms.
Steven,
Since you are up to do something, have you considered the following
approach:
In your template you typed this, for example:
#macro ( foo $a $b )
#if($a)
#if($b)
a and b
#else
a
#end
#end
But, you really wish the parser to see this:
#macro( foo $a $b )#if($a)#if($b)a and b#elsea#end#end
You would have typed the second macro, but it makes you sick to look at it.
It seems to me the essence is just that: the developer can't tolerate to
type what the parser should see.
This whole problem strikes me as something that is not an issue for the
parser at all. I like Geir's position that the parser just sees a character
stream. To that end, it already does too much by eating some line ends.
You're problem and many other similar ones could be resolved with a
preprocessor that converts from what the developer likes to type to what the
parser should see. Couldn't this easily be done with a
MyWhitespaceResolvingFileResourceLoader ? With this approach everyone who
needs to have their own code format be interpreted as something else just
make a JoeSmoesFileResourceLoader.
This was the approach I was beginning when I stumbled upon the bug with
#else and proposed the strict syntax for # directives. I was contemplating
a preprocessor that take the input file and convert to this stream:
#macro( foo $a $b )#{if}($a)#{if}($b)a and b#{else}a#{end}#{end}
Jim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Answer embedded...
Steven Hugg wrote:
>
> I thought the time was ripe to tackle the albatross that is whitespace
> handling, judging by the mail list archives :> It is one of my big
> stumbling blocks with Velocity that prevents me from fully enjoying its
> charms.
Ditto.
Great phrasing!
>
> It occurs to me that a very simple rule could be added to solve many
> whitespace problems:
>
> * Given a text fragment between two directives, if it is entirely made up of
> whitespace, do not output that fragment.
>
> This would let you do things like this:
>
> #if($fooCondition)
> #**# whitespace tamed #**#
> #end
>
> Which would output " whitespace tamed ". If you omit the comments, it would
> read like "\n whitespace tamed \n"
In previous threads, Geir underlined that Velocity should also work with
any character stream. So that the additional gobbling
>
> Easy, and probably could be done without even touching the parser. Also nice
> because there is precedent -- I have never had a problem with whitespace
> behavior in XSL, which has a similar option for gobbling whitespace.
Yes, XSL has some control, but its ugly, and the default behaviour differ
depending on the context: XML read over a select is stripped, whereas the
same text within xml-text tags is not. (I'm recontructing this from memory,
I did have problems with whitespace handling in XSLT and needed a lot of
embedded xml-text tags to get the LFs in the right place.)
XSL offers the following switches:
<xsl:strip-space elements=tokens />
<xsl:preserve-space elements=tokens />
<xsl:text disable-output-escaping="yes"|"no">...<!-- #PCDATA -->...</xsl:text>
<xsl:value-of select=pattern disable-output-escaping="yes"|"no">...</xsl:text>
If in velocity we make the whitespace gobbling switchable it would be OK
with me only if the gobbling rule/pattern is also OK.
>
> What does everyone think-- can we do it?
Steven, your picture doesn't seem complete to me. The whitespaces that bug
me are the ones within nested conditions and loops:
... some schmoo
## smoe comment
#if( $foo )
#if( $bar )
#set( $woogie = $bar )
#else
#set( $woogie = $foo )
#end
... some prefix
#foreach( $i in $woogie )
... do soemthing great here
#end
... some postfix
#end
In the output of this, the prefix is indented by lots of unwanted
whitespace.
My proposal was that any directive that is standalone (enclosed
whith whitespaces between the "\n"s) gobbles these whitespaces.
So your example:
#if($fooCondition)
whitespace tamed
#end
emits exactly what you typed:
whitespace tamed
if you want a newline before it - then type it.
In my case, if you want a macro/parse/inline call to emit the
surrounding whitespace the you add a proper comment:
#text("This will be indented and has no newline after it")##
#text("This will be indented and has a newline after it")#**#
#**##text("This also will be indented and has a newline after it")
This affects the backward compatibilty since:
#text("This will *not* be indented and has no newline after it")
versus now it *is* indented and *has* a newline. So to re-gain the
current behaviour it would need a #**# on the same line.
Steven, would my proposal fit what you expect?
Note that it is yust as simple as your proposal, but avoids the
extra newline before the schmoo whithin the condition (when no
comments are present), and thus is more backward compatible to
the current behaviour (e.g. since text might follow your end,
your proposal would emit a newline also here..., currently it
does not).
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
Thursday, April 11, 2002, 10:31:58 AM, Christoph Reck wrote:
> +0 to your rule in a) which contains the BNF to something
> *very* similar to what I proposed.
> +1 If you leave the (WSSchomo? Directive)* out of it.
> I see the requirement that if you place multiple directives
> in one line, you are embedding something in your text.
That should be (Schomo? Directive)* anyway, I have overlooked it. So
in the example below do you feel that we should not gobble the
whitespace? Maybe. I can accept either gobble or not to gobble it.
#foreach($x in $foo)
#if($x < 3)123#end
#end
> The whitespaces around a directive should only be gobbled
> when it has been placed standalone in a line.
> Geir, for character stream users, they could just put
> a #**# upfront any directive to inhibit gobbling.
> Porposal Update:
> If a line is looks like this:
> DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
> TabsAndSpaces ::= (#x20 | #x09)+
> LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
Ops... ture I forgot the first LineEnd and the StartOfStream. :-/
> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> should be gobbled. (Note that it supports multiline directives, that is
> why "DirectiveLine" is not simply "Line".) If you whant the first
> "LineEnd" to be gobbled prepend a ## before it (it is part of the
> previous line!).
OK. The updated a) is better.
> Daniel, could you live with this simplification?
> Note that the #echo directive you propose can be easily achieved
> with a macro: #macro(echo $text)$text#end
No, I disagree here. The problem is that VTL is a language for
generating text based on templates as we know. If a "text template
language" can't output any text without your custom objects in the
context, then it has serious problems in it's core. This is something
like if Fortran doesn't support multiplication operator, because you
can implement it with your own function. Some of disadvantages of
custom solutions are: your code is less protable (copy-pasteable), the
reader of your code must know your custom components, and last not
least Velocity users have to reivent the wheel again and again. So I
say that you can live without a built-in #echo like macro, but
Velocoty will be more complete and better with it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/19/02 5:39 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> "Geir Magnusson Jr." wrote:
>> On 4/18/02 9:10 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>>> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
>> [snip]
>>>> Strange, I've never seen a directive gobble the EOL before it. Geir,
>>>> can you confirm this?
>>>
>>> My apologies on this. My early work was merging to a StringWriter which I
>>> dumped to stdout. In that scenario, the EOLs did not show up in stdout - all
>>> the lines were bumped up against each other.
>>>
>>> When I finalized the code to use a BufferedWriter to a file, everything
>>> looked fantastic. So no complaints. Leave the whitespace handling completely
>>> alone! <g,d,&r>
>>
>> There are times when I love this job... :)
>
> Donnie's clarifications only applies to the gobbling of EOLs and
> blank lines before a directive.
>
> As long as you leave directives glued to the left margin the
> velocity world is curently great!
>
> Geir your examples and most test-bed code does not indent the
> directives, thus rarely you will encounter the feared
> "unwanted stray whitespaces" we are arguing about.
And you think that's the extent of my Velocity usage? Examples and
test-bed?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The cost of synchronization is much less that the cost of stupidity.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
"Geir Magnusson Jr." wrote:
> On 4/18/02 9:10 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> >> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
>[snip]
> >> Strange, I've never seen a directive gobble the EOL before it. Geir,
> >> can you confirm this?
> >
> > My apologies on this. My early work was merging to a StringWriter which I
> > dumped to stdout. In that scenario, the EOLs did not show up in stdout - all
> > the lines were bumped up against each other.
> >
> > When I finalized the code to use a BufferedWriter to a file, everything
> > looked fantastic. So no complaints. Leave the whitespace handling completely
> > alone! <g,d,&r>
>
> There are times when I love this job... :)
Donnie's clarifications only applies to the gobbling of EOLs and
blank lines before a directive.
As long as you leave directives glued to the left margin the
velocity world is curently great!
Geir your examples and most test-bed code does not indent the
directives, thus rarely you will encounter the feared
"unwanted stray whitespaces" we are arguing about.
> Simple testing can confirm it :)
>
> It has been this way since the earth cooled, back at v1.0
>
> Try the following template and tell me what you get :
>
> ==========
> #foreach($i in [1..2])
> $i
> #end
> ==========
> #foreach($i in [1..2]) $i #end
> =========
> #foreach($i in [1..2]) $i
> #end
> ==========
>
> Ok, I'll tell you :
>
> ==========
> 1
> 2
> ==========
> 1 2 =========
> 1
> 2
> ==========
>
> Because in the first and last case the #foreach() and #end gobble the NL.
> Yes, I did it way back, and I don't really like it from the general point of
> view, but it surly makes things prettier.
Yup this is perfectly correct, but:
---------------------------------------------------------------
Whitespace test:
#macro( echo $text )$text#end
#set( $foo = true )
#if( $foo )
## indented comments makes stray whitespaces
#foreach($i in [1..2])
## The #set gobbles leading whitespaces, this comment does not.
#set( $bar = $i )
Item: ## gobble EOL to put the number beside this
#echo( $bar )
## the echo gobbled the EOL, so put a newline explicetely in next
#end
#end
Whitespace test done.
------ produces unexpected whitespaces in the output ----------
Whitespace test:
Item: 1
Item: 2
Whitespace test done.
----------------------- instead of ----------------------------
Whitespace test:
Item: 1
Item: 2
Whitespace test done.
---------------------------------------------------------------
Jason stated that his solution is to run the output trough a prety-printer
(for C/Java code) or tidy (for XML, HTML) to get it right post mortem.
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/18/02 9:10 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> See below...
>
>> -----Original Message-----
>> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
>> Sent: Wednesday, April 17, 2002 3:30 AM
>> To: Velocity Users List
>> Subject: Re: Whitespace, redux
>>
>>
>> Answers embedded...
>>
>> Donnie Hale wrote:
>>>
>>> Sorry to jump in so late on this, but it's hitting home w/ work
>> I'm doing
>>> now (a Java code generator for the data access layer in a
>> web/servlet-based
>>> app). While the generated code compiles, I'd obviously like it to look
>>> decent. I have template code like:
>>>
>>> public class ${object.basename}DTO
>>> {
>>> public ${object.basename)DTO
>>> {
>>> }
>>>
>>> #foreach($prop in $object.properties)
>>> public $prop.type ${prop.getter}()
>>> {
>>> return $prop.name;
>>> }
>>> private $prop.type $prop.name;
>>>
>>> #end
>>> }
>>>
>>> First, I see the blank line after the closing brace of the constructor
>>> disappear.
>>
>> Strange, I've never seen a directive gobble the EOL before it. Geir,
>> can you confirm this?
>
> My apologies on this. My early work was merging to a StringWriter which I
> dumped to stdout. In that scenario, the EOLs did not show up in stdout - all
> the lines were bumped up against each other.
>
> When I finalized the code to use a BufferedWriter to a file, everything
> looked fantastic. So no complaints. Leave the whitespace handling completely
> alone! <g,d,&r>
There are times when I love this job... :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The cost of synchronization is much less that the cost of stupidity.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Donnie Hale <do...@haleonline.net>.
See below...
> -----Original Message-----
> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> Sent: Wednesday, April 17, 2002 3:30 AM
> To: Velocity Users List
> Subject: Re: Whitespace, redux
>
>
> Answers embedded...
>
> Donnie Hale wrote:
> >
> > Sorry to jump in so late on this, but it's hitting home w/ work
> I'm doing
> > now (a Java code generator for the data access layer in a
> web/servlet-based
> > app). While the generated code compiles, I'd obviously like it to look
> > decent. I have template code like:
> >
> > public class ${object.basename}DTO
> > {
> > public ${object.basename)DTO
> > {
> > }
> >
> > #foreach($prop in $object.properties)
> > public $prop.type ${prop.getter}()
> > {
> > return $prop.name;
> > }
> > private $prop.type $prop.name;
> >
> > #end
> > }
> >
> > First, I see the blank line after the closing brace of the constructor
> > disappear.
>
> Strange, I've never seen a directive gobble the EOL before it. Geir,
> can you confirm this?
My apologies on this. My early work was merging to a StringWriter which I
dumped to stdout. In that scenario, the EOLs did not show up in stdout - all
the lines were bumped up against each other.
When I finalized the code to use a BufferedWriter to a file, everything
looked fantastic. So no complaints. Leave the whitespace handling completely
alone! <g,d,&r>
Again, mea culpa.
Donnie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macro caching
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
To catch up, Tommy Svensson also had problems, but it seems that the global
VM approach solves his?
More inline.
On 4/17/02 5:25 PM, "Peter Romianowski" <me...@gmx.de> wrote:
> Hi,
>
> fast reply - as always! Thanks for that...
>
>> Ok - there are a few things that jump out as problems. First, are there
>> multiple 'design.vm' templates? Or just one that covers it for all
>> partners?
>
> One for each partner.
>
>>
>> Another way : are there multiple
>>
>>
>> #macro( footer $color)
>>
>> (or whatever) in the system?
>>
>> If so, this might be a real problem if all the partner requests are coming
>> through the same webapp. Why? What happens when two hit the servlet at the
>> same time? You might load one set of macros, start rendering, and then the
>> second request comes and loads it's macro set, replacing the first set
>> halfway through.
>
> Yes! I did not even think of that! But you are absoluty right. So now I have
> a real problem... Besides the caching. A solution would be to synchronize the
> renderer - ehm, not really :)
> Could I use one velocity-instance per partner? That would require some bigger
> code-changes for me - but if it works...
You could, but there may be other ways.
>
>> There are costs and risks with autoreloading - it's intended only for
>> development.
>
> The way I would expect things to work is that I simply use a
> #include-Statement.
> But looking at the code I see why this cannot be done so easily, because
> velocity
> is strictly devided into parse-time and run-time, right? Are there any chances
> that
> this might work in the future? And what should I do until then?
Yes - #parse() won't work as the #parse() is evaluated at run time...
>
> I am using velocity for almost all types of templating: web, mail, reports and
> so
> on. It really, rellay ROCKS! But I have to say, that some issues are really
> disturbing,
> like whitespace-gobbling and this one here. I didn't mean to offend you or
> other
> developers (no way!) - you're doing a great job!
So you are another in the magic whitespace camp? No offense taken, btw.
Good to know...
> So, help or a workaround is still very much appreciated!
Will continue down the thread...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Somebody has to do something, and it's just incredibly pathetic that it has
to be us. - Jerry Garcia
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: java method invoke problem
Posted by Xuan Han <xh...@inktomi.com>.
thanks. Eventually it's working!
-Xuan
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
Sent: Wednesday, April 17, 2002 4:05 PM
To: velocity-user@jakarta.apache.org
Subject: Re: java method invoke problem
On 4/17/02 6:02 PM, "Xuan Han" <xh...@inktomi.com> wrote:
> here it is:
>
> import java.net.*;
>
> public class Encoder
> {
> public String encode (String url)
> {
> return ( URLEncoder.encode( url ) );
> }
> }
>
That looks fine. I just used it with a template
#set($foo = $encoder.encode("hello there"))
$foo
And the output was
hello+there
As I expect.
What is output when you do
$encoder
$encoder.encode("hello there")
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Wednesday, April 17, 2002 3:00 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: java method invoke problem
>
>
> On 4/17/02 5:55 PM, "Xuan Han" <xh...@inktomi.com> wrote:
>
>> I have a public Encoder java object pushed into Context. It has a
method:
>> public String encode( String).
>>
>> In my vm macro, I invoke method on the Encoder.
>> #set( $valueEncoded = $Encoder.encode($value) )
>>
>> but the value is printed as "Encoder@9f47....", not the encocded string I
>> expected. What's causing the problem here? Thanks,
>
> Hard to say. Can we see the Encoder class?
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> You're going to end up getting pissed at your software
> anyway, so you might as well not pay for it. Try Open Source.
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java method invoke problem
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/17/02 6:02 PM, "Xuan Han" <xh...@inktomi.com> wrote:
> here it is:
>
> import java.net.*;
>
> public class Encoder
> {
> public String encode (String url)
> {
> return ( URLEncoder.encode( url ) );
> }
> }
>
That looks fine. I just used it with a template
#set($foo = $encoder.encode("hello there"))
$foo
And the output was
hello+there
As I expect.
What is output when you do
$encoder
$encoder.encode("hello there")
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Wednesday, April 17, 2002 3:00 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: java method invoke problem
>
>
> On 4/17/02 5:55 PM, "Xuan Han" <xh...@inktomi.com> wrote:
>
>> I have a public Encoder java object pushed into Context. It has a method:
>> public String encode( String).
>>
>> In my vm macro, I invoke method on the Encoder.
>> #set( $valueEncoded = $Encoder.encode($value) )
>>
>> but the value is printed as "Encoder@9f47....", not the encocded string I
>> expected. What's causing the problem here? Thanks,
>
> Hard to say. Can we see the Encoder class?
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> You're going to end up getting pissed at your software
> anyway, so you might as well not pay for it. Try Open Source.
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: java method invoke problem
Posted by Xuan Han <xh...@inktomi.com>.
here it is:
import java.net.*;
public class Encoder
{
public String encode (String url)
{
return ( URLEncoder.encode( url ) );
}
}
-----Original Message-----
From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
Sent: Wednesday, April 17, 2002 3:00 PM
To: velocity-user@jakarta.apache.org
Subject: Re: java method invoke problem
On 4/17/02 5:55 PM, "Xuan Han" <xh...@inktomi.com> wrote:
> I have a public Encoder java object pushed into Context. It has a method:
> public String encode( String).
>
> In my vm macro, I invoke method on the Encoder.
> #set( $valueEncoded = $Encoder.encode($value) )
>
> but the value is printed as "Encoder@9f47....", not the encocded string I
> expected. What's causing the problem here? Thanks,
Hard to say. Can we see the Encoder class?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java method invoke problem
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/17/02 5:55 PM, "Xuan Han" <xh...@inktomi.com> wrote:
> I have a public Encoder java object pushed into Context. It has a method:
> public String encode( String).
>
> In my vm macro, I invoke method on the Encoder.
> #set( $valueEncoded = $Encoder.encode($value) )
>
> but the value is printed as "Encoder@9f47....", not the encocded string I
> expected. What's causing the problem here? Thanks,
Hard to say. Can we see the Encoder class?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
java method invoke problem
Posted by Xuan Han <xh...@inktomi.com>.
I have a public Encoder java object pushed into Context. It has a method:
public String encode( String).
In my vm macro, I invoke method on the Encoder.
#set( $valueEncoded = $Encoder.encode($value) )
but the value is printed as "Encoder@9f47....", not the encocded string I
expected. What's causing the problem here? Thanks,
-Xuan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: macro caching
Posted by Peter Romianowski <me...@gmx.de>.
Hi,
fast reply - as always! Thanks for that...
> Ok - there are a few things that jump out as problems. First, are there
> multiple 'design.vm' templates? Or just one that covers it for all
> partners?
One for each partner.
>
> Another way : are there multiple
>
>
> #macro( footer $color)
>
> (or whatever) in the system?
>
> If so, this might be a real problem if all the partner requests are coming
> through the same webapp. Why? What happens when two hit the servlet at the
> same time? You might load one set of macros, start rendering, and then the
> second request comes and loads it's macro set, replacing the first set
> halfway through.
Yes! I did not even think of that! But you are absoluty right. So now I have
a real problem... Besides the caching. A solution would be to synchronize the
renderer - ehm, not really :)
Could I use one velocity-instance per partner? That would require some bigger
code-changes for me - but if it works...
> There are costs and risks with autoreloading - it's intended only for
> development.
The way I would expect things to work is that I simply use a #include-Statement.
But looking at the code I see why this cannot be done so easily, because velocity
is strictly devided into parse-time and run-time, right? Are there any chances that
this might work in the future? And what should I do until then?
I am using velocity for almost all types of templating: web, mail, reports and so
on. It really, rellay ROCKS! But I have to say, that some issues are really disturbing,
like whitespace-gobbling and this one here. I didn't mean to offend you or other
developers (no way!) - you're doing a great job!
So, help or a workaround is still very much appreciated!
Thanks,
Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: macro caching
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/17/02 4:41 PM, "Peter Romianowski" <me...@gmx.de> wrote:
> Hi,
>
> I am doing something quite strange, but I don't know what
> to do...
> In my project there are templates for several partners (not a
> fixed number). Upon HTML-generation I look which partner is
> connected and then render the specefic template. That works fine.
> Because the design only differs in some general "modules", like
> HEADER, FOOTER, LINKDESIGN, TABLEDESIGN and so on, I decided to
> do these things with macros. I have multiple templates per partner
> and so I put the macros into a design.vm (for each partner, that
> wants to override the default design).
> Now the strange thing :)
> In my Servlet I first render the design-template ignoring its
> output and then render the "normal" template. This way I have
> access to the macros in my templates. If there would be a better
> aproach (#include does not work - it's a pitty...), I would love
> to know about it. If there isn't one, then I have the problem,
> that the macros defined in design.vm are cached and I have to
> restart the whole application (which is really *huge* :) if I
> change a template. In the production environment the templates
> change dynamically and so the caching is a real problem.
Ok - there are a few things that jump out as problems. First, are there
multiple 'design.vm' templates? Or just one that covers it for all
partners?
Another way : are there multiple
#macro( footer $color)
(or whatever) in the system?
If so, this might be a real problem if all the partner requests are coming
through the same webapp. Why? What happens when two hit the servlet at the
same time? You might load one set of macros, start rendering, and then the
second request comes and loads it's macro set, replacing the first set
halfway through.
I may have misunderstood you, so this may not be a problem.
>
> My velocity.properties:
>
> velocimacro.permissions.allow.inline = true
> velocimacro.permissions.allow.inline.to.replace.global = true
> velocimacro.library.autoreload = true
There are costs and risks with autoreloading - it's intended only for
development.
>
> #----------------------------------------------------------------------------
> # T E M P L A T E L O A D E R S
> #----------------------------------------------------------------------------
>
> resource.loader = file
>
> file.resource.loader.description = Velocity File Resource Loader
> file.resource.loader.class =
> org.apache.velocity.runtime.resource.loader.FileResourceLoader
> file.resource.loader.path = ., o:/coreg/projects/promotionserver/runenv,
> o:/coreg/projects/promotionserver/runenv/www/WEB-INF/templates,
> file.resource.loader.cache = true
> file.resource.loader.modificationCheckInterval = 1
>
>
>
> Any help is highly appriciated!
Summary of my question : can you re-explain how the design.vm macros work?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
macro caching
Posted by Peter Romianowski <me...@gmx.de>.
Hi,
I am doing something quite strange, but I don't know what
to do...
In my project there are templates for several partners (not a
fixed number). Upon HTML-generation I look which partner is
connected and then render the specefic template. That works fine.
Because the design only differs in some general "modules", like
HEADER, FOOTER, LINKDESIGN, TABLEDESIGN and so on, I decided to
do these things with macros. I have multiple templates per partner
and so I put the macros into a design.vm (for each partner, that
wants to override the default design).
Now the strange thing :)
In my Servlet I first render the design-template ignoring its
output and then render the "normal" template. This way I have
access to the macros in my templates. If there would be a better
aproach (#include does not work - it's a pitty...), I would love
to know about it. If there isn't one, then I have the problem,
that the macros defined in design.vm are cached and I have to
restart the whole application (which is really *huge* :) if I
change a template. In the production environment the templates
change dynamically and so the caching is a real problem.
My velocity.properties:
velocimacro.permissions.allow.inline = true
velocimacro.permissions.allow.inline.to.replace.global = true
velocimacro.library.autoreload = true
#----------------------------------------------------------------------------
# T E M P L A T E L O A D E R S
#----------------------------------------------------------------------------
resource.loader = file
file.resource.loader.description = Velocity File Resource Loader
file.resource.loader.class = org.apache.velocity.runtime.resource.loader.FileResourceLoader
file.resource.loader.path = ., o:/coreg/projects/promotionserver/runenv,
o:/coreg/projects/promotionserver/runenv/www/WEB-INF/templates,
file.resource.loader.cache = true
file.resource.loader.modificationCheckInterval = 1
Any help is highly appriciated!
Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/17/02 3:29 AM, "Christoph Reck" <Ch...@dlr.de> wrote:
> Answers embedded...
>
> Donnie Hale wrote:
>>
>> Sorry to jump in so late on this, but it's hitting home w/ work I'm doing
>> now (a Java code generator for the data access layer in a web/servlet-based
>> app). While the generated code compiles, I'd obviously like it to look
>> decent. I have template code like:
>>
>> public class ${object.basename}DTO
>> {
>> public ${object.basename)DTO
>> {
>> }
>>
>> #foreach($prop in $object.properties)
>> public $prop.type ${prop.getter}()
>> {
>> return $prop.name;
>> }
>> private $prop.type $prop.name;
>>
>> #end
>> }
>>
>> First, I see the blank line after the closing brace of the constructor
>> disappear.
>
> Strange, I've never seen a directive gobble the EOL before it. Geir,
> can you confirm this?
Simple testing can confirm it :)
It has been this way since the earth cooled, back at v1.0
Try the following template and tell me what you get :
==========
#foreach($i in [1..2])
$i
#end
==========
#foreach($i in [1..2]) $i #end
=========
#foreach($i in [1..2]) $i
#end
==========
Ok, I'll tell you :
==========
1
2
==========
1 2 =========
1
2
==========
Because in the first and last case the #foreach() and #end gobble the NL.
Yes, I did it way back, and I don't really like it from the general point of
view, but it surly makes things prettier.
:)
[SNIP]
>>
>> While I have people's attention, are there any current workarounds to
>> achieve what I want?
>
> Send a patch to demonstrate the problem and it will get fixed.
Send an *example* to demonstrate the problem and it will be *considered*. :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
Answers embedded...
Donnie Hale wrote:
>
> Sorry to jump in so late on this, but it's hitting home w/ work I'm doing
> now (a Java code generator for the data access layer in a web/servlet-based
> app). While the generated code compiles, I'd obviously like it to look
> decent. I have template code like:
>
> public class ${object.basename}DTO
> {
> public ${object.basename)DTO
> {
> }
>
> #foreach($prop in $object.properties)
> public $prop.type ${prop.getter}()
> {
> return $prop.name;
> }
> private $prop.type $prop.name;
>
> #end
> }
>
> First, I see the blank line after the closing brace of the constructor
> disappear.
Strange, I've never seen a directive gobble the EOL before it. Geir,
can you confirm this?
> Second, sometimes I see the spaces before "public" inside the
> #foreach either disappear or get expanded (so it's indented more than I
> want.
To my knowledge it should never dissapears. I can recall one case where
I embedded javascript via a macro call (that indented it properly) where
the closing </script> was missing spaces before it - it seemed that vel
did it, but I did not track this down (had no real impact on the
functionality of the outputted code).
If the #foreach has some #set or other indented conditions after it, the
spaces will grow.
This is exactly the issue I'm adressing with my proposal.
> Third, the blank line before the #end disappears.
Nope, same comment as in your "First".
> I've tried putting a
> "eol" attribute in the context which evaluates to the result of
> System.getProperty("line.separator") and then sticking that by itself at the
> beginning of lines I want to be blank; but that gets gobbled too (I'm sure
> I'm not the first to try that).
I've successfully used an $NL within strings in a #set(...).
Other times my experience is that if you type a CR | (CR LF) in a line
other than after a directive it goes through untouched.
>
> So my question is - based on this proposal, will what I want be supported. A
> lot of this discussion seems geared toward where people *do* want whitespace
> gobbled. But I don't want it gobbled. I essentially want things echo'd just
> as I've formatted them with references replaced "in-place".
You points need to be checked.
Could you please send a patch to the test suite that demonstrates
your problem. This will enable a clear fix of it.
>
> Again, I'm sure not the first to express things this way. Just making sure
> my requirements are there in the recent threads.
Fine.
>
> While I have people's attention, are there any current workarounds to
> achieve what I want?
Send a patch to demonstrate the problem and it will get fixed.
>
> Thanks,
>
> Donnie
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Jason van Zyl <jv...@zenplex.com>.
On Tue, 2002-04-16 at 21:27, Donnie Hale wrote:
> Sorry to jump in so late on this, but it's hitting home w/ work I'm doing
> now (a Java code generator for the data access layer in a web/servlet-based
> app). While the generated code compiles, I'd obviously like it to look
> decent. I have template code like:
>
> public class ${object.basename}DTO
> {
> public ${object.basename)DTO
> {
> }
>
> #foreach($prop in $object.properties)
> public $prop.type ${prop.getter}()
> {
> return $prop.name;
> }
> private $prop.type $prop.name;
>
> #end
> }
>
> First, I see the blank line after the closing brace of the constructor
> disappear. Second, sometimes I see the spaces before "public" inside the
> #foreach either disappear or get expanded (so it's indented more than I
> want. Third, the blank line before the #end disappears. I've tried putting a
> "eol" attribute in the context which evaluates to the result of
> System.getProperty("line.separator") and then sticking that by itself at the
> beginning of lines I want to be blank; but that gets gobbled too (I'm sure
> I'm not the first to try that).
>
> So my question is - based on this proposal, will what I want be supported. A
> lot of this discussion seems geared toward where people *do* want whitespace
> gobbled. But I don't want it gobbled. I essentially want things echo'd just
> as I've formatted them with references replaced "in-place".
>
> Again, I'm sure not the first to express things this way. Just making sure
> my requirements are there in the recent threads.
>
> While I have people's attention, are there any current workarounds to
> achieve what I want?
If it's java source you can just pretty print the source post
generation. That's what I do with my torque generated code.
> Thanks,
> Donnie
>
>
> > -----Original Message-----
> > From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> > Sent: Thursday, April 11, 2002 4:32 AM
> > To: Velocity Users List
> > Subject: Re: Whitespace, redux
> >
> >
> > +0 to your rule in a) which contains the BNF to something
> > *very* similar to what I proposed.
> >
> > +1 If you leave the (WSSchomo? Directive)* out of it.
> > I see the requirement that if you place multiple directives
> > in one line, you are embedding something in your text.
> > The whitespaces around a directive should only be gobbled
> > when it has been placed standalone in a line.
> > Geir, for character stream users, they could just put
> > a #**# upfront any directive to inhibit gobbling.
> > Porposal Update:
> > If a line is looks like this:
> > DirectiveLine ::= LineEnd TabsAndSpaces? Directive
> > TabsAndSpaces? LineEnd
> > TabsAndSpaces ::= (#x20 | #x09)+
> > LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) |
> > EndOfStream
> > then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> > should be gobbled. (Note that it supports multiline directives, that is
> > why "DirectiveLine" is not simply "Line".) If you whant the first
> > "LineEnd" to be gobbled prepend a ## before it (it is part of the
> > previous line!).
> >
> > Daniel, could you live with this simplification?
> > Note that the #echo directive you propose can be easily achieved
> > with a macro: #macro(echo $text)$text#end
> >
> > Geir, should one of us tackle this issue and send a patch,
> > including the test suite? Then give the proposal a +1.
> > I've currelty more than 100% Workload - and I know others also -
> > but soemeone could yell up and say that its itching him and wants
> > to schedule it in to get it resolved.
> >
> > :) Christoph Reck
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Whitespace, redux
Posted by Donnie Hale <do...@haleonline.net>.
Sorry to jump in so late on this, but it's hitting home w/ work I'm doing
now (a Java code generator for the data access layer in a web/servlet-based
app). While the generated code compiles, I'd obviously like it to look
decent. I have template code like:
public class ${object.basename}DTO
{
public ${object.basename)DTO
{
}
#foreach($prop in $object.properties)
public $prop.type ${prop.getter}()
{
return $prop.name;
}
private $prop.type $prop.name;
#end
}
First, I see the blank line after the closing brace of the constructor
disappear. Second, sometimes I see the spaces before "public" inside the
#foreach either disappear or get expanded (so it's indented more than I
want. Third, the blank line before the #end disappears. I've tried putting a
"eol" attribute in the context which evaluates to the result of
System.getProperty("line.separator") and then sticking that by itself at the
beginning of lines I want to be blank; but that gets gobbled too (I'm sure
I'm not the first to try that).
So my question is - based on this proposal, will what I want be supported. A
lot of this discussion seems geared toward where people *do* want whitespace
gobbled. But I don't want it gobbled. I essentially want things echo'd just
as I've formatted them with references replaced "in-place".
Again, I'm sure not the first to express things this way. Just making sure
my requirements are there in the recent threads.
While I have people's attention, are there any current workarounds to
achieve what I want?
Thanks,
Donnie
> -----Original Message-----
> From: Christoph.Reck@dlr.de [mailto:Christoph.Reck@dlr.de]
> Sent: Thursday, April 11, 2002 4:32 AM
> To: Velocity Users List
> Subject: Re: Whitespace, redux
>
>
> +0 to your rule in a) which contains the BNF to something
> *very* similar to what I proposed.
>
> +1 If you leave the (WSSchomo? Directive)* out of it.
> I see the requirement that if you place multiple directives
> in one line, you are embedding something in your text.
> The whitespaces around a directive should only be gobbled
> when it has been placed standalone in a line.
> Geir, for character stream users, they could just put
> a #**# upfront any directive to inhibit gobbling.
> Porposal Update:
> If a line is looks like this:
> DirectiveLine ::= LineEnd TabsAndSpaces? Directive
> TabsAndSpaces? LineEnd
> TabsAndSpaces ::= (#x20 | #x09)+
> LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) |
> EndOfStream
> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
> should be gobbled. (Note that it supports multiline directives, that is
> why "DirectiveLine" is not simply "Line".) If you whant the first
> "LineEnd" to be gobbled prepend a ## before it (it is part of the
> previous line!).
>
> Daniel, could you live with this simplification?
> Note that the #echo directive you propose can be easily achieved
> with a macro: #macro(echo $text)$text#end
>
> Geir, should one of us tackle this issue and send a patch,
> including the test suite? Then give the proposal a +1.
> I've currelty more than 100% Workload - and I know others also -
> but soemeone could yell up and say that its itching him and wants
> to schedule it in to get it resolved.
>
> :) Christoph Reck
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Christoph Reck <Ch...@dlr.de>.
+0 to your rule in a) which contains the BNF to something
*very* similar to what I proposed.
+1 If you leave the (WSSchomo? Directive)* out of it.
I see the requirement that if you place multiple directives
in one line, you are embedding something in your text.
The whitespaces around a directive should only be gobbled
when it has been placed standalone in a line.
Geir, for character stream users, they could just put
a #**# upfront any directive to inhibit gobbling.
Porposal Update:
If a line is looks like this:
DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
TabsAndSpaces ::= (#x20 | #x09)+
LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
should be gobbled. (Note that it supports multiline directives, that is
why "DirectiveLine" is not simply "Line".) If you whant the first
"LineEnd" to be gobbled prepend a ## before it (it is part of the
previous line!).
Daniel, could you live with this simplification?
Note that the #echo directive you propose can be easily achieved
with a macro: #macro(echo $text)$text#end
Geir, should one of us tackle this issue and send a patch,
including the test suite? Then give the proposal a +1.
I've currelty more than 100% Workload - and I know others also -
but soemeone could yell up and say that its itching him and wants
to schedule it in to get it resolved.
:) Christoph Reck
Daniel Dekany wrote:
>[snip]
>
> I think a more general purpose and more obvious rule would be:
>
> a)
> If a line is looks like this:
> TemplateLine ::=
> WSSchomo? Directive (WSSchomo? Directive)* WSSchomo? LineEnd
> WSSchomo ::= (#x20 | #x09)+
> LineEnd ::= ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
> then the first "WSSchomo?" and the closing "WSSchomo? LineEnd" should be
> gobbled. (Note that it supports multiline directives, that is why
> "TemplateLine" is not simply "Line".)
Typo:
s/WSSchomo/WSSchmoo/g
or even clearer
s/WSSchomo/TabsAndSpaces/g
>
> b)
> Directive #echo('whatever') can be used to output any text, and combined
> with the whitespace gobbling it gives total controll over whitespaces:
> #if($foo)
> #echo('whitespace tamed')
> #else
> #echo(' <- one-space')
> #echo($test)
> #end
> and it is also a good way to do a safe context independent escaping of
> reserved characters:
> #echo('$')foo
> #echo('##not a commend')
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by Daniel Dekany <dd...@freemail.hu>.
----- Original Message -----
From: "Steven Hugg" <hu...@fasterlight.com>
To: <ve...@jakarta.apache.org>
Sent: Wednesday, April 10, 2002 1:58 AM
[snip]
> * Given a text fragment between two directives, if it is entirely made up
of
> whitespace, do not output that fragment.
>
> This would let you do things like this:
>
> #if($fooCondition)
> #**# whitespace tamed #**#
> #end
I think a more general purpose and more obvious rule would be:
a)
If a line is looks like this:
TemplateLine ::=
WSSchomo? Directive (WSSchomo? Directive)* WSSchomo? LineEnd
WSSchomo ::= (#x20 | #x09)+
LineEnd ::= ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
then the first "WSSchomo?" and the closing "WSSchomo? LineEnd" should be
gobbled. (Note that it supports multiline directives, that is why
"TemplateLine" is not simply "Line".)
b)
Directive #echo('whatever') can be used to output any text, and combined
with the whitespace gobbling it gives total controll over whitespaces:
#if($foo)
#echo('whitespace tamed')
#else
#echo(' <- one-space')
#echo($test)
#end
and it is also a good way to do a safe context independent escaping of
reserved characters:
#echo('$')foo
#echo('##not a commend')
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Whitespace, redux
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 4/9/02 7:58 PM, "Steven Hugg" <hu...@fasterlight.com> wrote:
> I thought the time was ripe to tackle the albatross that is whitespace
> handling, judging by the mail list archives :> It is one of my big
> stumbling blocks with Velocity that prevents me from fully enjoying its
> charms.
>
> It occurs to me that a very simple rule could be added to solve many
> whitespace problems:
>
> * Given a text fragment between two directives, if it is entirely made up of
> whitespace, do not output that fragment.
>
> This would let you do things like this:
>
> #if($fooCondition)
> #**# whitespace tamed #**#
> #end
>
> Which would output " whitespace tamed ". If you omit the comments, it would
> read like "\n whitespace tamed \n"
What if I *want* to output whitespace?
#if($fooCondition) #include('foo.vm') whitespace tamed #parse('bar.vm')
#end
Now what?
>
> Easy, and probably could be done without even touching the parser. Also nice
> because there is precedent -- I have never had a problem with whitespace
> behavior in XSL, which has a similar option for gobbling whitespace.
Oh, so it doesn't do it all the time ? ;)
>
> What does everyone think-- can we do it?
How about a switch?
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Maven & Gump are friends
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>