tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: To enhance or not?
Date Tue, 23 Dec 2003 16:57:47 GMT
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


Mime
View raw message