[
https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677775#action_12677775
]
Nathan Bubna commented on VELOCITY-704:
---------------------------------------
Alright, we'll stick with $evaluate as the default for
RuntimeInstance.evaluate(...) and #evaluate. It's easy enough for users to do
#if(!$template)#set( $template = $evaluate)#end at the top if they really
aren't sure (for some strange reason) whether the VTL they're writing will be
run through a resource loader or through evaluate and do want to use the scoped
variable storage. As i write that, i realize all the more how unlikely that
is... :)
Christoph, am i right that this #pragma you suggest would generally be a way to
change Velocity configuration from within a template? Probably best a
discussion for a separate thread, if so. Interesting idea, not sure what i
think of it yet.
Well, i think i'll start working on this more (porting to 2.x and documenting),
as you're making me more hopeful of some level of consensus. Doesn't seem like
anyone else has strong opinions here but us; even Claude, who birthed this idea
seems quiet now. ;-)
I know what i'm pushing for here isn't likely to be an easy pill to swallow for
those used to using velocimacro.context.localscope and other such "implicit
scoping" in languages, but i am sincerely convinced that this "explicit
scoping" is an overall win that will keep VTL more readable, reusable and
robust. It allows users much more control and flexibility than before at a
bare minimum of new concepts/code/complication. I also think it is going to
simplify development and user support efforts. So, despite the unfamiliarity
of this approach, if you bear with me and try to focus on what it adds and the
potential it could have, i think you may come to appreciate it! That said, if
you do see any more problems with it or flaws in my thinking, please keep
pointing them out. I'm already grateful for your pushback on this, as without
it, i would likely have stopped with the stop() method and not moved to the
much better #stop that is now implemented (not that you're sold on it yet, i
know ;).
> 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: [email protected]
For additional commands, e-mail: [email protected]
