[jira] Created: (VELOCITY-704) VTL Simplicity - "Control" objects

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677789#action_12677789 ]

Byron Foster commented on VELOCITY-704:
---------------------------------------

You know I think these discussions get buried in these tickets.  For example in this ticket there are really about 4 issues being discussed.

About the #evaluate scope, I really don't have an opinion, I have never used this directive so I don't have a feel for what makes since in practice.  If you have a strong persuasion, and there is no other opinion, then go with your gut :)

I'm indifferent about #pragma, but I don't think it solves the default scoping behavior since those of us who prefer the default to be macro would want it system wide, and don't want to have to specify the behavior on every page.  This takes us then to a velocity.properties setting, and ...

Ok, I don't like to be the last word type, but I do have to respectively address your presentation of defaulting to global scope  :)  Your labels of "implicit scoping" vs "explicit scoping" I think are not accurate.  Look, the only question is what does #set($foo = "bar") do???  I assert that the default behavior should be macro scope (No side effects), you assert global scope.  I don't think either approach is more "explicit" or "implicit".

I agree with everything else you say.  I like this approach in general to scoping.  And yes, it's a huge improvement over where VTL is now where I don't think even the committers could give a concise set of rules that describe current scoping behavior.  Adding scope control, and formalizing the behavior is good for everybody.

Yes, I hated $foreach.stop()  :)  #stop($foreach) is much better, even though I have a strong feeling I'll continue to use #break, the second class directive, I'm a creature of habit!

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678280#action_12678280 ]

Claude Brisson commented on VELOCITY-704:
-----------------------------------------

I'm pleased with your choises so far - what should the behaviour of #stop be when invoked without any argument?
 - most global scope = current behaviour
 - most local scope = much more interesting imho

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678327#action_12678327 ]

Claude Brisson commented on VELOCITY-704:
-----------------------------------------

What about :
#break -> cancel most inner scope
#stop -> exit merging (and rather than the scope, I'd give it an info string, since it's often the way to handle error cases)
this looks rather backward compatible and intuitive

