I'm all for Howard's "consistency" goal, but I'm also 100% in favor of Ron's
"compile errors over runtime errors" goal (if that was his goal?). Balancing
these two concerns will probably be very hard :-)
Two side notes that come to mind:
- Jesse mentioned something about "too many options wrt annotations." I'm a
big fan reducing options everywhere so that the framework is easier to learn
and remember... Put the onus on the framework developer to do the superhuman
in order to find the one way of doing things that is easiest to use but also
flexible, extensible, etc.
- I believe Java SE 6 introduces a new compile-time annotation processing
framework... Seems to me that in some not-too-distant future, this framework
could be used to validate a lot of the metadata that nowadays can only be
checked at runtime (ie convert more runtime errors into compile-time
errors).
On 12/13/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
yes, it follows the template syntax - for me, in java, this syntax feels
strange.
If you look at the Java persistance API annoations vs. xml its all full
of such "subannotations". I would favour aligning to it, instead of
using an "own" syntax, also if its 1:1 with the template syntax -
I Guess its a "feeling" for what one finds better - would really
interest me what others think about it...
Cheers,
Ron
Howard Lewis Ship wrote:
> It is a question of what you are consistent with.
>
> Template:
>
> <t:comp type="Zip" foo="bar"/>
>
> is (I feel) consistent with:
>
> @Component(bindings="foo=bar")
> private Zip _zip;
>
>
> But less consistent with:
>
> @Component (bindings = @Binding(name="foo", value="bar"))
>
>
> I really think there's some value in aligning these as clearly as
possible,
> but anything may change.
>
> My experience training people in Tapestry is driving a lot of these
little
> decisions. I can clearly remember the kind of blank stares I've gotten
when
> I introduce abstract classes and so forth. I'll probably be putting
myself
> out of business with T5 :-) (actually, I'll be able to cover much more
> material and get into true database/spring/hibernate integration).
>
>
> seems
>
> On 12/13/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
>>
>> 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]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
