[
https://issues.apache.org/jira/browse/VELOCITY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675389#action_12675389
]
Byron Foster commented on VELOCITY-704:
---------------------------------------
<quote>For instance, #break exists all the time, even when not in a
#foreach</qoute>
That's only because it is implemented that way. If you look at the #return
directive it validates that it's in a #macro block at template load time
(during init). #break could do the same. However, we can do better, my plan
was to beef up the directive validation at parse time, then Velocity smart
IDE's like Veloeclipse could validate #break and #return as the user edits her
VTL. This level of validation is simply not an option for .stop().
<qoute>It is obvious what $foreach.stop() does</qoute>
This is all very subjective of course, that's why there's a hundred million
languages out there. However, people with a programming background, most users
I would think, are going to instantly understand what #break does (and #return
for that matter). And to the non-programmers it's not going to make any
difference. To me, again subjective, $foreach.stop() looks like a reference
that's emitting content. I'm not against $foreach.stop() constructs, I'm more
indifferent, I'm just arguing for a directive solution also. However, I can
tell you're against a dual solution, and yes I think you could make a good
argument for this, so you don't need to :)
I regret having proposed #stop(parse) or #break(glass). I think it confused
the issue, when all that was of real interest to me was #return and adding an
'index' keyword to #foreach. I was thinking #return would get as much
resistance as this VELOCITY-612 :)
<qoute>then i would go back to pushing hard for just one #stop()
directive</qoute>
I'll take it. So, something like this:
#stop(all)
#stop(parse)
#stop(macro) = #return
#stop(foreach) = #break
What would #stop do?
> 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]
