[jira] Updated: (VELOCITY-787) Write to multiple files, controlled by template directives
[ https://issues.apache.org/jira/browse/VELOCITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Reck updated VELOCITY-787: Attachment: FileTool.java Nathan was faster than I... Here is the tool (from 2001...). Maybe you can close the issue if this solves your request. > Write to multiple files, controlled by template directives > -- > > Key: VELOCITY-787 > URL: https://issues.apache.org/jira/browse/VELOCITY-787 > Project: Velocity > Issue Type: New Feature > Components: Engine >Affects Versions: 2.0 > Environment: All environments >Reporter: Don Mendelson > Attachments: FileTool.java > > > For some purposes, such as code generation, it would be very desirable to > output to multiple files from the same context. For example, to generate code > for a C++ class, two files must be generated - a header and implementation > file. Rendering could be driven by the same context in both cases, which > would desribe the class name, method signatures, etc. Currently this must be > done by running the engine twice - once with a header template and again with > an implementation file template. > Furthermore, it would desirable to determine the output file names during > rendering, based on a combination of template directives and data in the > context. To use the code generation example, the header and implementation > file names would be determined by the name of the class to be generated. > This is not possible with the current method signature of Directive: > public boolean render(InternalContextAdapter context, Writer writer, Node > node) > An output directive would want to change the writer to a different instance > of FileWriter, for instance. But since Java passes object references by > value, the writer object cannot be replaced. > The proposal is to provide a method to install a new instance of Writer > during rendering of a template. This would support both writing multiple > outputs in one run of the engine as well as controlling the file names of the > outputs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-787) Write to multiple files, controlled by template directives
[ https://issues.apache.org/jira/browse/VELOCITY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928618#action_12928618 ] Christoph Reck commented on VELOCITY-787: - I don't think this needs to be solved within the engine. In the past I've solved this through a controller template, string interpolation, and a file writer tool. Example: #macro( createCode $params ) ## ... do something wise here #end ... #foreach ($file $list) #set( $fileContents = "#createCode(...)" ) $FileTool.write($file, $fileContents) #end > Write to multiple files, controlled by template directives > -- > > Key: VELOCITY-787 > URL: https://issues.apache.org/jira/browse/VELOCITY-787 > Project: Velocity > Issue Type: New Feature > Components: Engine >Affects Versions: 2.0 > Environment: All environments >Reporter: Don Mendelson > > For some purposes, such as code generation, it would be very desirable to > output to multiple files from the same context. For example, to generate code > for a C++ class, two files must be generated - a header and implementation > file. Rendering could be driven by the same context in both cases, which > would desribe the class name, method signatures, etc. Currently this must be > done by running the engine twice - once with a header template and again with > an implementation file template. > Furthermore, it would desirable to determine the output file names during > rendering, based on a combination of template directives and data in the > context. To use the code generation example, the header and implementation > file names would be determined by the name of the class to be generated. > This is not possible with the current method signature of Directive: > public boolean render(InternalContextAdapter context, Writer writer, Node > node) > An output directive would want to change the writer to a different instance > of FileWriter, for instance. But since Java passes object references by > value, the writer object cannot be replaced. > The proposal is to provide a method to install a new instance of Writer > during rendering of a template. This would support both writing multiple > outputs in one run of the engine as well as controlling the file names of the > outputs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-617) Jakarta Commons ORO at runtime
[ https://issues.apache.org/jira/browse/VELOCITY-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798616#action_12798616 ] Christoph Reck commented on VELOCITY-617: - I suggest to deprecate org.apache.velocity.convert.WebMacro, since it was an utility to migrate from it in early days when the clean room re-implementation was made. Now WM has changed a lot and I believe this class file is not useful any more. > Jakarta Commons ORO at runtime > -- > > Key: VELOCITY-617 > URL: https://issues.apache.org/jira/browse/VELOCITY-617 > Project: Velocity > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.5, 1.6 >Reporter: Adrian Tarau >Priority: Minor > Fix For: 1.7 > > Attachments: velocity-617.patch > > > There is a misleading information on the dependency > page(http://velocity.apache.org/engine/releases/velocity-1.5/dependencies.html > , These dependencies are required to compile and run the application) about > oro. > "The most common case is the integration of the Velocity runtime into your > application. In this case, you must add commons-collections, commons-lang and > oro to your application (and optional logging if required). If you already > have one or more of these libraries in your application, you should check if > you need to update their versions. " > also > "These dependencies are required to compile and run the application" > Except if Velocity is configured to escape references, oro is not need it at > runtime, only at compile time(most of the users don't care about compile > time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-736) Introspection regression from 1.5 to 1.6.2
[
https://issues.apache.org/jira/browse/VELOCITY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763095#action_12763095
]
Christoph Reck commented on VELOCITY-736:
-
I tested it with 1.5, where it works; whereas in 1.6.2 it fails - so this is a
regression.
It seems to be due to the protected class
org.apache.commons.fileupload.FileUploadBase$SizeException - see:
> javap -protected
> 'org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException'
Compiled from "FileUploadBase.java"
public class
org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException extends
org.apache.commons.fileupload.FileUploadBase$SizeException{
public
org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException();
public
org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException(java.lang.String);
public
org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException(java.lang.String,
long, long);
}
> javap -protected 'org.apache.commons.fileupload.FileUploadBase$SizeException'
Compiled from "FileUploadBase.java"
public abstract class
org.apache.commons.fileupload.FileUploadBase$SizeException extends
org.apache.commons.fileupload.FileUploadException{
protected
org.apache.commons.fileupload.FileUploadBase$SizeException(java.lang.String,
long, long);
public long getActualSize();
public long getPermittedSize();
}
Seems to be duplicate of VELOCITY-579
> Introspection regression from 1.5 to 1.6.2
> --
>
> Key: VELOCITY-736
> URL: https://issues.apache.org/jira/browse/VELOCITY-736
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.6.2
> Environment: Sun JDK 1.6.0_16
>Reporter: David Esposito
>
> When upgrading from Velcocity 1.5 to 1.6.2, the following snippet of code
> changed behavior.
> In Velocity 1.5, the output was:
> The file upload exceeded 100
> In Velocity 1.6.2, the output is:
> The file upload exceeded $ex.permittedSize
> There is nothing in the velocity log file to help me identify why it's not
> resolving 'permittedSize' to the correct bean method.
> Here is a test program to replicate the problem. The context variable in
> question is the Commons FileUpload exception class documented here:
> http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/FileUploadBase.SizeLimitExceededException.html
> I am using commons-fileupload-1.2.jar
> import java.io.StringWriter;
> import org.apache.commons.fileupload.FileUploadBase;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.context.Context;
> public class Main {
> public static void main(String[] args) throws Exception{
> VelocityEngine e = new VelocityEngine();
> String testTemplate = "The file upload exceeded
> $ex.permittedSize";
> StringWriter out = new StringWriter();
> Context ctx = new VelocityContext();
> FileUploadBase.FileSizeLimitExceededException ex = new
> FileUploadBase.FileSizeLimitExceededException("too big!", 50, 100);
> ctx.put("ex",ex);
> e.evaluate(ctx, out, "Tester", testTemplate);
> System.out.println(out.toString());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-736) Introspection regression from 1.5 to 1.6.2
[
https://issues.apache.org/jira/browse/VELOCITY-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763068#action_12763068
]
Christoph Reck commented on VELOCITY-736:
-
Interesting why this worked in 1.5...
The api doc lists for Class FileUploadBase.SizeLimitExceededException:
Methods inherited from class
org.apache.commons.fileupload.FileUploadBase.SizeException
getActualSize, getPermittedSize
And Class FileUploadBase.SizeException has:
Method Summary
long getActualSize()
long getPermittedSize()
which means these are package private and therefore not allowed to be used
externally.
Can someone independently try it in 1.5 and 1.6 to confirm this is a regression?
> Introspection regression from 1.5 to 1.6.2
> --
>
> Key: VELOCITY-736
> URL: https://issues.apache.org/jira/browse/VELOCITY-736
> Project: Velocity
> Issue Type: Bug
> Components: Engine
>Affects Versions: 1.6.2
> Environment: Sun JDK 1.6.0_16
>Reporter: David Esposito
>
> When upgrading from Velcocity 1.5 to 1.6.2, the following snippet of code
> changed behavior.
> In Velocity 1.5, the output was:
> The file upload exceeded 100
> In Velocity 1.6.2, the output is:
> The file upload exceeded $ex.permittedSize
> There is nothing in the velocity log file to help me identify why it's not
> resolving 'permittedSize' to the correct bean method.
> Here is a test program to replicate the problem. The context variable in
> question is the Commons FileUpload exception class documented here:
> http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/FileUploadBase.SizeLimitExceededException.html
> I am using commons-fileupload-1.2.jar
> import java.io.StringWriter;
> import org.apache.commons.fileupload.FileUploadBase;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.context.Context;
> public class Main {
> public static void main(String[] args) throws Exception{
> VelocityEngine e = new VelocityEngine();
> String testTemplate = "The file upload exceeded
> $ex.permittedSize";
> StringWriter out = new StringWriter();
> Context ctx = new VelocityContext();
> FileUploadBase.FileSizeLimitExceededException ex = new
> FileUploadBase.FileSizeLimitExceededException("too big!", 50, 100);
> ctx.put("ex",ex);
> e.evaluate(ctx, out, "Tester", testTemplate);
> System.out.println(out.toString());
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-704) VTL Simplicity - "Control" objects
[ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677663#action_12677663 ] Christoph Reck commented on VELOCITY-704: - At the template level a new directive #pragma would be handy - with such a capability, the programmer could be able to override the default scope: #pragma( scope "template" ) or #pragma( scope "evaluate" ) To keep the simplicity of the directives, it also could be: #set( $pragma.scope = "template" ) OT: this idea has been in my mind since the whitespace handling threads: #pragma( whitespacehandling "structured" ) my 2c. > VTL Simplicity - "Control" objects > -- > > Key: VELOCITY-704 > URL: https://issues.apache.org/jira/browse/VELOCITY-704 > Project: Velocity > Issue Type: New Feature > Components: Engine >Reporter: Nathan Bubna >Assignee: Nathan Bubna > Fix For: 2.0 > > > In the discussion for VELOCITY-680, Claude suggested the addition of what i'm > calling "control" objects as a solution. These would have the same name as > the block directive or macro to which they belong.At a minimum, these > would provide get(key), set(key, value) and stop() methods to control the > reference scoping and execution of the block to which they belong. > Directives could extend the basic control object to provide additional > functions, such as index() and hasNext() for #foreach. Here's some examples: > #foreach( $user in $users ) > $user#if( $foreach.hasNext ), #end > #if( $foreach.count > 10 ) $foreach.stop() #end > #end > #macro( foo $bar ) > blah blah #if( $bar == 'bar' ) $foo.stop() #end > #set( $foo.woogie = 'woogie' ) > $foo.woogie > #end > #foreach( $item in $list ) > #set( $outer = $foreach ) > #foreach( $attr in $item.attributes ) > #if ( $attr == $null ) $outer.stop()#end > #end > #end > --foo.vm- > blah blah $template.stop() blah > > #define( $foo ) > blah blah $define.stop() blah > #end > This could allow us to greatly simplify all sorts of things. We could remove > the #break, #stop and #return directives. We would no longer need to have > "local" contexts for foreach loops or macros; instead users could set and get > local variables directly in the provided namespace. All else would be > global. This may even cut down our internal code complexity a fair bit. > It'll certainly obviate the need for several configuration properties and > internal contexts. Everything becomes much more explicit, obvious and > robust. I also don't think it looks ugly. :) > We would, of course, have to make sure that the StopExceptions thrown by > stop() aren't wrapped into MethodInvocationExceptions. We'd have to make the > directives clean up their control when done rendering, and if they're nested > in a directive of the same type, then they should save and restore the > reference to the parent control. We'd also have to figure out a good > default name to give the control objects for the top-level control object, > and whether it would be different than the name of the control object used > during a #parse call. $template? $parse? $velocity? If we wanted to use > $template--which i think works well for both top-level and #parse--then we'd > probably have to make it configurable, since that's likely to conflict. And > if we make that configurable, i suppose we may as well make it configurable > for the others too. > I'm struggling to think of any real downside to this. Most of the replaced > features (implicit macro localscope, #stop, #break, $velocityHasNext) are > either not default behavior or are new features. I'd wager that most people > would only have to change $velocityCount to $foreach.count. Even that's no > big deal, since this would be for a major version change. , The worst i can > think of is the fact that for a couple of these controls it would mean a few > more keystrokes. Considering all the gains in extensibility, explicitness > and simplification (for us and users), i think it's worth a few keystrokes. > What do you guys think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELTOOLS-113) new DisplayTool features
[ https://issues.apache.org/jira/browse/VELTOOLS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672547#action_12672547 ] Christoph Reck commented on VELTOOLS-113: - Would this work in other languages? (is there such a java function?) Could you use a #macro(plural ...) instead? > new DisplayTool features > > > Key: VELTOOLS-113 > URL: https://issues.apache.org/jira/browse/VELTOOLS-113 > Project: Velocity Tools > Issue Type: New Feature > Components: GenericTools >Reporter: Nathan Bubna >Priority: Minor > > More ideas from the dev list: > -- > On Sat, Feb 7, 2009 at 3:41 PM, wrote: > Hello, > I wanted to share with you a few ideas I have about new simple > improvements for DisplayTools. I should be able to make patches for > them if you are interested. > #snip > 2. Add new "property" parameter to > list(Object list, String delim, String finaldelim, String property) > method that will format an array or collection of objects on selected > property (similar to SortTools). > 3. Add new method: > stripTags(Object obj, String... allowedTags) > that will strip all (html) tags from the text except those listed in > allowedTags (allowed tags are passed like this: "br","img","p"). > 4. Add new method: > br(Object obj) > that will replace \n with "\n" > 5. Add new "preserveWords" parameter to: > truncate(Object truncateMe, int maxLength, String suffix, boolean > preserveWords) > that will truncate a string to a last complete word within maxLength > instead of exact character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Issue Comment Edited: (VELOCITY-688) ! preceding a reference in strict mode ignores a null exception
[ https://issues.apache.org/jira/browse/VELOCITY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672333#action_12672333 ] chreck edited comment on VELOCITY-688 at 2/10/09 9:58 AM: -- The original intent of the bang syntax ($!foo) - it is to allow the template writer to say "this may be null". Without strict mode, $!foo will not log anything if it is undefined or null. I have not used the strict mode, so I have not considered what to do then for a $foo that is undefined or null. I do agree with Nathan that a $foo null reference in strict mode should throw an exception as originally devised. A $!foo null reference in strict mode could output nothing or throw an exception (no preference here). was (Author: chreck): This is the original intent of the bang syntax - it is to allow the template writer to say "this may be null". Without strict mode, $!foo will not log anything if it is undefined or null. I have not used the strict mode, so I have not considered what to do then for a $foo that is undefined or null. I do agree with Nathan that a $foo null reference in strict mode should throw an exception as originally devised. A $!foo null reference in strict mode should output nothing or throw an exception (no preference here). > ! preceding a reference in strict mode ignores a null exception > --- > > Key: VELOCITY-688 > URL: https://issues.apache.org/jira/browse/VELOCITY-688 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.7 >Reporter: Byron Foster > Fix For: 1.7 > > > Change strict mode (runtime.references.strict = true) behavior such that when > Velocity attempts to render a reference that evaluates to null then throw an > exception. If the reference is preceded by '$!' as in $!foo, then simply > render nothing and ignore the null value as it does for non strict mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-688) ! preceding a reference in strict mode ignores a null exception
[ https://issues.apache.org/jira/browse/VELOCITY-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672333#action_12672333 ] Christoph Reck commented on VELOCITY-688: - This is the original intent of the bang syntax - it is to allow the template writer to say "this may be null". Without strict mode, $!foo will not log anything if it is undefined or null. I have not used the strict mode, so I have not considered what to do then for a $foo that is undefined or null. I do agree with Nathan that a $foo null reference in strict mode should throw an exception as originally devised. A $!foo null reference in strict mode should output nothing or throw an exception (no preference here). > ! preceding a reference in strict mode ignores a null exception > --- > > Key: VELOCITY-688 > URL: https://issues.apache.org/jira/browse/VELOCITY-688 > Project: Velocity > Issue Type: Improvement > Components: Engine >Affects Versions: 1.7 >Reporter: Byron Foster > Fix For: 1.7 > > > Change strict mode (runtime.references.strict = true) behavior such that when > Velocity attempts to render a reference that evaluates to null then throw an > exception. If the reference is preceded by '$!' as in $!foo, then simply > render nothing and ignore the null value as it does for non strict mode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Issue Comment Edited: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering
[
https://issues.apache.org/jira/browse/VELOCITY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666241#action_12666241
]
chreck edited comment on VELOCITY-680 at 1/22/09 10:36 AM:
---
I believe what you're looking for is in the whiteboard:
http://svn.apache.org/repos/asf/velocity/engine/trunk/whiteboard/geir/Local.java
Thea idea of it is to have a block where local variables do not pollute the
global namespace:
#macro(foo $bar)
#local($baz $bag)
#set($baz = "goo")
#set($bag = "gone")
$bar $baz $bag
#end
#end
#set($baz = "untouched")
#foo('hello')
$baz
Which should render (untested):
hello goo gone
untouched
was (Author: chreck):
I believe what you're looking for is in the whiteboard:
http://svn.apache.org/repos/asf/velocity/engine/trunk/whiteboard/geir/Local.java
> RFC: New #local directive that behaves like #set but puts things into local
> context in macro rendering
> --
>
> Key: VELOCITY-680
> URL: https://issues.apache.org/jira/browse/VELOCITY-680
> Project: Velocity
> Issue Type: New Feature
>Affects Versions: 1.7
>Reporter: Jarkko Viinamäki
> Attachments: velocity-local-directive.patch
>
>
> It would be very useful to be able to set variables that are in local macro
> scope. That is, they do not overwrite "global" variables and are thrown away
> after macro rendering. This would allow people to build macro libraries that
> do not clash so easily with each other.
> There is some implementation of a "LocalDirective" in
> experimental/localdirective but I didn't quite get it and it doesn't follow
> the same syntax as #set. I used a few minutes to hack together this
> alternative implementation which behaves exactly like #set but it puts things
> in local context only.
> There's only one test case since this is Request-for-Comments type of patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-680) RFC: New #local directive that behaves like #set but puts things into local context in macro rendering
[ https://issues.apache.org/jira/browse/VELOCITY-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666241#action_12666241 ] Christoph Reck commented on VELOCITY-680: - I believe what you're looking for is in the whiteboard: http://svn.apache.org/repos/asf/velocity/engine/trunk/whiteboard/geir/Local.java > RFC: New #local directive that behaves like #set but puts things into local > context in macro rendering > -- > > Key: VELOCITY-680 > URL: https://issues.apache.org/jira/browse/VELOCITY-680 > Project: Velocity > Issue Type: New Feature >Affects Versions: 1.7 >Reporter: Jarkko Viinamäki > Attachments: velocity-local-directive.patch > > > It would be very useful to be able to set variables that are in local macro > scope. That is, they do not overwrite "global" variables and are thrown away > after macro rendering. This would allow people to build macro libraries that > do not clash so easily with each other. > There is some implementation of a "LocalDirective" in > experimental/localdirective but I didn't quite get it and it doesn't follow > the same syntax as #set. I used a few minutes to hack together this > alternative implementation which behaves exactly like #set but it puts things > in local context only. > There's only one test case since this is Request-for-Comments type of patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-661) Parsing errors on content inside #literal() #end block
[
https://issues.apache.org/jira/browse/VELOCITY-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660051#action_12660051
]
Christoph Reck commented on VELOCITY-661:
-
To avoid to have to make to many changes to the parser, maybe the interface or
semantics of directives can be enhanced with a feature to tell the parser to go
into a "simple" mode where it skips parsing into AST until the end marker is
reached.
It would be nice to be able to tell it what the end marker is, similar to the
suggestion above (I changed it to contain the "#"):
#literal('#litend')
...#end...
#litend
To leave a single limitation that requires avoiding an "#end" within the block
is only partially acceptable.
#set( $H = '#' )
#literal()
...${H}end...
#end
Custom directives that do their own magic with the block content would not know
what to do with an embedded "${H}", which would require some
pre-processing/rendering of the block before using it (interesting idea...
would allow some dynamically velocity created content before directive
activity). Alternatively, the custom directive could allow its own escaping
syntax.
> Parsing errors on content inside #literal() #end block
> --
>
> Key: VELOCITY-661
> URL: https://issues.apache.org/jira/browse/VELOCITY-661
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.6.1
> Environment: ALL
>Reporter: ND
>
> I have some velocity templates that include quit some javascript. Inside the
> javascript a javascrip template engine is used which also uses ${varname}
> Escaping each occurance would make the code rather unreable, so to prevent
> velocity from parsing the javascript code, I put a #literal() around it.
> However, velocity still PARSES the contents of this block, which of course
> results in parsing exceptions.
> My feeling with "literal" is that it is completely UNINTERPRETED content?
> This SHOULD work:
> #literal()
> var myId = 'someID';
> $('#test).append($.template('').apply({myId: myId}));
> #end
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] Commented: (VELOCITY-619) New set modifier so that set only assigns a value when variable is not defined.
[ https://issues.apache.org/jira/browse/VELOCITY-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636300#action_12636300 ] Christoph Reck commented on VELOCITY-619: - True that if someone used #set( $!foo = $bar ) in an earlier version it set the value ignoring the bang. At some point it was discussed to use this syntax to explicetely allow setting a NULL value. Changing this would break BC (even though it is an unimplemented feature - some people may have local patches to do so - as I had once...). I propose to add a new directive for this, instead of overloading the #set with bang to mean "set only if undefined". Possible directive names: #default, #option, #setUndefined, #setIfUndefined, #allow, #let P.S. This is inline with some new directives introduced in Vel1.6: #evaluate, #define($ref)...#end, and #break > New set modifier so that set only assigns a value when variable is not > defined. > --- > > Key: VELOCITY-619 > URL: https://issues.apache.org/jira/browse/VELOCITY-619 > Project: Velocity > Issue Type: Improvement > Components: Engine >Reporter: Byron Foster > Attachments: setBangModifier_2.patch > > > Define a new #set modifier such that a variable is only set if it is not > defined, like so: > #set($!foo = "bar") > If the '!' character proceeds the variable foo, then $foo will be set with > the value of "bar" ONLY IF $foo is not defined (is not in the context). > Otherwise if $foo is defined it will remain unchanged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-99) XmlTool
[ https://issues.apache.org/jira/browse/VELTOOLS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612395#action_12612395 ] Christoph Reck commented on VELTOOLS-99: Great to have such a tool now from stock! I browsed over the code and seems quite complete and a very good start. OK, it is fixed onto dom4j (adds another jar to the using application), with no #4:JXPath and no #5:DVSL like support - but these would be some nice to have sugars that are not essential for the main purpose. I believe it will be easy to setup a variant with these capabilities! If I get the itch - if ever..., I will post the code. If I see it correctly the result of $doc.foo.bar will be an XmlTool instance with a text node content "woogie"? Correct me if not. So with the new string comparison functionality in velocity 1.5 it will also work to do #if($doc.foo.bar == "woogie")...#end - which in previous versions would require an interpolation to cast it to a string. > XmlTool > --- > > Key: VELTOOLS-99 > URL: https://issues.apache.org/jira/browse/VELTOOLS-99 > Project: Velocity Tools > Issue Type: New Feature > Components: GenericTools >Affects Versions: 2.x >Reporter: Nathan Bubna > Fix For: 2.0 > > > There have always been those interested in a general tool to read and utilize > XML content in templates. Various approaches to this have been taken. > Though i've yet to need this myself, i thought it would be prudent to gather > ideas and links to relevant discussion and implementations here, in case > someone gets the itch or we want to come up with ideas for something like the > GHOP contest. > Here's a XmlTool that Christoph Reck posted to the mailing list: > http://velocity.markmail.org/search/?q=XmlTool#query:XmlTool+page:1+mid:rpogtxshsqqoiph7+state:results > Philippe Collignon created XmlGen (http://xmlgen.sourceforge.net/), which > offers a very simple API for walking XML docs in a template. There was talk > of contributing the whole project, but that fizzled. As it is ASL 2 > licensed, we could easily adopt relevant portions or, better, find a way to > collaborate and keep the portions we're both interested in in one place. > DVSL has some useful node selection/handling code that uses Dom4j: > http://svn.apache.org/repos/asf/velocity/dvsl/trunk/src/java/org/apache/dvsl/dom4j/Dom4jNodeImpl.java > Anakia, of course, also has some useful xpath/xml handling code: > http://svn.apache.org/repos/asf/velocity/anakia/trunk/src/java/org/apache/anakia/ > It may also prove useful to somehow combine or connect XML reading with the > XML writing stuff proposed in VELTOOLS-97 > (https://issues.apache.org/jira/browse/VELTOOLS-97) > And of course, there's probably a lot of other useful XML handling code out > there. At this point, my favorite API by far is XmlGen's which is very > Velocity-ish and intuitive to me. Since XmlGen is a Texen extension and i > hope eventually to get around to making VelocityTools integrate naturally > into Texen (as well as DVSL and Anakia), it may be that XmlGen's xml reading > API(s) could migrate wholly to VelocityTools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELTOOLS-99) XmlTool
[
https://issues.apache.org/jira/browse/VELTOOLS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558416#action_12558416
]
Christoph Reck commented on VELTOOLS-99:
There are several aspects to consider for a XML tool:
1. VTL Syntax, either:
a) the DOM nodes are xpath-sensitive:
$node.xpath('/[EMAIL PROTECTED]"reck"]/date')
here the implementation needs a XML node factory that is xpath-aware
(as dom4j is), or the Anakia approach with JDOM.
or
b) an external tool is used to work with the DOM nodes (like my XmlTOol or
XPath_Evaluation-XPathHandler mentioned above):
$xml.xpath( $node, '/[EMAIL PROTECTED]"reck"]/date')
This is the simple approach (as my original XmlTool).
or even
c) the XPath directive mentioned above (directives are a bit more difficult
to activate that a tool).
2. Use of JDOM or generic DOM. I propose to use DOM, since it is most adopted
and has many compatible implementations.
3. Allow parsing of XML files from within the template (in analogy to the
#parse directive)?:
$xml.parse("foo.xml")
or feed the XML from the application into the context (like Anakia uses
$root).
4. The XPath engine to use. I like the idea of the apache commons JXPath, which
is also capable to run xpath statements against JDOM and as well as java
objects (POJOS)!
5. Can DVSL capability be added to the XML tool?
P.S. not to forget that some better control of the VTL whitespace output is
highly desirable.
> XmlTool
> ---
>
> Key: VELTOOLS-99
> URL: https://issues.apache.org/jira/browse/VELTOOLS-99
> Project: Velocity Tools
> Issue Type: New Feature
> Components: GenericTools
>Affects Versions: 2.x
>Reporter: Nathan Bubna
> Fix For: 2.x
>
>
> There have always been those interested in a general tool to read and utilize
> XML content in templates. Various approaches to this have been taken.
> Though i've yet to need this myself, i thought it would be prudent to gather
> ideas and links to relevant discussion and implementations here, in case
> someone gets the itch or we want to come up with ideas for something like the
> GHOP contest.
> Here's a XmlTool that Christoph Reck posted to the mailing list:
> http://velocity.markmail.org/search/?q=XmlTool#query:XmlTool+page:1+mid:rpogtxshsqqoiph7+state:results
> Philippe Collignon created XmlGen (http://xmlgen.sourceforge.net/), which
> offers a very simple API for walking XML docs in a template. There was talk
> of contributing the whole project, but that fizzled. As it is ASL 2
> licensed, we could easily adopt relevant portions or, better, find a way to
> collaborate and keep the portions we're both interested in in one place.
> DVSL has some useful node selection/handling code that uses Dom4j:
> http://svn.apache.org/repos/asf/velocity/dvsl/trunk/src/java/org/apache/dvsl/dom4j/Dom4jNodeImpl.java
> Anakia, of course, also has some useful xpath/xml handling code:
> http://svn.apache.org/repos/asf/velocity/anakia/trunk/src/java/org/apache/anakia/
> It may also prove useful to somehow combine or connect XML reading with the
> XML writing stuff proposed in VELTOOLS-97
> (https://issues.apache.org/jira/browse/VELTOOLS-97)
> And of course, there's probably a lot of other useful XML handling code out
> there. At this point, my favorite API by far is XmlGen's which is very
> Velocity-ish and intuitive to me. Since XmlGen is a Texen extension and i
> hope eventually to get around to making VelocityTools integrate naturally
> into Texen (as well as DVSL and Anakia), it may be that XmlGen's xml reading
> API(s) could migrate wholly to VelocityTools.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBF-8) New project logo
[ https://issues.apache.org/jira/browse/DBF-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548744 ] Christoph Reck commented on DBF-8: -- Nice logo! Maybe an additional pixel row below "Velocity" avoids it to be stuck on top of the "D"? > New project logo > > > Key: DBF-8 > URL: https://issues.apache.org/jira/browse/DBF-8 > Project: DocBook Framework > Issue Type: New Feature >Reporter: Nathan Bubna > Attachments: Velocity-DocBook-Framework.png > > > New logo created by Frederico (mr.finsta13 *AT* hotmail *DOT* com) as part of > the Google Highly Open Participation contest. See: > http://code.google.com/p/google-highly-open-participation-asf/issues/detail?id=32 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-174) For consideration: #define()...#end directive to define a block of VTL as a reference
[
https://issues.apache.org/jira/browse/VELOCITY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497518
]
Christoph Reck commented on VELOCITY-174:
-
Looks to me like a #macro, declaring a $reference variable instead of a
#thingy, and without parameters...
But it is affected by the numerous macro properties (local-scope, etc.):
#macro( body )
body VTL code
#end
#parse('base_layout.vm")
Or a multi-line set (does not look as nice - whitespace gobbling issue!):
#set( $body = "body VTL code
")
body VTL code
#end
#parse('base_layout.vm")
So I do like the idea of introducing #define for the notion of a set with a
body.
We need to think over if the body should allow somehow to disable parsing, e.g.
#define( $page )
#literal
$header
$messages
Some VTL that is not parsed
$footer
#end
#end
And then use it, replacing the context references:
#eval( $page )
> For consideration: #define()...#end directive to define a block of VTL as a
> reference
> -
>
> Key: VELOCITY-174
> URL: https://issues.apache.org/jira/browse/VELOCITY-174
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.3.1
> Environment: Operating System: All
> Platform: All
>Reporter: Andrew Tetlaw
>Priority: Minor
> Fix For: 1.6
>
> Attachments: Define.java, Extends.java
>
>
> * Proposal:
> #define( $block_ref )
> ## any VTL / text content here
> ...
> #end
> then you can use it like a reference:
> $!block_ref / #if( $block_ref ).. #end / and so on
> * Justification:
> 1. Allows template designer to use a more efficient inside -> out approach
> (similar to Nathan's VelocityLayoutServlet)
> 2. Keeps macro framework separate (the app developer can still disallow inline
> macros)
> 3. #macros to return blocks of VTL cannot be used like silent references or in
> other directives (like #if)
> 4. The multi-line #set proposal requires a quoted value. A #define() block can
> contain anything (without the need to escape quotes for example).
> 5. #define() blocks are proxied (like #macros) and thus change according to
> the
> context after they are defined, something a normal $reference or #set can't
> do.
> 7. Can improve template management by reducing number of unique template
> components
> 8. Can improve template security/errors by reducing the need for bottom tier
> template makers to worry about generic layout code and visa-versa.
> 9. Merges the strengths of #macros and $references = best of both worlds
> * Usage Example: Custom HTML forms:
> template 1. : document_type_1_custom_form_body.vm
>
> #define( $custom_form_body )
> ## unique form fields here
> #end
> #parse("main_form_layout.vm")
>
> template 2 : main_form_layout.vm
>
> #define( $custom_page_body )
>
> ## common form fields here
> $!custom_form_body
>
>
> #end
> #parse("main_page_layout.vm")
>
> template 2 : main_page_layout.vm
>
>
> ## common page layout html here
> $!custom_page_body
>
>
> If the #define() directive was not available a template designer would need to
> do this:
> template 1. : document_type_1_custom_form_body.vm
>
> #parse("main_page_layout_header.vm")
> #parse("main_form_layout_header.vm")
> ## unique form fields here
> #parse("main_form_layout_header.vm")
> #parse("main_page_layout_header.vm")
>
> Not only is the same output achieved with fewer #parse() directives (3 v 5),
> the
> unique templates are fewer and easier to manage. Template designers can make
> many document_type_X templates and need only to define the reference
> $custom_form_body and not worry about the overall page layout. Custom parts of
> the page are also only optionally required now; the main template can test
> for a
> reference and display a default block if it isn't defined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VELOCITY-540) Make local directive part of Velocity engine core
Make local directive part of Velocity engine core - Key: VELOCITY-540 URL: https://issues.apache.org/jira/browse/VELOCITY-540 Project: Velocity Issue Type: Wish Components: Engine Reporter: Christoph Reck I prefer #local vs velocimacro.context.localscope because you can create macro libraries that allow declaring local vars without polluting the namespace, but also enables setting global variables. See the thread ending on 16.04.2007 "RE: velocimacro.context.localscope" with the #springBind example for such a case. If #local is not part of the core, it cannot be used for general purpose velocity macro libraries... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-535) org.apache.velocity.exception.ParseErrorException: Encountered "" at...
[ https://issues.apache.org/jira/browse/VELOCITY-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484856 ] Christoph Reck commented on VELOCITY-535: - The parse error indicates that some construct is not complete (an #if of #foreach without a corresponding #end). It would be helpful if the velocity parser would point to the start of this construct istead of the current message. In the middle of the most indented level I see a probable cause: #end #else both at the same level... I don't see the #if for this #else... Further down are two #end statements, also at the same innermost level. This should not have been posted to the Velocity-bugtracker, better place would have been the user@velocity.apache.org > org.apache.velocity.exception.ParseErrorException: Encountered "" at... > - > > Key: VELOCITY-535 > URL: https://issues.apache.org/jira/browse/VELOCITY-535 > Project: Velocity > Issue Type: Bug > Components: Engine >Affects Versions: 1.5 > Environment: Windows Xp-Vista-Srv 2003; JDK1.5.0_11;Tomcat 5.5.17; > Struts 2.0.6 >Reporter: Jean Seurin > Attachments: SearchSchedule.vm > > > Suddenly receive a org.apache.velocity.exception.ParseErrorException: > Encountered "" at line (last line, last char of the template) for the > attached template. > No particular reason, it used to work perfectly. It doesn't not anymore, > whatever I put at the end of the template (##, several blank lines, etc...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-519) Java escape sequences should work in Velocity macros
[
https://issues.apache.org/jira/browse/VELOCITY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475835
]
Christoph Reck commented on VELOCITY-519:
-
If inserting & automatic translation of unicode characters work, the template
writer might predefine and use $tab, $CR, $LF constants instead of \t, \r \n
thus keeping BC.
#set( $tab = "\u0009" )
...
#if( $samplestring.contains($tab) )
P.S. in the past I used the UrlDecoder to achieve this.
> Java escape sequences should work in Velocity macros
>
>
> Key: VELOCITY-519
> URL: https://issues.apache.org/jira/browse/VELOCITY-519
> Project: Velocity
> Issue Type: New Feature
>Affects Versions: 1.5 beta2
>Reporter: Stepan Koltsov
> Fix For: 1.6
>
> Attachments: velocity-unescape-2007-02-24-stepancheg.diff,
> velocity-unescape-only-u-2007-02-24-stepancheg.diff
>
>
> Following test should work:
> ===
> public void testJavaEscape() throws Exception {
> VelocityEngine ve = new VelocityEngine();
> ve.init();
> Context context = new VelocityContext();
> StringWriter writer = new StringWriter();
> ve.evaluate(context, writer, "test","#set($v = \"\\u0061\")$v");
> assertEquals("a", writer.toString());
> writer = new StringWriter();
> ve.evaluate(context, writer, "test","#set($v = \"\\n\")$v");
> assertEquals("\n", writer.toString());
> }
> ===
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-149) allow for deeply nested macro calls
[
https://issues.apache.org/jira/browse/VELOCITY-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461924
]
Christoph Reck commented on VELOCITY-149:
-
The multi-line directives of (upcoming) 1.5 release and the better
quote-escaping ("using a doubled "" quote" in the quoted string"), seems to
make this request obsolete.
The following looks akward to me:
#macro1("foo-#macro2("bar")-baz")
Can someone tell me in which programming language this would be possible?
Going with normal "programming" practices, you would unwrap this into:
#set( $bar = "#macro2('bar')" )
#macro1("foo-${bar}-baz")
OTOH, this requests seems related to
http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11751.html which
could be more useful than the above akward assembly.
> allow for deeply nested macro calls
> ---
>
> Key: VELOCITY-149
> URL: https://issues.apache.org/jira/browse/VELOCITY-149
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.3-rc1
> Environment: Operating System: All
> Platform: All
>Reporter: Ralf Hauser
>Priority: Minor
> Fix For: 1.5
>
>
> currently, it appears that more than two levels get almost unfeasible.
> see also http://sourceforge.net/mailarchive/message.php?msg_id=4015929
> Being able to do multi-line string literals or macro arguments is probably a
> related idea (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17803)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-496) Allow periods in references secondary keys.
[
http://issues.apache.org/jira/browse/VELOCITY-496?page=comments#action_12450686
]
Christoph Reck commented on VELOCITY-496:
-
Claudes request affects the ueberspector, but has a minor BC issue.
The ${map.{foo.bar}.baz}schmoo syntax is a parser change - and could make it
into 1.5 if it is a minor change. Who can check if the parser can be updated
for this syntatic upgrade? Please note that the unit tests must pass after a
parser change.
Patches are welcome as Will states!
> Allow periods in references secondary keys.
> ---
>
> Key: VELOCITY-496
> URL: http://issues.apache.org/jira/browse/VELOCITY-496
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.6
>Reporter: Claude Brisson
>Priority: Minor
>
> This is a quite prospective proposal that emerged from a discussion in a
> VelocityTools JIRA issue (https://issues.apache.org/jira/browse/VELTOOLS-69).
> Its goal is to have the short syntax $map.foo.bar chek the existence of
> $map.get("foo.bar") when $map.foo is null.
> Backward compatibility is 99%, since it only breaks templates that rely on
> $map.foo.bar being an invalid reference while having foo.bar as key in map.
> The implementation doesn't look obvious, and we must ensure that there are no
> other side effects, yet this behaviour can be quite usefull when dealing with
> HTML field names that contain a period.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-496) Allow periods in references secondary keys.
[
http://issues.apache.org/jira/browse/VELOCITY-496?page=comments#action_12450329
]
Christoph Reck commented on VELOCITY-496:
-
For completeness: the implementation should also consider that a property
access after the map access might be used:
$map.foo.bar.baz
meaning
$map.get("foo.bar") .getBaz()
So a descision is needed if this feature will be supported.
Also consider having eplicit syntaxt for a map access with a dotted key:
$map.{foo.bar}.baz and ${map.{foo.bar}.baz}schmoo
which would resolve this issue and my completeness request
> Allow periods in references secondary keys.
> ---
>
> Key: VELOCITY-496
> URL: http://issues.apache.org/jira/browse/VELOCITY-496
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
>Affects Versions: 1.6
>Reporter: Claude Brisson
>Priority: Minor
>
> This is a quite prospective proposal that emerged from a discussion in a
> VelocityTools JIRA issue (https://issues.apache.org/jira/browse/VELTOOLS-69).
> Its goal is to have the short syntax $map.foo.bar chek the existence of
> $map.get("foo.bar") when $map.foo is null.
> Backward compatibility is 99%, since it only breaks templates that rely on
> $map.foo.bar being an invalid reference while having foo.bar as key in map.
> The implementation doesn't look obvious, and we must ensure that there are no
> other side effects, yet this behaviour can be quite usefull when dealing with
> HTML field names that contain a period.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
