On 1/7/08 3:23 PM, in article [EMAIL PROTECTED], "Davor Hrg" <[EMAIL PROTECTED]> wrote:
> var: is for simple usages only, > var: is not a prefix like prop: it will not generate an expression > > extracting type from combined binding is i a tedious job and probably > not even possible do be done right: Unless I'm mistaken, OGNL did an okay job with it in T4. > > <div t:type="loop" source="recentPosts" value="var:post"> > > tapestry would have to know somehow about the connection between > recentPosts and var:post > > loop is just a component... how is T5 supposed to know that elements from > recentPosts are to be stored into var:post.... Runtime reflection is doable on an Object reference. Much slower, granted, and certainly not what var or prop is designed to handle. I see the current var work as a stepping stone for more complicated work down the line. > use page properties, this way tapestry can compile expressions in advance... > > private Post post; > > ..getPost() > > ..setPost() > > > if you don't want getters and setters "cluttering" your code , someone > on the list > has a solution that can add them on the fly via annotation.... The issue isn't so much one of clutter as it is one of static analysis. If the only reason the property exists is as a temporary holder for a component, why bother adding it to the page class? The code will never be called from within the page or anywhere other than within Tapestry. How do you adequately deal with code rot in such an environment? The annotation, which does cut out the getter/setter portion, still requires the addition of an unused property to the class. What I do like about the annotation, however, is that it does imbue semantic meaning, so at least I know where to look for usages when cleaning up code. -- Kevin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
