Hi all,

I haven't yet posted to this list, although I have been lurking for quite
some time now and managed to turn a certain Dirk O. and Christian N. into
Tapestry fans - not to mention a customer. :-)
I'm also an old WO user, just like a seemingly increasing number of people
who feel the need to come out of their WOCloset here..but on with the
show:

>
> (lots about automagic binding)
>
> For debate:  should step #3 apply to scalar properties
> (boolean, int, double, etc.) or just to object
> properties?

If possible, yes please. scalar values are just so nice to have instead of
the wrapper types, and AFAICS everything is already in place, so why not?

> For debate:  Tapestry can now automate the process of
> checking for required parameters ... that is, it can
> enforce that a binding exists and that the binding's
> value is non-null ... or should this check stay in
> component code?

IMHO whether a parameter is required or optional should be attribute of
the components' API. The component designer should be able to specify
which parameters are mandatory and/or optional. Makes it easier for a tool
to check a component for consistency, too.

> There will be a small loss in efficiency.  Tapestry

Ignore it (at first, at least).
And this from someone who lives for performance! :-)

> The plus side is that the codebase will shrink a bit.

Significantly! Isn't that the most important aspect? Like you said,
futzing with bindings is counterintuitive and also..tiresome. More code ==
more bugs. Code is evil.

> It should be pretty obvious that the new code is far
> more desirable.  Note that none of the gobbledygook
> about static bindings is needed anymore ... if its
> static, it is set once and not changed.  If it is
> dynamic, it is set before renderComponent() and cleared
> after.

Yes. It would also make it easier for Spindle to update Java Source and
bindings in sync, just like a certain commercial program that shall remain
unnamed here.
 
> I'm really warming up to this change.  Given that
> Tapestry is a component-based framework, it makes sense
> that making components easier to construct is a win on
> both the coding and marketing side of things.

Yes, although Tapestry already is a very convincing 'sell' once you start
showing some JSP lump. :)

> So ... the final question is: when?  2.0.2, 2.0.3 ... or
> should this wait for the 2.1 series?

IMHO keep 2.0 stable, new bindings for a 2.1 branch. Break everything!

Holger
-- 
Holger Hoffst�tte
Daedalos Consulting GmbH
Ruhrtal 5, 58456 Witten, Germany
http://www.daedalos.com/

_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer

Reply via email to