On Wed, Feb 9, 2011 at 12:31 PM, Kalle Korhonen <[email protected]> wrote: > 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. >
And that's always been my desire, to build and infrastructure that can be everything to everyone, with room for lots of people to work on what specifically interests them. > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
