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:24:17 GMT
Here are the clover reports for the two modified classes.  Look for
scanForBindingProperty() in ComponentClassFactory and get/setBinding() in
AbstractComponent.  The changes get 100% coverage through Tapestry's
existing tests.

http://idisk.mac.com/nog/Public/Tapestry/ComponentClassFactory.html
http://idisk.mac.com/nog/Public/Tapestry/AbstractComponent.html

Note - this code is just a hack to test if it works - I'll be putting some
effort into tidying it up before it hits CVS!

R

----- Original Message ----- 
From: "Howard M. Lewis Ship" <hlship@comcast.net>
To: "'Tapestry development'" <tapestry-dev@jakarta.apache.org>
Sent: Wednesday, December 24, 2003 5:57 AM
Subject: RE: To enhance or not?


Here's where I wish we had a bit of corporate backing behind Tapestry.

The correct approach here would be to compare the performance of the two
approaches --- memory usage
and throughput.

Given that tests pass I'm ok either way. I would prefer to verify, using
Clover or other code
coverage tool, that we get high (preferably 100%) coverage of the changed
code. That would, to me,
mitigate the risk.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Richard Lewis-Shell [mailto:rlewisshell@mac.com]
> Sent: Tuesday, December 23, 2003 4:17 AM
> To: tapestry-dev@jakarta.apache.org
> Subject: To enhance or not?
>
>
> 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