[
https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676128#action_12676128
]
Nathan Bubna commented on VELOCITY-704:
---------------------------------------
Yes, #set( $template.foo = 'bar' ) works for most cases, unless you are running
via engine.evaluate(), in which case $evaluate would be the global scope.
Which brings up a nagging thought. Should the scope for evaluate() also be
$template? I've tried to name the scope according to the context in which the
VTL is being written. The name for all of them was thus pretty obvious, except
for engine.evaluate(...) and #evaluate(...). Yes, they're different from
#parse or Template.merge, since you can directly put a string in when calling
them, but that string is always a template. Thoughts?
10-20% performance hit on what? Memory? Speed? And where is the hit?
Directive.init()? #stop? #set? I'd love to know more, though admittedly i'm
more concerned with getting features settled before optimizing anything.
As for #stop vs #break and #return, can you explain to me why you don't see
that? I feel like i've made my case already, but here's one more try: i
think 1 being "simpler" than 3 is pretty obvious--less to document, less to
debug, less to know. I think it is clearly "better" because advanced users
have complete control and are not limited to merely stopping the most immediate
foreach or macro. And "intuition" is terribly subjective. I'll only argue
that it is more VTL-centric because it doesn't introduce new terms from other
languages and the baggage they carry (break labels and return values). I was
really hoping to find some consensus between you and i about this, but if we
can't get that, then i'd love to hear from anyone else following this
discussion. What do you think?
No need to speculate about my macro usage, i've said before that prior to 1.6's
fixes and improvements, i considered it reckless to rely on them heavily.
Still, i have been using Velocity over 8 years now, so i might have made up
some in longevity of what i lacked in breadth? Who knows. And yeah, i share
the "traditional" opposition to thinking of macros as a "method call" construct
(thus my opposition to associating them with terms like 'return'). Changing
#set to default to localscope for 2.0 is a non-BC change that i currently would
consider inconsistent (what about #parse and #define?), unnecessary (as a user,
i've never seen fit to turn velocimacro.context.localscope to true, and as a
dev, it's been an occasional nuisance) and generally lacking in compelling
reasons to exist (all the moreso given the introduction of $macro). Still, if
you think you have a good case for it, i would love to hear you out. Though
perhaps in a different thread?
> 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]
