This all makes good sense, and frankly it's such a small nit, it
almost doesn't matter. My main earlier complaint about loops and
local variables (essentially my dislike of boilerplate code) was
already handled by the creation of the @Property annotation, so really
it's as I said, and aesthetic thing. You don't have to unit-test a
single private variable, so that's clean. I just don't like having a
variable that's only used by external code (even if auto-generated).
Feels un-encapsulated. But these arguments from Howard and Thiago are
compelling, and I was waffling about this anyway. This is part of the
reason I didn't JIRA it - I suspected it wasn't really worth doing,
unless there was an easy way we just hadn't thought of. Before seeing
T5 in action, I would have argued to have it work with reflection to
eliminate the code, but frankly this is a small price to pay for tons
of optimization.
Christian.
On 11-Feb-09, at 13:29 , Howard Lewis Ship wrote:
Just thought of a metaphor: think of all the wires on the back of you
TV/Stereo stack ... the page acts like receiver, which internally
connects all the components (TV, VCR, DVD, Wii) together. The result
is a star-shaped graph, rather than a tesselation (i.e., imagine all
the wires if every piece had to have a cable to connect it to every
other piece!)
On Wed, Feb 11, 2009 at 10:27 AM, Howard Lewis Ship
<[email protected]> wrote:
I think of the page (really component) class as the "faciliator",
between components in the template.
Also note that the type safety issue goes beyond performance; it's
also the gateway to optimizations and other features that rely on
type
and annotations. A var: may change its type at different times, and
will usually be null, making it hard to analyze statically. We could
add an annotation in the Java code to pin down the type of the var:
... but then its easier to use @Property. I use @Property all over
the place, I don't think I use var: very often at all. The only
situation that would make sense would be if I was iterating some
objects and had a component to, for example, display the object
properties.
On Wed, Feb 11, 2009 at 3:15 AM, Thiago H. de Paula Figueiredo
<[email protected]> wrote:
On Wed, Feb 11, 2009 at 12:54 AM, Christian Edward Gruber
<[email protected]> wrote:
Hey Howard et. al.
Hi!
<ol t:type="loop" t:source="listItems"
t:value="${var:(com.foo.bar.blah.MyObject)listItem}">
<li>${var:listItem.name}</li>
</ol>
Notice you end up writing more code than you would using a @Property
and it is way more fragile, as you would need to provide a fully
qualified class name without IDE autocompletion and it is not
refactoring-safe. I don't think it is a good idea.
In other words, it would explicitly provide a cast-like syntax to
allow the
bytecode manipulation to be instructed with the type. Now, I'm
not 100%
sure I think this is better than adding a single @Property
private MyObject
listItem in the code, but because this is truly a local variable
for this
iteration, it seems like having an instance variable is not
appropriate for
the purpose.
If you think that the page class and the template are just to
different sides of the same thing (the page) and that the template
is
not code, just a text template, having an instance variable is
appropriate. :)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Christian Edward Gruber
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
