tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Lewis-Shell" <rlewissh...@mac.com>
Subject Re: To enhance or not?
Date Tue, 23 Dec 2003 19:35:08 GMT
Custom parameters already get ignored by the property enhancer - it is only
their respective bindings that are currently enhanced.  Tapestry has always
made use of binding properties if they are available, so I would suggest
sticking with this moving forward, even for custom bindings (and changing
that would break a LOT of code I'm sure).  The prototype implementation I
have so far will enhance abstract binding property methods only, but I am
not fussed on this.  Though Tapestry itself actually has some abstract
binding property methods already (eg. Form.get/setStatefulBinding()), so
it's quite conceivable other apps will have these also, so I figure the
safest approach for now is to enhance a binding property if abstract,
otherwise leave alone.

R

----- Original Message ----- 
From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Sent: Wednesday, December 24, 2003 7:45 AM
Subject: Re: To enhance or not?


> I am aboard with your proposal for 3.0. But are we going to continue to
enhance custom parameters if
> not manually implemented or should we just leave custom parameters alone,
always, going forward?
>
> -Harish
>
> Richard Lewis-Shell wrote:
>
> > OK, I've now done a little testing with not enhancing custom parameter
> > binding properties...
> >
> > By changing ComponentClassFactory so it only enhances custom parameters
IF
> > they are genuinely abstract (as opposed to missing which is how the
current
> > code works), and reverting AbstractComponent.get/setBinding() so they no
> > longer assume there will always be binding properties, but instead
checks
> > for such a property first, it works.  Classes do not require enhancing
just
> > because they have a custom parameter, and ALL Tapestry's tests pass (and
so
> > do all our app's tests to boot).
> >
> > To my mind this is a big improvement, especially for large Tapestry
> > applications.  eg. our app has over 550 components, so by making this
> > change, there are around 550 classes that do not require enhancing, thus
> > around 550 less classes requiring loading/tracking, and 550 classes that
are
> > easier to debug.
> >
> > The drawback?  Apart from adding a little extra complexity to the
framework
> > as Harish raises, technically it's a teeny weeny API change (because
some
> > classes no longer have set/getXYZBinding methods) and I think at this
late
> > beta stage we're not supposed to be making those.  However, it is only
the
> > property for the binding itself, not the actual parameter value, so I
think
> > it unlikely to have a significant effect.  And did I mention
teeny/weeny?
> > :-)
> >
> > As always, let me know your thoughts...
> >
> > R
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message