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]
--
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]