anyway, this is a side debate since this syntax is accessible with macros (I'd let the Scope.stop() anyway).

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678340#action_12678340 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Another vote to keep #break around, eh?  :)  How about this:

#break  -> stop innermost scope
#break($<scope>) -> stop specified scope
#stop -> stop outermost scope w/no message
#stop("info string") -> stop outermost scope w/message

I can't say i consider this to be as simple or straightforward.  But since we do already have both directives in 1.x and #break seems to have some fans, i can live with this.   I'll just rationalize that all of the users who would bother with these features won't be confused by having two such similar directives.  After all, we already have the #define and #macro cousins, and i've yet to figure out a clean way to consolidate those two either.

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678350#action_12678350 ]

Claude Brisson commented on VELOCITY-704:
-----------------------------------------

Fine for me.

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678351#action_12678351 ]

Claude Brisson commented on VELOCITY-704:
-----------------------------------------

except maybe that we can keep #stop($<scope>) (so #<scope>(scope/string) is overloaded), #break being always invoked without args

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679027#action_12679027 ]

Byron Foster commented on VELOCITY-704:
---------------------------------------

I like your proposal Nathan, and I like Claude's suggested alteration.

I'm curious about the #stop string parameter.  Where would this be displayed?  It seems that an #error or #assert directive would be a better fit for indicating errors, or debugging. but I'm indifferent.  Hmm, I like #assert though...

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679031#action_12679031 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

The current implementation has it printed to the logs as a debug string  "StopCommand: <message here>".  I can't imagine doing anything else with it but debugging.

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681092#action_12681092 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Ok, i've ported the changes to 2.0 and started cleaning out the things it replaces.  So far, #return, $velocityCount and $velocityHasNext are gone.  Next on the chopping block is velocimacro.context.localscope, then #global, #local and inner supporting code.   You'll probably notice that it is a bit awkward to remove one part at a time.  Since this is something of a paradigm shift, some of the related tests don't even make sense now.  Bear with me if some of the intermediate stages have odd loose ends.  I do think though, that doing it in stages should be easier to follow than taking them all out at once.

Once all is cleaned up, i'll start work on the documentation updates as i have time.

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681178#action_12681178 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Ok, i think that should do it code-wise.  Now for documentation...

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681415#action_12681415 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Ok, not quite done with code changes...   I just realized i overlooked one pocket of implicit, non-optional local context:  EvaluateContext.   Will, are you tracking this?  If so, do you recall the reasons for making context changes within #evaluate local?  This is rather different than VelocityTools' ViewRenderTool which uses the current context.

Also, there's support for using custom context classes for that local scope.  I'm trying to think of the use-case for this but drawing a complete blank.  I obviously need to deprecate it in 1.7 and yank it from 2.0 to be consistent, but i'm still curious about what it was for.  Also, i'm tempted to revert to global scope for 1.7 unless the user specifies a local context class.  Thoughts?

> 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

     [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Bubna resolved VELOCITY-704.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 1.7

That should do it, i think.

> 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: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705246#action_12705246 ]

Jarkko Viinamäki commented on VELOCITY-704:
-------------------------------------------

Duh. Based on my velocity testbench (with test case similar to one in VELOCITY-24) the 1.7-dev (current head) is about 20% slower than 1.6.2.

Profiling shows that in 1.7-dev most of the time is spent on RuntimeMacro.render and VelocimacroProxy.render. This is due to new preRender and postRender methods and new scoping functionality. Since there is some instanceof-checking, object creation and hashmap overhead, it will be difficult to improve this. It also affects all macro calls regardless if you use the new functionality or not. :/

> 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: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705655#action_12705655 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Ay, a speed hit is expected.  Though i think it is worth it for the features and simplification it offers.  I do hope we can improve on the speed.  Of course, if you don't use the feature and want faster macros, the simplest fix is:

macro.provide.scope.control = false

then it's just a boolean condition check in both preRender and postRender.

Also, in 2.0, some of the lost ground should be recovered (i expect) since 1.7 has a lot of now-deprecated functionality that has been removed from the 2.0 branch (velocimacro.context.localscope, velocityCount, velocityHasNext, etc

As for particular speed improvements, i haven't done any testing or much thinking yet, but when i first wrote this i did consider replacing a lot of those:

if (obj instanceof Scope) {  this } else { that }

with

try {  this } catch (ClassCastException) { that }

since i think it will be rather rare (and increasingly so in the future) that people will override Scope instances in their context.   But, without doing any performance testing to compare the two approaches, i figured it was best to start out doing it "the right way" and worry about optimizing later.  The one other idea i had was to keep a small map of  "scoped directive" stacks (or something like that) in the InternalContextAdapter and lazily create Scope objects as requested.  It seemed more difficult to do at the time though, and again, without performance numbers to compare it was hard to justify the effort.   Anyway, all that is to say that i think we can do better here performance-wise; it'll just take a little testing and refactoring. :)

> 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: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

     [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nathan Bubna reassigned VELOCITY-704:
-------------------------------------

    Assignee:     (was: Nathan Bubna)

> 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
>             Fix For: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710945#action_12710945 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

I was thinking about this and realized that we really shouldn't have any of these turned on by default, except for $foreach.   I believe this is the only one that provides things otherwise available with the default settings now.  The others would be extras and only really needed when someone wants a local scope and/or wants to #break to a particular $<scope>, neither of which is likely to be standard use.

Having $macro, $template, $evaluate, $define and $<macroname> off by default should reduce the overhead to a boolean check.  Those who wish to use $macro or the like, may turn them on, just as they currently have to turn on the now-deprecated velocimacro.context.localscope.

> 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
>             Fix For: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Velocity - Dev mailing list-2]

    [ https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712467#action_12712467 ]

Nathan Bubna commented on VELOCITY-704:
---------------------------------------

Ok, now all are off by default, except $foreach.  I also did some quick tests and try-catch was faster than instanceof, so i swapped those too.   I am still thinking it would be better to keep a stack of ScopeOwners in the InternalContextAdapter and create them on demand (which would also obviate the whole Scope.getReplaced() thing), but i'm not sure i'll get to that soon.  First, i'm gonna copy these changes in the 2.x branch.

> 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
>             Fix For: 1.7, 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-unsubscribe@...
For additional commands, e-mail: dev-help@...