You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2004/02/11 20:37:45 UTC
[veltools] recommended keys for MessageTool/ActionMessagesTool
hey folks,
i've brought this question up once before, but i can't help but try once more.
:)
Right now, we recommend that people use "$msg" as the context key for the
MessageTool and "$actionmsgs" as the context key for the ActionMessagesTool
frankly, i'm not comfortable either one. the MessageTool is designed to
support the i18n of text displayed in the webapp. the ActionMessagesTool is
for displaying messages sent/created by Struts actions. i've always felt this
naming (which comes largely from Struts) was confusing and unclear. while it
is pretty much too late to try and get Struts to drop the language of "message
resources" in favor of "text resources", and thus not worthwhile to change the
java class names of these tools. i do not think it is too late to change how
we name them in templates. i think we could make their purposes more distinct
and clear by changing the recommended keys. here are my reasons and
suggestions:
while $actionmsgs is functionally descriptive, it is ugly and on the long side
for a standard tool. it is also not parallel to $errors while the functions
of those two tools are parallel. i think it would be clearer and more elegant
to change this recommendation to: $messages
$msg on the other hand is only descriptive of the underlying java classes, not
the true function of the tool. since the tool is just used to display
internationlized text, i think an appropriate key would be: $text
please note that these are only the *recommended* keys and users are welcome
to keep their current naming schemes.
my reason for bringing this up now is that we are drawing close to a 1.1 rc or
final release. this would be the official introduction of the
ActionMessagesTool, and thus it is best to settle this matter before the
release. also, after 1.1, i hope to put more effort into building standard
velocimacro libraries to accompany the tools. at that point, the recommended
keys become standards and changing them would be *very* difficult. the time
to decide this is now.
oh, and since this is really a matter of how VelocityTools is used, i'm very
interested in hearing from everyone using these, not just contributors and
committers.
Nathan Bubna
nathan@esha.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 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
Request for information: velocimacro past/future
Posted by Brad Cox <bc...@virtualschool.edu>.
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: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Mike Kienenberger <mk...@alaska.net>.
> > Nathan Bubna wrote:
> > >my reason for bringing this up now is that we are drawing close to a
> > >1.1 rc or final release. this would be the official introduction of
> > >the ActionMessagesTool, and thus it is best to settle this matter
> > >before the release. also, after 1.1, i hope to put more effort into
> > >building standard velocimacro libraries to accompany the tools. at
> > >that point, the recommended keys become standards and changing them
> > >would be *very* difficult. the time to decide this is now.
+1 for the changes.
I also think that it's a pretty trivial change since anyone needing
"backward compatibility" will automatically have it by using their existing
toolbox.xml definitions.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Matthew Van Horn <ma...@ashleyassociates.co.jp>.
I like $messages and $text as well.
> -----Original Message-----
> From: Charles N. Harvey III [mailto:charlieh@alloy.com]
> Sent: Thursday, February 12, 2004 4:52 AM
> To: Velocity Users List
> Subject: Re: [veltools] recommended keys for
> MessageTool/ActionMessagesTool
>
>
> +1
>
> I like $messages and $text.
>
>
> Charlie
>
>
> Nathan Bubna wrote:
>
> >hey folks,
> >
> >i've brought this question up once before, but i can't help but try
> >once more.
> >:)
> >
> >Right now, we recommend that people use "$msg" as the
> context key for
> >the MessageTool and "$actionmsgs" as the context key for the
> >ActionMessagesTool
> >
> >frankly, i'm not comfortable either one. the MessageTool is
> designed
> >to support the i18n of text displayed in the webapp. the
> >ActionMessagesTool is for displaying messages sent/created by Struts
> >actions. i've always felt this naming (which comes largely from
> >Struts) was confusing and unclear. while it is pretty much
> too late to
> >try and get Struts to drop the language of "message
> resources" in favor
> >of "text resources", and thus not worthwhile to change the
> java class
> >names of these tools. i do not think it is too late to
> change how we
> >name them in templates. i think we could make their purposes more
> >distinct and clear by changing the recommended keys. here
> are my reasons and
> >suggestions:
> >
> >while $actionmsgs is functionally descriptive, it is ugly and on the
> >long side for a standard tool. it is also not parallel to $errors
> >while the functions of those two tools are parallel. i
> think it would
> >be clearer and more elegant to change this recommendation to:
> >$messages
> >
> >$msg on the other hand is only descriptive of the underlying java
> >classes, not the true function of the tool. since the tool is just
> >used to display internationlized text, i think an
> appropriate key would
> >be: $text
> >
> >please note that these are only the *recommended* keys and users are
> >welcome to keep their current naming schemes.
> >
> >my reason for bringing this up now is that we are drawing close to a
> >1.1 rc or final release. this would be the official introduction of
> >the ActionMessagesTool, and thus it is best to settle this matter
> >before the release. also, after 1.1, i hope to put more effort into
> >building standard velocimacro libraries to accompany the tools. at
> >that point, the recommended keys become standards and changing them
> >would be *very* difficult. the time to decide this is now.
> >
> >oh, and since this is really a matter of how VelocityTools
> is used, i'm
> >very interested in hearing from everyone using these, not just
> >contributors and committers.
> >
> >Nathan Bubna
> >nathan@esha.com
> >
> >
> >---------------------------------------------------------------------
> >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: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by "Charles N. Harvey III" <ch...@alloy.com>.
+1
I like $messages and $text.
Charlie
Nathan Bubna wrote:
>hey folks,
>
>i've brought this question up once before, but i can't help but try once more.
>:)
>
>Right now, we recommend that people use "$msg" as the context key for the
>MessageTool and "$actionmsgs" as the context key for the ActionMessagesTool
>
>frankly, i'm not comfortable either one. the MessageTool is designed to
>support the i18n of text displayed in the webapp. the ActionMessagesTool is
>for displaying messages sent/created by Struts actions. i've always felt this
>naming (which comes largely from Struts) was confusing and unclear. while it
>is pretty much too late to try and get Struts to drop the language of "message
>resources" in favor of "text resources", and thus not worthwhile to change the
>java class names of these tools. i do not think it is too late to change how
>we name them in templates. i think we could make their purposes more distinct
>and clear by changing the recommended keys. here are my reasons and
>suggestions:
>
>while $actionmsgs is functionally descriptive, it is ugly and on the long side
>for a standard tool. it is also not parallel to $errors while the functions
>of those two tools are parallel. i think it would be clearer and more elegant
>to change this recommendation to: $messages
>
>$msg on the other hand is only descriptive of the underlying java classes, not
>the true function of the tool. since the tool is just used to display
>internationlized text, i think an appropriate key would be: $text
>
>please note that these are only the *recommended* keys and users are welcome
>to keep their current naming schemes.
>
>my reason for bringing this up now is that we are drawing close to a 1.1 rc or
>final release. this would be the official introduction of the
>ActionMessagesTool, and thus it is best to settle this matter before the
>release. also, after 1.1, i hope to put more effort into building standard
>velocimacro libraries to accompany the tools. at that point, the recommended
>keys become standards and changing them would be *very* difficult. the time
>to decide this is now.
>
>oh, and since this is really a matter of how VelocityTools is used, i'm very
>interested in hearing from everyone using these, not just contributors and
>committers.
>
>Nathan Bubna
>nathan@esha.com
>
>
>---------------------------------------------------------------------
>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: [veltools] validator Tool
Posted by Nathan Bubna <na...@esha.com>.
Marino A. Jonsson said:
...
> However they do have two boolean attributes, staticJavascript and
> dynamicJavascript. When staticJavascript is true all the _static_
> javascript methods in validator-rules.xml are rendered. When
> dynamicJavascript is true the _dynamic_ methods (that serve as access points
> to the static methods for the validation process) are constructed from the
> relevant form info.
>
> By default both these attributes are true, which puts all the javascript in
> a single page ... however, a more sane approach would be to put the static
> methods in a seperate .js file and just render the dynamic parts with the
> form on a given page. In order to do that you would have to manually set
> the two dynamic/static attributes before calling the getJavascript method in
> each case - setStaticJavascript(true/false) and
> setDynamicJavascript(true/false).
>
> I cleaned it up a bit and made the interface more intuitive (I hope) ... now
> there are basically five public methods (apart from the getters/setters):
>
> getJavaScript()
> getJavaScript(String formName)
>
> getDynamicJavascript()
> getDynamicJavascript(String formName)
>
> getStaticJavascript()
>
>
> The getDynamicJavascript and getStaticJavascript methods are useful if the
> static methods should be seperate from the dynamic code, i.e. in a seperate
> .js file.
>
> getJavascript renders the dynamic parts as well as all the static methods in
> one big pile.
>
> thoughts?
makes good sense to me. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: [veltools] validator Tool
Posted by Tim Colson <tc...@cisco.com>.
> It was only a single post,
I obviously missed it, sorry about that.
> so I threw out the respective get/set methods.
Seems cool.
> a more sane approach would be to
As I recall, there were a few things that could be improved and made
more sane, but the new method calls you've added sound like a great
start to me!
I've got a simple little app I'm working on now with 1.1 - so I'll have
a look at the Validator stuff directly.
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [veltools] validator Tool
Posted by "Marino A. Jonsson" <ma...@hotmail.com>.
It was only a single post, and I've already committed the changes, but I'd
like feedback from you and Nathan (others are welcome to comment too :-) ).
Here are the most relevant parts:
As the ValidatorTool is based on the ValidatorJavascriptTag it has a lot of
optional attributes that translate to a lot of public getter/setter methods
in the corresponding Velocity tool (eight to be exact). The majority of the
attributes are rarely used and so it doesn't really bug me that one would
have to set the attribute in a seperate call to change it. One of the
attributes is really redundant (formName) since it's either determined
dynamically or supplied as a parameter to the getJavascript() method, so I
threw out the respective get/set methods.
However they do have two boolean attributes, staticJavascript and
dynamicJavascript. When staticJavascript is true all the _static_
javascript methods in validator-rules.xml are rendered. When
dynamicJavascript is true the _dynamic_ methods (that serve as access points
to the static methods for the validation process) are constructed from the
relevant form info.
By default both these attributes are true, which puts all the javascript in
a single page ... however, a more sane approach would be to put the static
methods in a seperate .js file and just render the dynamic parts with the
form on a given page. In order to do that you would have to manually set
the two dynamic/static attributes before calling the getJavascript method in
each case - setStaticJavascript(true/false) and
setDynamicJavascript(true/false).
I cleaned it up a bit and made the interface more intuitive (I hope) ... now
there are basically five public methods (apart from the getters/setters):
getJavaScript()
getJavaScript(String formName)
getDynamicJavascript()
getDynamicJavascript(String formName)
getStaticJavascript()
The getDynamicJavascript and getStaticJavascript methods are useful if the
static methods should be seperate from the dynamic code, i.e. in a seperate
.js file.
getJavascript renders the dynamic parts as well as all the static methods in
one big pile.
thoughts?
cheers,
Marin�
"Tim Colson" <tc...@cisco.com> wrote in message
news:000201c3f1d1$b8f5c800$0a18190a@amer.cisco.com...
> > > btw. Timo did you get a chance to look at the proposals for the
> > > ValidatorTool?
> Sorry, was on biz travel week before last... and then all those msg's
> (hah) about logging got me bogged down [almost] reading them. (I wonder
> if a conference call once in a while could help the process.)
>
> If you throw a link or three to help me understand what I should read -
> I promise I'll have a look at it and give feedback.
>
> Cheers,
> Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
[veltools] validator Tool
Posted by Tim Colson <tc...@cisco.com>.
> > btw. Timo did you get a chance to look at the proposals for the
> > ValidatorTool?
Sorry, was on biz travel week before last... and then all those msg's
(hah) about logging got me bogged down [almost] reading them. (I wonder
if a conference call once in a while could help the process.)
If you throw a link or three to help me understand what I should read -
I promise I'll have a look at it and give feedback.
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Nathan Bubna <na...@esha.com>.
well, that's enough agreement to convince me. $text and $messages it is. :)
----- Original Message -----
From: "Marino A. Jonsson" <ma...@hotmail.com>
To: <ve...@jakarta.apache.org>
Sent: Thursday, February 12, 2004 12:49 PM
Subject: Re: [veltools] recommended keys for MessageTool/ActionMessagesTool
>
> "Tim Colson" <tc...@cisco.com> wrote in message
> news:000201c3f1a2$3ea03ab0$0a18190a@amer.cisco.com...
> > > unabbrieviated words for most of our tool keys, and i think
> > > that's a good thing.
> >
> > +1
> >
> > A tiny bit of verbosity can make things easier to understand down the
> > road.
> > (My Perl old code is super-terse, but I don't have a clue what some of
> > it does today, whereas the Java code I write can pretty much be read
> > through years later and not even need docs.)
> >
> > To be honest, I'm cool with $text - but even that seems a tad generic.
> > ;-)
>
> how does $applicationresources and $actionmessages sound? :-)
>
> seriously, I like $text - it seems spot on in the context of template
> designing, and it's short.
> On the other hand, although I don't disagree with the abbreviation
> principle, I still think $msgs would be better than $messages - since 'msg'
> is a pretty universaly know abbreviation for message (I think). But I don't
> feel strongly about this and $messages is fine with me too :-)
>
> btw. Timo did you get a chance to look at the proposals for the
> ValidatorTool?
>
> cheers,
> Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by "Marino A. Jonsson" <ma...@hotmail.com>.
"Tim Colson" <tc...@cisco.com> wrote in message
news:000201c3f1a2$3ea03ab0$0a18190a@amer.cisco.com...
> > unabbrieviated words for most of our tool keys, and i think
> > that's a good thing.
>
> +1
>
> A tiny bit of verbosity can make things easier to understand down the
> road.
> (My Perl old code is super-terse, but I don't have a clue what some of
> it does today, whereas the Java code I write can pretty much be read
> through years later and not even need docs.)
>
> To be honest, I'm cool with $text - but even that seems a tad generic.
> ;-)
how does $applicationresources and $actionmessages sound? :-)
seriously, I like $text - it seems spot on in the context of template
designing, and it's short.
On the other hand, although I don't disagree with the abbreviation
principle, I still think $msgs would be better than $messages - since 'msg'
is a pretty universaly know abbreviation for message (I think). But I don't
feel strongly about this and $messages is fine with me too :-)
btw. Timo did you get a chance to look at the proposals for the
ValidatorTool?
cheers,
Marin�
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Tim Colson <tc...@cisco.com>.
> unabbrieviated words for most of our tool keys, and i think
> that's a good thing.
+1
A tiny bit of verbosity can make things easier to understand down the
road.
(My Perl old code is super-terse, but I don't have a clue what some of
it does today, whereas the Java code I write can pretty much be read
through years later and not even need docs.)
To be honest, I'm cool with $text - but even that seems a tad generic.
;-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Nathan Bubna <na...@esha.com>.
Marino A. Jonsson said:
> I like $text, and I guess $messages is ok too ... but is there any reason
> not to use $msg instead of $messages? I realize that it would be a little
> confusing at first - the former $msg changing to $text and $msg reintroduced
> as a recommended key for action messages instead - but I think $messages is
> a little on the long side and that $msg would be better in the long run.
yes the confusion of old $msg for new $msg is definitely a short-run issue,
but not an insignificant one. still, i would prefer $messages if only for the
parallel to $errors. i toyed with the idea of $msgs, but still felt that was
easily confused with $msg and not as readable as i'd like it. we use
unabbrieviated words for most of our tool keys, and i think that's a good
thing.
> "Nathan Bubna" <na...@esha.com> wrote in message
> news:0cbd01c3f0d6$868003f0$677ba8c0@zeus.esha.com...
...
> > while $actionmsgs is functionally descriptive, it is ugly and on the long
> side
> > for a standard tool. it is also not parallel to $errors while the
> functions
> > of those two tools are parallel. i think it would be clearer and more
> elegant
> > to change this recommendation to: $messages
...
> > my reason for bringing this up now is that we are drawing close to a 1.1
> rc or
> > final release. this would be the official introduction of the
> > ActionMessagesTool, and thus it is best to settle this matter before the
> > release. also, after 1.1, i hope to put more effort into building
> standard
> > velocimacro libraries to accompany the tools. at that point, the
> recommended
> > keys become standards and changing them would be *very* difficult. the
> time
> > to decide this is now.
> >
> > oh, and since this is really a matter of how VelocityTools is used, i'm
> very
> > interested in hearing from everyone using these, not just contributors and
> > committers.
...
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by "Marino A. Jonsson" <ma...@hotmail.com>.
I like $text, and I guess $messages is ok too ... but is there any reason
not to use $msg instead of $messages? I realize that it would be a little
confusing at first - the former $msg changing to $text and $msg reintroduced
as a recommended key for action messages instead - but I think $messages is
a little on the long side and that $msg would be better in the long run.
cheers,
Marin�
"Nathan Bubna" <na...@esha.com> wrote in message
news:0cbd01c3f0d6$868003f0$677ba8c0@zeus.esha.com...
> hey folks,
>
> i've brought this question up once before, but i can't help but try once
more.
> :)
>
> Right now, we recommend that people use "$msg" as the context key for the
> MessageTool and "$actionmsgs" as the context key for the
ActionMessagesTool
>
> frankly, i'm not comfortable either one. the MessageTool is designed to
> support the i18n of text displayed in the webapp. the ActionMessagesTool
is
> for displaying messages sent/created by Struts actions. i've always felt
this
> naming (which comes largely from Struts) was confusing and unclear. while
it
> is pretty much too late to try and get Struts to drop the language of
"message
> resources" in favor of "text resources", and thus not worthwhile to change
the
> java class names of these tools. i do not think it is too late to change
how
> we name them in templates. i think we could make their purposes more
distinct
> and clear by changing the recommended keys. here are my reasons and
> suggestions:
>
> while $actionmsgs is functionally descriptive, it is ugly and on the long
side
> for a standard tool. it is also not parallel to $errors while the
functions
> of those two tools are parallel. i think it would be clearer and more
elegant
> to change this recommendation to: $messages
>
> $msg on the other hand is only descriptive of the underlying java classes,
not
> the true function of the tool. since the tool is just used to display
> internationlized text, i think an appropriate key would be: $text
>
> please note that these are only the *recommended* keys and users are
welcome
> to keep their current naming schemes.
>
> my reason for bringing this up now is that we are drawing close to a 1.1
rc or
> final release. this would be the official introduction of the
> ActionMessagesTool, and thus it is best to settle this matter before the
> release. also, after 1.1, i hope to put more effort into building
standard
> velocimacro libraries to accompany the tools. at that point, the
recommended
> keys become standards and changing them would be *very* difficult. the
time
> to decide this is now.
>
> oh, and since this is really a matter of how VelocityTools is used, i'm
very
> interested in hearing from everyone using these, not just contributors and
> committers.
>
> Nathan Bubna
> nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: [veltools] recommended keys for MessageTool/ActionMessagesTool
Posted by Tim Colson <tc...@cisco.com>.
> $messages and $text
+1
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org