[EMAIL PROTECTED]: Project velocity-texen-test (in module velocity-texen) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project velocity-texen-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - velocity-texen-test : Texen is a general purpose text generating utility based on ... Full details are available at: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/velocity-texen/velocity-texen-test/gump_work/build_velocity-texen_velocity-texen-test.html Work Name: build_velocity-texen_velocity-texen-test (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Ddeprecation=false -Dversion=25012008 -Dskip.jar.loading=true test [Working Directory: /srv/gump/public/workspace/velocity-texen/build] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/velocity-texen/bin/test-classes:/srv/gump/public/workspace/velocity-texen/test/texen-classpath/test.jar:/srv/gump/public/workspace/velocity-texen/bin/texen-25012008.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/apache-commons/collections/build/commons-collections-25012008.jar:/srv/gump/public/workspace/apache-commons/lang/commons-lang-25012008.jar:/srv/gump/public/workspace/logging- log4j-12/dist/lib/log4j-25012008.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/packages/werken-xpath/werken-xpath-0.9.4.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-25012008.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-dep-25012008.jar:/srv/gump/public/workspace/velocity-anakia/bin/anakia-25012008.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar - compile-src: compile-test: [javac] Compiling 6 source files to /srv/gump/public/workspace/velocity-texen/bin/test-classes test-jar: [mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test [jar] Building jar: /srv/gump/public/workspace/velocity-texen/bin/test/texen-classpath.jar test: [mkdir] Created dir: /srv/gump/public/workspace/velocity-texen/bin/test-reports [junit] Running org.apache.texen.ExtendedTexenTestCase [junit] Template results directory does not exist [junit] Created template results directory [junit] Generating to file bin/test/texen-generator/report [junit] Comparing result file 'bin/test/texen-generator/TurbineWeather.java' with compare file 'test/texen/compare/TurbineWeather.java' [junit] Comparing result file 'bin/test/texen-generator/TurbineWeatherService.java' with compare file 'test/texen/compare/TurbineWeatherService.java' [junit] Comparing result file 'bin/test/texen-generator/WeatherService.java' with compare file 'test/texen/compare/WeatherService.java' [junit] Comparing result file 'bin/test/texen-generator/book.txt' with compare file 'test/texen/compare/book.txt' [junit] Comparing result file 'bin/test/texen-generator/Text.txt' with compare file 'test/texen/compare/Text.txt' [junit] Template results directory does not exist [junit] Created template results directory [junit] java.lang.NullPointerException [junit] at java.io.Reader.init(Reader.java:61) [junit] at java.io.InputStreamReader.init(InputStreamReader.java:80) [junit] at org.apache.commons.collections.ExtendedProperties.load(ExtendedProperties.java:573) [junit] at org.apache.commons.collections.ExtendedProperties.load(ExtendedProperties.java:549) [junit] at org.apache.texen.test.TestUtil.loadProperties(TestUtil.java:156) [junit] at org.apache.texen.ExtendedTexenTestCase.testExtendedTexenClasspath(ExtendedTexenTestCase.java:158) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Re: Blocks in Velocimacros
Really great to see your contribution
I haven't had time to review this in detail yet. But I want to make sure
users will be able to use block macros when put at the top of a file, or
when included with #parse. It's not feasible in many setups to include the
block macros in a globally accessible file.
WILL
On Jan 25, 2008 10:28 AM, Nathan Bubna [EMAIL PROTECTED] wrote:
On Jan 25, 2008 10:15 AM, Claude Brisson [EMAIL PROTECTED] wrote:
Very interesting work!
ditto! will you open a JIRA issue open so we can start easily sharing
code and tracking these ideas in one place?
About the different alternatives - none of them really pleases me.
There's another option: not allowing block macros to be used before they
are defined. Okay, you cannot make crossed reflexivity with block macros
without... is it such a big deal?
I dunno. I think discouraging the use of block macros prior to
registering them in combination with having option #4 (the prefix)
available for those who say but i NEED it! seems tolerable to me.
We could just state in the documentation that we strongly recommend
you define your block macros globally in a velocimacro library or
something like that. I don't think, though, that we need to bother
have the prefix be configurable. It's already confusing enough that
we would need one, without making it worse by having it vary from user
to user.
Claude
Le jeudi 24 janvier 2008 à 19:53 -0500, Raghu Rajah a écrit :
Apologies for a delayed response on this thread. Was buried in some
work for
the past couple of weeks. Was able to spend some time on this past
couple of
days. Here's what I have,
I have a working version of the blockmacro as discussed in this
thread.
Patch attached. Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
In broad brush strokes, here's what I did,
- Modified the grammar to look for blockmacro and register just like
the
regular macro would.
- Created a new proxy for this and dealt with creating this one for
block
macros.
I am yet to finish up some things,
- Making yield variable configurable
- want to make the proxy class interceptable (I need this ability to
intercept and manipulate content)
- the default templatetests doesn't seem to be comparing with the
cmps. Is
there something I need to do special to make this work. If I replace
the
content of any existing content with garbage, the tests still pass.
Would
appreciate help in pointing me in the right direction here.
- refactor my current tests to be in alignment with other tests within
the
project and add more complex tests.
Bumped in to a catch though,
- If the block macro is used before it is declared, I would have no
idea if
the macro is a LINE one or a BLOCK one. Currently, I am defaulting to
LINE
which will make template parsing fail. There are four alternatives, I
can
think of,
OPTION-1: Put a 'do' after my parameters.
#html(something) do
#end
Of course, 'do' could be optional, if html is defined already. The bad
thing
about this is it introduces new language semantics into VTL
OPTION-2: Create a call semantic for blockmacros
#callBlockMacro (html something)
#end
Again the callBlockMacro is optional, if you have defined html
already.
OPTION-3:Forward declaration for block macros.
#forwardBlock html
#forwardLine strong
OPTION-4 (My preference): A configurable convention on prefix suffix
(thank you, Conor, for the suggestion)
Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated.
Thanks,
Raghu.
On 1/7/08 11:48 AM, Will Glass-Husain [EMAIL PROTECTED]
wrote:
Not quite sure if I follow how this would work. I'm guessing you'll
have to do some tricks with the parser nodes to make this work
(since
at parse time the repository of macros is not yet defined). There's
probably a couple of ways of structuring this.
Look forward to seeing some code. Thanks again for your interest in
contributing!
WILL
On Jan 7, 2008 8:35 AM, Claude Brisson [EMAIL PROTECTED] wrote:
That does make sense. Thanks.
Since I would have the
repository of the defined velocimacros already, I can easily
determine if
the current macro is a block.
That is the specific point I was missing in your approach. Looks
totally
feasible.
Claude
Le lundi 07 janvier 2008 à 10:29 -0500, Raghu Rajah a écrit :
Maybe we are talking two different things.
1. I don't intend to distinguish the content variable (yield or
bodyContent)
from any other reference. It is just another reference as far as
the parser
is concerned. The
[jira] Created: (VELOCITY-583) BlockMacro support
BlockMacro support
--
Key: VELOCITY-583
URL: https://issues.apache.org/jira/browse/VELOCITY-583
Project: Velocity
Issue Type: New Feature
Components: Engine
Reporter: Raghu Rajah
Fix For: 1.6
Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
Full discussion on thread: http://tinyurl.com/ytq3k4
--
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]
RE: Blocks in Velocimacros
The best and preferred way is to add an entry in the JIRA bug report
system, with an attachment.
Claude
Le vendredi 25 janvier 2008 à 13:01 -0500, Raghu Rajah a écrit :
The attachment gets stripped. Is there a recommended way to send the patch
over?
Thanks,
Raghu.
From: [EMAIL PROTECTED]
To: dev@velocity.apache.org
Subject:
Date: Fri, 25 Jan 2008 12:57:19 -0500
Apologies for a delayed response on this thread. Was buried
in some work for
the past couple of weeks. Was able to spend some time on this past couple
ofdays. Here's what I have, I have a working version of the blockmacro as
discussed in this thread.Patch attached. Here's the trivial example,
#blockmacro(html $style)html style=$style ${yield}/html#end Block
Macro Result#html(color:red) bodyRaghu/body#end In broad brush
strokes, here's what I did, - Modified the grammar to look for blockmacro
and register just like theregular macro would.- Created a new proxy for this
and dealt with creating this one for blockmacros. I am yet to finish up some
things, - Making yield variable configurable- want to make the proxy class
interceptable (I need this ability tointercept and manipulate content)- the
default templatetests doesn't seem to be comparing with the cmps. Isthere
something I need to do special to make this work. If I replace thecontent of
any existing content with garbage, the tests still pass. Wouldappreciate help
in pointing me in the right direction here.- refactor my current tests to be
in alignment with other tests within theproject and add more complex tests.
Bumped in to a catch though, - If the block macro is used before it is
declared, I would have no idea ifthe macro is a LINE one or a BLOCK one.
Currently, I am defaulting to LINEwhich will make template parsing fail.
There are four alternatives, I canthink of, OPTION-1: Put a 'do' after my
parameters. #html(something) do#end
Of course, 'do' could be optional, if html is defined already. The bad
thingabout this is it introduces new language semantics into VTL OPTION-2:
Create a call semantic for blockmacros #callBlockMacro (html something)#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros. #forwardBlock html#forwardLine
strong OPTION-4 (My preference): A configurable convention on prefix
suffix(thank you, Conor, for the suggestion) Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated. Thanks, Raghu.
Shed those extra pounds with MSN and The Biggest Loser! Learn more.
_
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Blocks in Velocimacros
The attachment gets stripped. Is there a recommended way to send the patch over?
Thanks,
Raghu.
From: [EMAIL PROTECTED]
To: dev@velocity.apache.org
Subject:
Date: Fri, 25 Jan 2008 12:57:19 -0500
Apologies for a delayed response on this thread. Was buried in
some work for
the past couple of weeks. Was able to spend some time on this past couple
ofdays. Here's what I have, I have a working version of the blockmacro as
discussed in this thread.Patch attached. Here's the trivial example,
#blockmacro(html $style)html style=$style ${yield}/html#end Block Macro
Result#html(color:red) bodyRaghu/body#end In broad brush strokes, here's
what I did, - Modified the grammar to look for blockmacro and register just
like theregular macro would.- Created a new proxy for this and dealt with
creating this one for blockmacros. I am yet to finish up some things, - Making
yield variable configurable- want to make the proxy class interceptable (I need
this ability tointercept and manipulate content)- the default templatetests
doesn't seem to be comparing with the cmps. Isthere something I need to do
special to make this work. If I replace thecontent of any existing content with
garbage, the tests still pass. Wouldappreciate help in pointing me in the right
direction here.- refactor my current tests to be in alignment with other tests
within theproject and add more complex tests. Bumped in to a catch though, - If
the block macro is used before it is declared, I would have no idea ifthe macro
is a LINE one or a BLOCK one. Currently, I am defaulting to LINEwhich will make
template parsing fail. There are four alternatives, I canthink of, OPTION-1:
Put a 'do' after my parameters. #html(something) do#end
Of course, 'do' could be optional, if html is defined already. The bad
thingabout this is it introduces new language semantics into VTL OPTION-2:
Create a call semantic for blockmacros #callBlockMacro (html something)#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros. #forwardBlock html#forwardLine
strong OPTION-4 (My preference): A configurable convention on prefix
suffix(thank you, Conor, for the suggestion) Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated. Thanks, Raghu.
Shed those extra pounds with MSN and The Biggest Loser! Learn more.
_
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
[jira] Commented: (VELOCITY-406) Improved Syntax for Maps and Collections
[
https://issues.apache.org/jira/browse/VELOCITY-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562476#action_12562476
]
Stephen Colebourne commented on VELOCITY-406:
-
I support this RFE for list access using [ ].
I expected the syntax ${someList[1]} to work in Velocity, and was surprised
when it didn't. Perhaps VELOCITY-533 has made this more feasible?
Personally, I only need the 'get' behaviour, and not the 'set' behaviour, but
they should be logically introduced together.
I also don't see the need for ${someList.1} to work - that seems like overkill
syntax.
Improved Syntax for Maps and Collections
Key: VELOCITY-406
URL: https://issues.apache.org/jira/browse/VELOCITY-406
Project: Velocity
Issue Type: Improvement
Components: Engine
Reporter: Jörg Gottschling
Priority: Minor
Fix For: 1.6
I would like to see some syntatic sugar for Maps and Collections and perhaps
other Objects too.
(I have read that there will be a syntax for map literals in 1.5, that's a
first step.)
I want to have something like in groovy:
http://groovy.codehaus.org/Collections
Scroll down to Slicing with the subscript operator.
PS: Please do never implement this terrible confusing groovy map bean syntax,
where map.foo ist equivalent to map.get(foo).
--
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]
RE: Blocks in Velocimacros
Created Jira Issue (VELOCITY-583 - http://tinyurl.com/yw5hbh)
Attached code as a patch to the jira issue.
I will take a prefix approach with _ as the default, without any
configurability of the prefix.
Raghu.
Date: Fri, 25 Jan 2008 10:28:32 -0800
From: [EMAIL PROTECTED]
To: dev@velocity.apache.org
Subject: Re: Blocks in Velocimacros
On Jan 25, 2008 10:15 AM, Claude Brisson [EMAIL PROTECTED] wrote:
Very interesting work!
ditto! will you open a JIRA issue open so we can start easily sharing
code and tracking these ideas in one place?
About the different alternatives - none of them really pleases me.
There's another option: not allowing block macros to be used before they
are defined. Okay, you cannot make crossed reflexivity with block macros
without... is it such a big deal?
I dunno. I think discouraging the use of block macros prior to
registering them in combination with having option #4 (the prefix)
available for those who say but i NEED it! seems tolerable to me.
We could just state in the documentation that we strongly recommend
you define your block macros globally in a velocimacro library or
something like that. I don't think, though, that we need to bother
have the prefix be configurable. It's already confusing enough that
we would need one, without making it worse by having it vary from user
to user.
Claude
Le jeudi 24 janvier 2008 à 19:53 -0500, Raghu Rajah a écrit :
Apologies for a delayed response on this thread. Was buried in some work
for
the past couple of weeks. Was able to spend some time on this past couple
of
days. Here's what I have,
I have a working version of the blockmacro as discussed in this thread.
Patch attached. Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
In broad brush strokes, here's what I did,
- Modified the grammar to look for blockmacro and register just like the
regular macro would.
- Created a new proxy for this and dealt with creating this one for block
macros.
I am yet to finish up some things,
- Making yield variable configurable
- want to make the proxy class interceptable (I need this ability to
intercept and manipulate content)
- the default templatetests doesn't seem to be comparing with the cmps. Is
there something I need to do special to make this work. If I replace the
content of any existing content with garbage, the tests still pass. Would
appreciate help in pointing me in the right direction here.
- refactor my current tests to be in alignment with other tests within the
project and add more complex tests.
Bumped in to a catch though,
- If the block macro is used before it is declared, I would have no idea
if
the macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINE
which will make template parsing fail. There are four alternatives, I can
think of,
OPTION-1: Put a 'do' after my parameters.
#html(something) do
#end
Of course, 'do' could be optional, if html is defined already. The bad
thing
about this is it introduces new language semantics into VTL
OPTION-2: Create a call semantic for blockmacros
#callBlockMacro (html something)
#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros.
#forwardBlock html
#forwardLine strong
OPTION-4 (My preference): A configurable convention on prefix suffix
(thank you, Conor, for the suggestion)
Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated.
Thanks,
Raghu.
On 1/7/08 11:48 AM, Will Glass-Husain [EMAIL PROTECTED] wrote:
Not quite sure if I follow how this would work. I'm guessing you'll
have to do some tricks with the parser nodes to make this work (since
at parse time the repository of macros is not yet defined). There's
probably a couple of ways of structuring this.
Look forward to seeing some code. Thanks again for your interest in
contributing!
WILL
On Jan 7, 2008 8:35 AM, Claude Brisson [EMAIL PROTECTED] wrote:
That does make sense. Thanks.
Since I would have the
repository of the defined velocimacros already, I can easily
determine if
the current macro is a block.
That is the specific point I was missing in your approach. Looks
totally
feasible.
Claude
Le lundi 07 janvier 2008 à 10:29 -0500, Raghu Rajah a écrit :
Maybe we are talking two different things.
1. I don't intend to distinguish the content variable (yield or
bodyContent)
from any other reference. It is just another reference as far as the
parser
is concerned. The only
[jira] Updated: (VELOCITY-583) BlockMacro support
[
https://issues.apache.org/jira/browse/VELOCITY-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raghu Rajah updated VELOCITY-583:
-
Attachment: blockmacro.patch
First cut. I have a working version of the blockmacro as discussed.
Patch attached. Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
In broad brush strokes, here's what I did,
- Modified the grammar to look for blockmacro and register just like the
regular macro would.
- Created a new proxy for this and dealt with creating this one for block
macros.
I am yet to finish up some things,
- Making yield variable configurable
- want to make the proxy class interceptable (I need this ability to
intercept and manipulate content)
- the default templatetests doesn't seem to be comparing with the cmps. Is
there something I need to do special to make this work. If I replace the
content of any existing content with garbage, the tests still pass. Would
appreciate help in pointing me in the right direction here.
- refactor my current tests to be in alignment with other tests within the
project and add more complex tests.
Bumped in to a catch though,
- If the block macro is used before it is declared, I would have no idea if
the macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINE
which will make template parsing fail. There are four alternatives, I can
think of,
OPTION-1: Put a 'do' after my parameters.
#html(something) do
#end
Of course, 'do' could be optional, if html is defined already. The bad thing
about this is it introduces new language semantics into VTL
OPTION-2: Create a call semantic for blockmacros
#callBlockMacro (html something)
#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros.
#forwardBlock html
#forwardLine strong
OPTION-4 (My preference): A configurable convention on prefix suffix
(thank you, Conor, for the suggestion)
Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated.
BlockMacro support
--
Key: VELOCITY-583
URL: https://issues.apache.org/jira/browse/VELOCITY-583
Project: Velocity
Issue Type: New Feature
Components: Engine
Reporter: Raghu Rajah
Fix For: 1.6
Attachments: blockmacro.patch
Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
Full discussion on thread: http://tinyurl.com/ytq3k4
--
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]
Re: Blocks in Velocimacros
Very interesting work!
About the different alternatives - none of them really pleases me.
There's another option: not allowing block macros to be used before they
are defined. Okay, you cannot make crossed reflexivity with block macros
without... is it such a big deal?
Claude
Le jeudi 24 janvier 2008 à 19:53 -0500, Raghu Rajah a écrit :
Apologies for a delayed response on this thread. Was buried in some work for
the past couple of weeks. Was able to spend some time on this past couple of
days. Here's what I have,
I have a working version of the blockmacro as discussed in this thread.
Patch attached. Here's the trivial example,
#blockmacro(html $style)
html style=$style
${yield}
/html
#end
Block Macro Result
#html(color:red)
bodyRaghu/body
#end
In broad brush strokes, here's what I did,
- Modified the grammar to look for blockmacro and register just like the
regular macro would.
- Created a new proxy for this and dealt with creating this one for block
macros.
I am yet to finish up some things,
- Making yield variable configurable
- want to make the proxy class interceptable (I need this ability to
intercept and manipulate content)
- the default templatetests doesn't seem to be comparing with the cmps. Is
there something I need to do special to make this work. If I replace the
content of any existing content with garbage, the tests still pass. Would
appreciate help in pointing me in the right direction here.
- refactor my current tests to be in alignment with other tests within the
project and add more complex tests.
Bumped in to a catch though,
- If the block macro is used before it is declared, I would have no idea if
the macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINE
which will make template parsing fail. There are four alternatives, I can
think of,
OPTION-1: Put a 'do' after my parameters.
#html(something) do
#end
Of course, 'do' could be optional, if html is defined already. The bad thing
about this is it introduces new language semantics into VTL
OPTION-2: Create a call semantic for blockmacros
#callBlockMacro (html something)
#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros.
#forwardBlock html
#forwardLine strong
OPTION-4 (My preference): A configurable convention on prefix suffix
(thank you, Conor, for the suggestion)
Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated.
Thanks,
Raghu.
On 1/7/08 11:48 AM, Will Glass-Husain [EMAIL PROTECTED] wrote:
Not quite sure if I follow how this would work. I'm guessing you'll
have to do some tricks with the parser nodes to make this work (since
at parse time the repository of macros is not yet defined). There's
probably a couple of ways of structuring this.
Look forward to seeing some code. Thanks again for your interest in
contributing!
WILL
On Jan 7, 2008 8:35 AM, Claude Brisson [EMAIL PROTECTED] wrote:
That does make sense. Thanks.
Since I would have the
repository of the defined velocimacros already, I can easily determine if
the current macro is a block.
That is the specific point I was missing in your approach. Looks totally
feasible.
Claude
Le lundi 07 janvier 2008 à 10:29 -0500, Raghu Rajah a écrit :
Maybe we are talking two different things.
1. I don't intend to distinguish the content variable (yield or
bodyContent)
from any other reference. It is just another reference as far as the
parser
is concerned. The only variation is in the proxy directive, which would
wrap
the context to add the capability to yield (trap get on yield and render
content in-place).
2. I did not intend to add the block-macros as part of the parsing
environment. The parser will treat the block macro usage as yet another
velocimacro, this one just happens to be a block. Since I would have the
repository of the defined velocimacros already, I can easily determine if
the current macro is a block. All the Parser does here is to add the
content
as the child of the current AST, as opposed to a peer.
3. The real problem is to distinguish during definition if a macro is a
block-macro or a single-line one. Since there is no begin syntax for the
block I (as the parser) won't know for sure if the next line is a
beginning
of a block or simply another peer node. Which is why I need a new
directive
#block
Does this make sense? Let me know what you feel about this.
Raghu.
On 1/7/08 9:52 AM, Claude Brisson [EMAIL PROTECTED] wrote:
Le lundi 07 janvier 2008 à 07:34 -0500, Raghu Rajah a écrit :
Actually, I was saying the opposite. We can keep the calling semantics,
as
is. I might have to use an alternate directive (other than #macro) for
definition.
The definition parsing would become
[no subject]
Apologies for a delayed response on this thread. Was buried in
some work for
the past couple of weeks. Was able to spend some time on this past couple
ofdays. Here's what I have, I have a working version of the blockmacro as
discussed in this thread.Patch attached. Here's the trivial example,
#blockmacro(html $style)html style=$style ${yield}/html#end Block Macro
Result#html(color:red) bodyRaghu/body#end In broad brush strokes, here's
what I did, - Modified the grammar to look for blockmacro and register just
like theregular macro would.- Created a new proxy for this and dealt with
creating this one for blockmacros. I am yet to finish up some things, - Making
yield variable configurable- want to make the proxy class interceptable (I need
this ability tointercept and manipulate content)- the default templatetests
doesn't seem to be comparing with the cmps. Isthere something I need to do
special to make this work. If I replace thecontent of any existing content with
garbage, the tests still pass. Wouldappreciate help in pointing me in the right
direction here.- refactor my current tests to be in alignment with other tests
within theproject and add more complex tests. Bumped in to a catch though, - If
the block macro is used before it is declared, I would have no idea ifthe macro
is a LINE one or a BLOCK one. Currently, I am defaulting to LINEwhich will make
template parsing fail. There are four alternatives, I canthink of, OPTION-1:
Put a 'do' after my parameters. #html(something) do#end
Of course, 'do' could be optional, if html is defined already. The bad
thingabout this is it introduces new language semantics into VTL OPTION-2:
Create a call semantic for blockmacros #callBlockMacro (html something)#end
Again the callBlockMacro is optional, if you have defined html already.
OPTION-3:Forward declaration for block macros. #forwardBlock html#forwardLine
strong OPTION-4 (My preference): A configurable convention on prefix
suffix(thank you, Conor, for the suggestion) Blockmacro.default.prefix = _
Recommendations, alternate suggestions, would be appreciated. Thanks, Raghu.
_
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
