[
https://issues.apache.org/jira/browse/VELOCITY-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna closed VELOCITY-703.
---------------------------------
Resolution: Duplicate
The goal of this issue is contained within VELOCITY-704, which has a much
better solution for being free of #break, #stop and #return via "control"
objects.
> VTL Simplicity - collapse #break, #stop and #return
> ---------------------------------------------------
>
> Key: VELOCITY-703
> URL: https://issues.apache.org/jira/browse/VELOCITY-703
> Project: Velocity
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Nathan Bubna
> Fix For: 2.0
>
>
> I think it is a too much to have #stop, #break and #return (optional or not)
> directives in the core for doing essentially the same thing in three
> different situations. I love that you cleaned up #stop first to
> exception-based impl and now to pull it from the parser. With the addition
> of #stop(parse), i think the time is right to be rid of #break and the new
> #return. What about doing something like this:
> #stop - stops the current parse, macro or foreach (this is the simple,
> common case)
> #stop( all ) - stops the whole merge
> #stop( parse ) - stops the current #parse
> #stop( macro ) - stops the current macro (aka #return)
> #stop( foreach ) - stops the current #foreach
> This would provide consistency, clarity, and extensibility. It's not hard to
> imagine allowing advanced users to add a second argument to those latter 3 to
> bubble the stop command up further levels
> #stop( parse 2 ) - stops 2 #parse levels
> #stop( macro $x ) - stops $x #macro levels
> #stop( foreach $loop.depth ) - stops as many #foreach levels as $loop knows
> about
> The point being to allow the desired control with one explicit, extensible,
> VTL-centric command and not clutter the namespace with concepts from other
> languages that tend to then suggest unwanted things. (e.g. #break -> break
> labels, continue; #return -> may imply macros are methods, returning values)
> I'm, of course, willing to help with this.
--
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-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
