Hi Howard,
many thanks for explaining the trade-offs thorougly. From user-point of
view it just feels a bit unnatural, that one needs to add a property in
the page class, which exists as a locally scoped and derived variable in
the template.
After all tapestry5 looks extremely promising. Am digging deeper to code
these days and am hoping to contribute some work in future :)
Howard Lewis Ship schrieb:
First off, just use the @Property annotation. Field + @Property ...
no getters or setters.
Tapestry works in a type-safe manner, using real properties on the Java objects.
This is good: property access is validated during page construction,
not at runtime when a property expression is first evaluated.
Further, property access is converted into a PropertyConduit object; a
new class is created, and you get all the benefits of hotspot
optimizations and no reflection (including, no synchronization
issues).
The var: binding prefix gives a little bit of the behavior you want.
However, it's very hard to introduce a new, type-safe property into an
existing class in the way you suggest: that is, the Loop component
should create a new property on the containing Page class.
This is problematic for a number of lifecycle reasons (the page is
instantiated first, so it's a little late to create a new property by
the time the Loop component is instantiated an initialized). This
could be addressed with considerable effort, and it would introduce
some ambiguities w.r.t. how subclasses of pages operate.
I don't find the need to define a property onerous; in fact, the
separation between template and code is very nice. The property gives
me the ability to know easily (using the debugger, for example) the
state of the things. Its documented, and defines a specific type. It's
easy: a property and an annotation. It's expressive. Lastly, many
times you have an integration between template logic, encoded in the
template markup and use of components, and container logic. Having a
field in the container component is a very natural way to handle that.
I guess we all have a threshold for "code magic". Mine is pretty
high, I like all the magic and meta-programming that Tapestry does,
but sounds like your threshold is a bit higher than mine.
On Mon, Jan 26, 2009 at 1:00 PM, manuel aldana <ald...@gmx.de> wrote:
hi,
the Loop component is used basically used by (define a list t:source and
bind a local iterable var t:value to access the values later):
...
<ol t:type="loop" t:source="listItems" t:value="listItem">
<li>${listItem.name}</li>
</ol>
...
What I find a bit clumsy is that you have to put this local-variable also to
your page class:
Page{
List<Item> listItems;
Item listItem;
...
//getter+setters
}
Why is tapestry not holding/creating the listItem local-var on the fly
itself, instead of forcing to create a duplicated local variable (listItem
is derived from listItems) inside the page class?
--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
