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
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
