I agree that somehow the bindings= syntax doesn't feel totally natural
in annotation mode, but I think it's also possible to have too many
choices wrt annotations. We should probably be highly critical of each
new addition going into the fold as it will only eat away at peoples
ability to learn the framework.
Finding more ways to re-use the same knowledge/annotation in different
ways seems like a win/win situation.
On 12/13/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
Sure ist a mutter of conventions and taste-
My taste is favouring the detailed one @Binding(name=...), somehow I
find it more apealing and easier to maintain - I like double klicking
the string and changing it instead of drugging the mouse over -
and - it is, for my taste, more aligned with conventions and more self
documenting, which I find important.
bindings="value=ognl:value" always seemed to me more like a hack, a
direct transform of template-html to an annotation than a definition in
the java-language.
I am also curious what others think...
Cheers,
Ron
Howard Lewis Ship wrote:
> This is open for debate, of course. I consider the approach I've taken
> with
> this annotation to be a kind of developer-time optimization, and I don't
> think it's premature. I think your suggestion is quite valid, but I
> think it
> is overkill, in the way that may XML applications use overly deep nested
> elements (often, where simple XML attributes could be used instead, to
> complete the rough analogy). Does that make sense?
>
> Basically, my constant thought in T5 is to focus on the application
> developer, not the tool builder. In many cases, I've deliberately made
> things hard for myself, to make things as easy as I know how for the
> application developer. In other cases, such as this one, I've taken
> shortcuts -- pragamatism over dogmatism. I want those application
> developers
> to type as little as possible, to struggle with the editor as little as
> possible.
>
> Using nested @Binding annotations has a couple of minor advantages in terms
> of code completion and compile time validty. Someone how types
> @Component(bindings="foo") will have to wait until runtime to see the
> error. So be it.
>
> On 12/12/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
>>
>> Hi -
>> wanted to ask about the component bindings.
>> Currently I know the bindigns annotation attribute is
>>
>> String[] bindings.
>>
>> in the format of "name=value"
>>
>> Though requiring more typing, which I know *some* of you really dislike,
>> it is common to split such "complex" values to sub-annotations:
>>
>> bindings={ @Binding( name="listener", value="listener:doSomething" ) }
>>
>> or even
>>
>> bindings={
>> @Binding( name="listener", type="listener", value="doSomething" )
>> }
>>
>> this will be, as far as i can see, easier to maintain and ofcouase to
>> parse.
>>
>> what do you think?
>>
>> just my 3 cent...
>>
>> Cheers,
>> Ron
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
