[
https://issues.apache.org/jira/browse/VELOCITY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497535
]
bruce sherrod commented on VELOCITY-174:
----------------------------------------
Yes, Will -- #extends is like #parse, but with two differences: (1) #extends
appears first, rather than last, and (2) VTL in the body of the second template
is not rendered. So, the "child" template only overrides the defined regions
from the parent template. (via #set and #define).
A more complex example:
a.vm:
#define ($header)
default header
#end
#define ($body)
default body
#end
#define ($footer)
default footer
#end
$header
$body
$footer
b.vm:
#extends("a.vm")
#define ($body)
b body
#end
c.vm:
#extends("a.vm")
#define($header)
c custom header
#end
#define ($body)
c body
#end
This is conceptually similar to object inheritance with overridden virtual
methods.
It is based on django's template system:
http://www.djangoproject.com/documentation/templates/#template-inheritance
> For consideration: #define()...#end directive to define a block of VTL as a
> reference
> -------------------------------------------------------------------------------------
>
> Key: VELOCITY-174
> URL: https://issues.apache.org/jira/browse/VELOCITY-174
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.3.1
> Environment: Operating System: All
> Platform: All
> Reporter: Andrew Tetlaw
> Priority: Minor
> Fix For: 1.6
>
> Attachments: Define.java, Extends.java
>
>
> * Proposal:
> #define( $block_ref )
> ## any VTL / text content here
> ...
> #end
> then you can use it like a reference:
> <html><body> $!block_ref </body></html> / #if( $block_ref ).. #end / and so on
> * Justification:
> 1. Allows template designer to use a more efficient inside -> out approach
> (similar to Nathan's VelocityLayoutServlet)
> 2. Keeps macro framework separate (the app developer can still disallow inline
> macros)
> 3. #macros to return blocks of VTL cannot be used like silent references or in
> other directives (like #if)
> 4. The multi-line #set proposal requires a quoted value. A #define() block can
> contain anything (without the need to escape quotes for example).
> 5. #define() blocks are proxied (like #macros) and thus change according to
> the
> context after they are defined, something a normal $reference or #set can't
> do.
> 7. Can improve template management by reducing number of unique template
> components
> 8. Can improve template security/errors by reducing the need for bottom tier
> template makers to worry about generic layout code and visa-versa.
> 9. Merges the strengths of #macros and $references = best of both worlds
> * Usage Example: Custom HTML forms:
> template 1. : document_type_1_custom_form_body.vm
> ----
> #define( $custom_form_body )
> ## unique form fields here
> #end
> #parse("main_form_layout.vm")
> ----
> template 2 : main_form_layout.vm
> ----
> #define( $custom_page_body )
> <form>
> ## common form fields here
> $!custom_form_body
> <input type="submit" value="submit">
> </form>
> #end
> #parse("main_page_layout.vm")
> ----
> template 2 : main_page_layout.vm
> ----
> <html><body>
> ## common page layout html here
> $!custom_page_body
> </body></html>
> ----
> If the #define() directive was not available a template designer would need to
> do this:
> template 1. : document_type_1_custom_form_body.vm
> ----
> #parse("main_page_layout_header.vm")
> #parse("main_form_layout_header.vm")
> ## unique form fields here
> #parse("main_form_layout_header.vm")
> #parse("main_page_layout_header.vm")
> ----
> Not only is the same output achieved with fewer #parse() directives (3 v 5),
> the
> unique templates are fewer and easier to manage. Template designers can make
> many document_type_X templates and need only to define the reference
> $custom_form_body and not worry about the overall page layout. Custom parts of
> the page are also only optionally required now; the main template can test
> for a
> reference and display a default block if it isn't defined.
--
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]
