woops:)
Jesse Kuhnert wrote:
> No...I meant re-use knowledge of the new annotations - such that you
> can apply them in more than one place...Not necessarily t4 knowledge.
>
> On 12/13/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> Jesse Kuhnert wrote:
>> > 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.
>>
>> As I see it, the whole framework is new, templates syntax is new,
>> component classes are new, @Inject annotation is new, but the binding
>> attribute must stay as it was? to reuse the knowledge? the whole
rewrite
>> of T5 is under the flag of "do it right this time, forget about older
>> versions" - so be it, if its better this way (as I believe), then take
>> it...
>>
>> Cheers,
>> Ron
>>
>>
>> >
>> > 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]
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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]
