On Wed, Feb 9, 2011 at 6:18 AM, Alex Kotchnev <[email protected]> wrote: > One area that I miss from the Grails world (that Play also seems to adopt) > is moving the "convention-over-configuration" from deep down in the code
Thanks Alex for the insight regarding Grails. > Testing T5 apps is still a sore spot. Sure, you can use EasyMock to mock out > a bunch of stuff and unit test components but you end up having to learn > about much more than you signed up for - having to mock out some T5 services > is not fun at all. Having better and more explicit support for various unit I've marketed Tynamo's approach on integration testing before, but once again, see http://docs.codehaus.org/display/TYNAMO/2010/07/30/Full+web+integration+testing+in+a+single+JVM for full functional testing in a single JVM. Mocking approaches only go so far and Selenium is much too slow and error prone to my taste for general functional testing. > liquibase or yaml), standard security package etc, etc. Sure, I could I'm not sure a standard security package is a good idea. If Tapestry provided its own, people would still be asking for integration with Shiro or Acegi or their favorite security package X. At the same, it's not necessarily a good marketing strategy that Tapestry would embrace a particular security framework (and you have to appreciate what exists in these frameworks, I wouldn't want to duplicate all that effort). It's much simpler for Tapestry to support the use of one of these security packages, such as Tynamo's tapestry-security, as an officially approved third-party security integration, *without* bringing it as part of the core. Then again, we do have official Hibernate integration so why not a particular security library as well? Shiro is an Apache project and me being a committer in all of the three projects, it doesn't require a huge stretch of imagination that tapestry-security would become an official Tapestry module. But I'll say this: Shiro may be well documented and tapestry-security well integration tested, but Tapestry's code sets the bar way, way higher still. > I appreciate Howard's drive to make the underpinnings of the framework yet > better , cleaner, and more powerful (e.g. the plastic work) ; however, at > least from the perspective of a "regular" user they don't have much > immediate value. It seems to me that the framework periphery (as discussed ... > authors have no choice but do depend on, resulting into upgrade issues (e.g. > many people depend on third party modules like tynamo , testify > or chenillekit ). Maybe a little slowdown in core framework advances would > be nice for module authors as well. As the founder of Tynamo, I say you don't have to worry about compatibility issues with Tynamo's offerings. There's always some work to do to update the libs if the internals change, but T5's adaptable api and external/internal interfaces have well proven its merits in my eyes - the effort has been minimal so far and I've been impressed with Tapestry's (internal) backwards compatibility. I think Josh put it well, you have to scratch the itch you have, and Howard has a major one to continue improving the internals. It's up to the rest of of us to add the layering on top. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
