[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: #defineblock( $block_ref) ... #end implementation
From:       "Nathan Bubna" <nathan () esha ! com>
Date:       2003-04-28 23:57:55
[Download RAW message or body]

Andrew said:
> > anyway, i suppose the merits of the two methods are debatable.
> > #define is
> > more elegant, but it does significantly overlap the functionality of
> > #macro.
> > and, given the behavior i describe above, this notably changes the
> > predictability and, thus, the readability of VTL by blurring the line
> > between macros and references.  hmm.  not sure how i feel about this...
>
> Yes I felt the same way but was stuck.
...
> In my mind I've always seen references as a jack-of-all trades kind of
> thing when you consider that $ref could mean "hello" or a processing tool
> like $tools.evaluate("$source") or even $magicreference.method("arg1",
> "arg2").getSomething().moreProcessing()  ! But I take your point that
> normal references are rendered when set not parsed.

yes, i'm well aware that you can do just about anything with a reference.
i've even written some evaluate/render tools for the tools project myself
:-).

the "line" i was referring to was not about rendering vs. parsing.  it was
more a matter of macros being used for larger chunks or snippets of VTL
(display/view modularity) and references being more typically used as entry
points for data (interface between model and view).  of course, since few of
us actually work in perfectly MVC worlds (and IMHO, those aren't always the
best solution), references are frequently also used as tools for performing
custom and/or complex functions on the model data, as well as other such
not-very-MVCish things.

so, that said, the "line" is a little blurry already, and i'm not sure it
really matters (even when it comes to being strictly MVC).  IMHO, your
examples have shown realistic, wholly "V" behavior that would be elegantly
done with this directive.

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]