You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Brad Cox <bc...@virtualschool.edu> on 2004/02/12 02:51:11 UTC
Request for information: velocimacro past/future
I'm starting to write up documentation on using Velocity within my
http://virtualschool.edu/ale project and need information that isn't
apparent from the documentation.
What I'd LIKE to do is to describe a simple, repeatable pattern, like
"if velocity doesn't understand how to do something, it always prints
the command it couldn't parse unchanged as a clue you need to fix it.
Problem is, this is true only in a few cases and emphatically NOT
true of most syntax errors. For example, commas in macro calls or
definitions (why aren't commas REQUIRED?) cause ParseExceptions, and
there are dozens (it seems) of similar examples.
The inconsistencies are so widespread that I'm wondering whether I
should be documenting them or fixing them. The ParseExceptions MIGHT
be patchable by catching the exception and emitting the original
source. But I suspect it can't be that easy: antlr's ASP trees were
really murky last time I looked.
So Geir, could I impose on you to shed some light on where the
dragons are here? Did the macro parser originate in some other
project perhaps (the documentation kind of sounds that way)? Do you
understand this code well enough to make error handling consistent?
Do you plan to make such changes? Are there legacy issues involved?
Is this something that would justify a code fork? I'm willing to
pitch in, but don't want to step in blindly.
--
Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
http://virtualschool/ale Action Learning Environment
http://virtualschool.edu/mybank Digital Rights Management System
http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
http://virtualschool.edu/jwaa Java Web Application Architecture (JWAA)
http://virtualschool.edu/java+ Java Preprocessor (Java+)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 11, 2004, at 9:10 PM, Will Glass-Husain wrote:
> Hi Brad,
>
> Maybe this is a useful idea... Geir's suggested previously that a
> template
> validator would be helpful. In other words, a tool to validate the
> templates
> when they are uploaded. Check for proper syntax, check that the
> references
> used are kosher, etc. I've been stewing on this but haven't produced
> anything.
I've used this technique in another environment w/ a scripting language
structured a lot like velocity, and it was a big help.
>
> As an aside, I'd like to see commas in macro definitions too. The
> inconsistency confuses my users, particularly when a List is one
> of the arguments. (commas in Lists but not macro calls).
Yep
>
> Best,
> WILL
>
> ----- Original Message -----
> From: "Brad Cox" <bc...@virtualschool.edu>
> To: "'Velocity Users List'" <ve...@jakarta.apache.org>
> Sent: Wednesday, February 11, 2004 5:51 PM
> Subject: Request for information: velocimacro past/future
>
>
>> I'm starting to write up documentation on using Velocity within my
>> http://virtualschool.edu/ale project and need information that isn't
>> apparent from the documentation.
>>
>> What I'd LIKE to do is to describe a simple, repeatable pattern, like
>> "if velocity doesn't understand how to do something, it always prints
>> the command it couldn't parse unchanged as a clue you need to fix it.
>>
>> Problem is, this is true only in a few cases and emphatically NOT
>> true of most syntax errors. For example, commas in macro calls or
>> definitions (why aren't commas REQUIRED?) cause ParseExceptions, and
>> there are dozens (it seems) of similar examples.
>>
>> The inconsistencies are so widespread that I'm wondering whether I
>> should be documenting them or fixing them. The ParseExceptions MIGHT
>> be patchable by catching the exception and emitting the original
>> source. But I suspect it can't be that easy: antlr's ASP trees were
>> really murky last time I looked.
>>
>> So Geir, could I impose on you to shed some light on where the
>> dragons are here? Did the macro parser originate in some other
>> project perhaps (the documentation kind of sounds that way)? Do you
>> understand this code well enough to make error handling consistent?
>> Do you plan to make such changes? Are there legacy issues involved?
>> Is this something that would justify a code fork? I'm willing to
>> pitch in, but don't want to step in blindly.
>> --
>> Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
>> http://virtualschool/ale Action Learning Environment
>> http://virtualschool.edu/mybank Digital Rights Management System
>> http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
>> http://virtualschool.edu/jwaa Java Web Application Architecture
>> (JWAA)
>> http://virtualschool.edu/java+ Java Preprocessor (Java+)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: Request for information: velocimacro past/future
Posted by Robert Nocera <rn...@neosllc.com>.
We've been thinking about the idea of a template validator also. Currently
I use Eclipse with VeloEdit and Veloedit does a good job of validating some
things visually but it doesn't help if you aren't in eclipse or a visual
environment and it doesn't validate that your method calls are correct.
Being able to run a template through a validation process would be a big
help in a lot of applications of Velocity.
-Rob
-----Original Message-----
From: Will Glass-Husain [mailto:wglass@forio.com]
Sent: Wednesday, February 11, 2004 9:11 PM
To: Velocity Users List
Subject: Re: Request for information: velocimacro past/future
Hi Brad,
Maybe this is a useful idea... Geir's suggested previously that a template
validator would be helpful. In other words, a tool to validate the templates
when they are uploaded. Check for proper syntax, check that the references
used are kosher, etc. I've been stewing on this but haven't produced
anything.
As an aside, I'd like to see commas in macro definitions too. The
inconsistency confuses my users, particularly when a List is one
of the arguments. (commas in Lists but not macro calls).
Best,
WILL
----- Original Message -----
From: "Brad Cox" <bc...@virtualschool.edu>
To: "'Velocity Users List'" <ve...@jakarta.apache.org>
Sent: Wednesday, February 11, 2004 5:51 PM
Subject: Request for information: velocimacro past/future
> I'm starting to write up documentation on using Velocity within my
> http://virtualschool.edu/ale project and need information that isn't
> apparent from the documentation.
>
> What I'd LIKE to do is to describe a simple, repeatable pattern, like
> "if velocity doesn't understand how to do something, it always prints
> the command it couldn't parse unchanged as a clue you need to fix it.
>
> Problem is, this is true only in a few cases and emphatically NOT
> true of most syntax errors. For example, commas in macro calls or
> definitions (why aren't commas REQUIRED?) cause ParseExceptions, and
> there are dozens (it seems) of similar examples.
>
> The inconsistencies are so widespread that I'm wondering whether I
> should be documenting them or fixing them. The ParseExceptions MIGHT
> be patchable by catching the exception and emitting the original
> source. But I suspect it can't be that easy: antlr's ASP trees were
> really murky last time I looked.
>
> So Geir, could I impose on you to shed some light on where the
> dragons are here? Did the macro parser originate in some other
> project perhaps (the documentation kind of sounds that way)? Do you
> understand this code well enough to make error handling consistent?
> Do you plan to make such changes? Are there legacy issues involved?
> Is this something that would justify a code fork? I'm willing to
> pitch in, but don't want to step in blindly.
> --
> Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
> http://virtualschool/ale Action Learning Environment
> http://virtualschool.edu/mybank Digital Rights Management System
> http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
> http://virtualschool.edu/jwaa Java Web Application Architecture (JWAA)
> http://virtualschool.edu/java+ Java Preprocessor (Java+)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
+1 also.
Mike Kienenberger wrote:
>Will Glass-Husain <wg...@forio.com> wrote:
>
>
>>As an aside, I'd like to see commas in macro definitions too. The
>>inconsistency confuses my users, particularly when a List is one
>>of the arguments. (commas in Lists but not macro calls).
>>
>>
>
>+1 :)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by Mike Kienenberger <mk...@alaska.net>.
Will Glass-Husain <wg...@forio.com> wrote:
> As an aside, I'd like to see commas in macro definitions too. The
> inconsistency confuses my users, particularly when a List is one
> of the arguments. (commas in Lists but not macro calls).
+1 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by Will Glass-Husain <wg...@forio.com>.
Hi Brad,
Maybe this is a useful idea... Geir's suggested previously that a template
validator would be helpful. In other words, a tool to validate the templates
when they are uploaded. Check for proper syntax, check that the references
used are kosher, etc. I've been stewing on this but haven't produced
anything.
As an aside, I'd like to see commas in macro definitions too. The
inconsistency confuses my users, particularly when a List is one
of the arguments. (commas in Lists but not macro calls).
Best,
WILL
----- Original Message -----
From: "Brad Cox" <bc...@virtualschool.edu>
To: "'Velocity Users List'" <ve...@jakarta.apache.org>
Sent: Wednesday, February 11, 2004 5:51 PM
Subject: Request for information: velocimacro past/future
> I'm starting to write up documentation on using Velocity within my
> http://virtualschool.edu/ale project and need information that isn't
> apparent from the documentation.
>
> What I'd LIKE to do is to describe a simple, repeatable pattern, like
> "if velocity doesn't understand how to do something, it always prints
> the command it couldn't parse unchanged as a clue you need to fix it.
>
> Problem is, this is true only in a few cases and emphatically NOT
> true of most syntax errors. For example, commas in macro calls or
> definitions (why aren't commas REQUIRED?) cause ParseExceptions, and
> there are dozens (it seems) of similar examples.
>
> The inconsistencies are so widespread that I'm wondering whether I
> should be documenting them or fixing them. The ParseExceptions MIGHT
> be patchable by catching the exception and emitting the original
> source. But I suspect it can't be that easy: antlr's ASP trees were
> really murky last time I looked.
>
> So Geir, could I impose on you to shed some light on where the
> dragons are here? Did the macro parser originate in some other
> project perhaps (the documentation kind of sounds that way)? Do you
> understand this code well enough to make error handling consistent?
> Do you plan to make such changes? Are there legacy issues involved?
> Is this something that would justify a code fork? I'm willing to
> pitch in, but don't want to step in blindly.
> --
> Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
> http://virtualschool/ale Action Learning Environment
> http://virtualschool.edu/mybank Digital Rights Management System
> http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
> http://virtualschool.edu/jwaa Java Web Application Architecture (JWAA)
> http://virtualschool.edu/java+ Java Preprocessor (Java+)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by Brad Cox <bc...@virtualschool.edu>.
At 7:07 AM -0500 2/13/04, Geir Magnusson Jr wrote:
>On Feb 11, 2004, at 8:51 PM, Brad Cox wrote:
>
>>I'm starting to write up documentation on using Velocity within my
>>http://virtualschool.edu/ale project and need information that
>>isn't apparent from the documentation.
>>
>>What I'd LIKE to do is to describe a simple, repeatable pattern,
>>like "if velocity doesn't understand how to do something, it always
>>prints the command it couldn't parse unchanged as a clue you need
>>to fix it.
>>
>>Problem is, this is true only in a few cases and emphatically NOT
>>true of most syntax errors. For example, commas in macro calls or
>>definitions (why aren't commas REQUIRED?) cause ParseExceptions,
>>and there are dozens (it seems) of similar examples.
>
>You are right. There are probably a huge number of syntax errors :)
I thought I made it clear, the proposal was to make syntax error
*handling* consistent for all kinds of syntax errors. Not just
commas, but missing parentheses, invalid references and so forth and
so on. Grep ParseException should find most of them.
>We'll fix the comma thing, btw, in 1.5. It's 100% backwards compatible.
Great. But how about the other cases that throw ParseExceptions?
>>
>>The inconsistencies are so widespread that I'm wondering whether I
>>should be documenting them or fixing them. The ParseExceptions
>>MIGHT be patchable by catching the exception and emitting the
>>original source. But I suspect it can't be that easy: antlr's ASP
>>trees were really murky last time I looked.
>
>We don't use antlr.
>
>>
>>So Geir, could I impose on you to shed some light on where the
>>dragons are here? Did the macro parser originate in some other
>>project perhaps (the documentation kind of sounds that way)?
>
>Nope. All done here.
>
>>Do you understand this code well enough to make error handling
>>consistent? Do you plan to make such changes? Are there legacy
>>issues involved? Is this something that would justify a code fork?
>>I'm willing to pitch in, but don't want to step in blindly.
>
>The commas I agree, and can even get that patch in now. I think
>there's no problem there. You need to be specific on what you mean
>for the other ones.
>
>geir
>
>>--
>>Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
>> http://virtualschool/ale Action Learning Environment
>>http://virtualschool.edu/mybank Digital Rights Management System
>> http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
>> http://virtualschool.edu/jwaa Java Web Application Architecture (JWAA)
>> http://virtualschool.edu/java+ Java Preprocessor (Java+)
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>--
>Geir Magnusson Jr 203-247-1713(m)
>geir@4quarters.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
--
Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
http://virtualschool/ale Action Learning Environment
http://virtualschool.edu/mybank Digital Rights Management System
http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
http://virtualschool.edu/jwaa Java Web Application Architecture (JWAA)
http://virtualschool.edu/java+ Java Preprocessor (Java+)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Request for information: velocimacro past/future
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 11, 2004, at 8:51 PM, Brad Cox wrote:
> I'm starting to write up documentation on using Velocity within my
> http://virtualschool.edu/ale project and need information that isn't
> apparent from the documentation.
>
> What I'd LIKE to do is to describe a simple, repeatable pattern, like
> "if velocity doesn't understand how to do something, it always prints
> the command it couldn't parse unchanged as a clue you need to fix it.
>
> Problem is, this is true only in a few cases and emphatically NOT true
> of most syntax errors. For example, commas in macro calls or
> definitions (why aren't commas REQUIRED?) cause ParseExceptions, and
> there are dozens (it seems) of similar examples.
You are right. There are probably a huge number of syntax errors :)
We'll fix the comma thing, btw, in 1.5. It's 100% backwards compatible.
>
> The inconsistencies are so widespread that I'm wondering whether I
> should be documenting them or fixing them. The ParseExceptions MIGHT
> be patchable by catching the exception and emitting the original
> source. But I suspect it can't be that easy: antlr's ASP trees were
> really murky last time I looked.
We don't use antlr.
>
> So Geir, could I impose on you to shed some light on where the dragons
> are here? Did the macro parser originate in some other project perhaps
> (the documentation kind of sounds that way)?
Nope. All done here.
> Do you understand this code well enough to make error handling
> consistent? Do you plan to make such changes? Are there legacy issues
> involved? Is this something that would justify a code fork? I'm
> willing to pitch in, but don't want to step in blindly.
The commas I agree, and can even get that patch in now. I think
there's no problem there. You need to be specific on what you mean for
the other ones.
geir
> --
> Brad J. Cox, PhD, 703 361 4751, http://virtualschool.edu
> http://virtualschool/ale Action Learning Environment
> http://virtualschool.edu/mybank Digital Rights Management System
> http://virtualschool.edu/jco Java Cryptographic Objects (JCO)
> http://virtualschool.edu/jwaa Java Web Application Architecture
> (JWAA)
> http://virtualschool.edu/java+ Java Preprocessor (Java+)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org