Actually, one of the justifications for this is *easier* unit testing. Currently, to test some of the behavior of a class ... say rendering its body or informal parameters, requires a lot of machinations to, in effect, test code inside AbstractComponent. Even with EasyMock that's a lot of work.
With this new design, rending of informal parameters will be a method invocation on the ComponentResources object injected into the "peer" class. Much easier! On 12/20/05, Kevin Menard <[EMAIL PROTECTED]> wrote: > While I like the technical justification for all this, I do wonder about how > much it'll increase complexity. T3 had a bit of a steep learning curve, T4 > seems to have only amplified the problem by throwing HiveMind into the mix. > I certainly enjoy the flexibility we have now and the ability to test things > far easier. On the other hand, I have a lot more configuration going on > that really can't be checked until runtime and a lot more interfaces kicking > around. My project sizes have definitely grown considerably in breadth, > which can be a bit overwhelming at times. > > So, I like the general idea of where you want to take Tapestry. I just want > to make sure that a) the bar of entry isn't set ridiculously high and b) > that in the pursuit of flexibility and using POJOs for everything that new > problems are being introduced. > > -- > Kevin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
