Thanks Kristian and Alex. Great comments. I second your opinions: we need more stuff which is attractive for new user. We need yet another one killer feature, such as live class reloading, to be more attractive for new users. I believe that the order features on Howard's list need to be changed. A rewrite of the JS layer needs to be done in 5.3.
I also would like to see a lot of stuff in tapx moving to Tapestry's core. Why actually not? I like the idea of slowing down the development in core for a release and concentrating on fancy stuff like new components, dynamic CSS, etc. On Wed, Feb 9, 2011 at 3:18 PM, Alex Kotchnev <[email protected]> wrote: > I second Kristian's opinion - it seems that Howard's roadmap includes > little > to no user facing features. In many respects it seems that there are a > bunch > of user-facing rough spots like the Javascript framework, JPA, HTML5, > portlets that generate questions on the mailing list almost daily. I'm not > sure how many new users are sold on getting stared w/ the framework because > "it has yet more powerful metaprogramming features". > > 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 > into more visible parts of the system (e.g. into the filesystem). For > example, if you want to tweak the datasource configs, you just edit > "conf/DataSource.groovy", if you want to tweak the spring config, you tweak > "conf/resources.groovy" (or conf/resources.xml). If you want to add things > to the startup of the app, you tweak "Bootstrap.groovy". Much of that > simplicity is lost in T5 when I have to edit the already pretty long > AppModule.java in my app when I have to "contribute" into yet another > configuration point and implement yet another T5 interface. T5 already does > some of this w/ the special "components" and "pages" packages (and the > "entity" package w/ Hibernate support) > > Another area that I also find massively useful in Grails is the built in > configurability. You get three environments (dev,test,prod in > Config.groovy) > out of the box (and you can easily add more if needed) and in each > environment you can declare and override configuration points at will. > Sure, > I've done something similar and very basic w/ Maven profiles, but it feels > like a bolt-on instead of being a nicely integrated part of the framework. > > 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 > testing tasks (e.g. once again, Grails has some excellent mocking utilities > that allow you to mock out various parts of the framework in unit tests > that > are commonly needed - be it domain objects, controllers, services). > Testify > is an excellent addition but it's not a part of the framework and as such > can lag behind official T5 releases. > > The items above are just the core-framework related things. From a > ecosystem/extension perspective the list goes on and on - support for > schema > generation for hibernate, a generic data migration facility (e.g. based on > liquibase or yaml), standard security package etc, etc. Sure, I could > accomplish all of these on my own but the fact that the framework doesn't > cater to these common needs certainly doesn't help w/ picking it in the > first place. On one hand, I understand that T5 isn't a 'full stack' > solution > ("it's just a web framework for god's sake" - i hear something screaming in > my head) but when it tries to compete against others (such as Grails or > Play) it kinda has to be to stay competitive. > > On the Gradle switchover - as far as I understand, I guess it doesn't have > to affect users of the framework , as long as the artifacts still continue > being exported into maven repositories (e.g. which I think Gradle does > well). A user of the framework can still continue using a maven archetype > to > get started w/ Tapestry, it seems like there would be just one more way to > do so (w/ the equivalent of a Gradle project archetype). At the same time, > I > don't see too many benefits of the switchover (but then I'm not a core > developer either, so my opinion doesn't hold much water) beyond having to > use a different tool for the build and having yet another build tool to > learn. > > 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 > above) would be more valuable from a user's point of view. The core itself > has already been moving quite quickly (e.g. from 5.0->5.1->5.2 a whole > bunch > of changes to the guts). Although these changes don't affect the clearly > delineated public APIs, they do affect many of the internals, which module > 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. > > Regards, > > Alex K > > > On Wed, Feb 9, 2011 at 7:34 AM, Kristian Marinkovic < > [email protected]> wrote: > > > i guess your roadmaps (igor, howard) are very promising. > > > > what i am missing is a decent (official) portlet support in T5. This was > > the main reason some of my customers refused to switch to T5 and chose > JSF > > instead (with Liferay). They were all quite impressed by T5 features but > > they didn't want to spend their effort in maintaining a custom portlet > > solution. Those costumers are big companies that already have some kind > of > > portlet support and want to reuse their infrastructure. Almost everytime > > we were presenting T5 and its advantages to some managers, someone had to > > ask: does it support portlets (event if they don't use it!). from my > > experience this is a big selling point. > > > > a new JS infrastructure / abstraction layer is overdue as this is the > > reason why there are no (at least not many) fancy JS enabled controls and > > widgets for T5. because everytime you think of creating one, you remember > > that T5 depends on prototype and you dont want to use it anymore. but > > writing T5 components that depend on JQuery, dojo, ... doesn't feel right > > too. i think it would be a big advantage if you could write js library > > agnostic components (with some additional adapters if necessary) and > adapt > > to your customers needs. > > > > i'm still not convinced moving from gradle to maven is a good idea. for > me > > maven works great and almost any it-company nowadays is familiar with it. > > we are building a custom OSGIfied version of T5.2 using maven. i don't > > know how to achieve the same result with gradle. Also from my point of > > view having a default project layout for all java projects (especially > > open source) is a good (not to say great) idea! > > > > g, > > kris > > > > > > > > Von: Howard Lewis Ship <[email protected]> > > An: Tapestry development <[email protected]> > > Datum: 08.02.2011 22:34 > > Betreff: Re: A plan for 5.3 / 5.4 > > > > > > > > Javassist vs. Plastic vs. ComponentClassTransformWorker > > > > Imagine if you could contribute a "classic" > > ComponentClassTransformWorker or some new interface for working with a > > Plastic class, both to the same service: > > ComponentClassTransformWorker. The "classic" style would be > > transformed, via TypeCoercer, to the new form. And, of course, we'd > > make that work for all service configurations. That's my plan, > > anyway. Configurations should, instead of complaining that provided > > types are bad, attempt to coerce first. > > > > I think the new interface will look more like: > > > > public interface ComponentClassTransformer > > { > > void transformClass(PlasticClass componentClass, MutableComponentModel > > model); > > } > > > > > > On Tue, Feb 8, 2011 at 1:25 PM, Igor Drobiazko <[email protected] > > > > wrote: > > > Having an official road map would be a great improvement for Tapestry. > > Also > > > having two releases in 2011 is great. > > > > > > My plans for 5.3/5.4 are: > > > > > > - Support for JSR-330 (almost done) > > > - Support for some HTML5 features > > > - Support for "multidimensional" caching of pages, components, etc. > > > - Helping you out by migrating from javassist to plastic (I already > > started > > > learning ASM + Plastic) > > > - Maybe some support for other frameworks: Event though we having JPA > > > support in Tynomo, I'm thinking to move it into Tapestry? Such a widely > > used > > > framework should be supported. > > > > > > Along the way I'm working on the book which hopefully will be released > > > before summer. > > > > > > What do you think about moving some stuff from tapx to Tapestry core? > > > > > > On Tue, Feb 8, 2011 at 7:13 PM, Howard Lewis Ship <[email protected]> > > wrote: > > > > > >> Been chatting with clients (who may help fund this) and just thinking > > >> about plans. Here's a rough outline of what I think I can commit to > > >> in 5.3 and 5.4. > > >> > > >> 5.3 > > >> - Deprecate Javassist inside ComponentClassInstantiator, replace with > > >> Plastic > > >> - Deprecate ClassFactory, provide necessary hooks to use Plastic > > >> - Move Plastic into Tapestry? > > >> - Gradle build for Tapestry > > >> - Improve debugging experience (shadow per-thread values into shared > > >> object fields in development mode) > > >> - Improve asset pipelines for > > >> - Dynamic generation of content (example, .less files converted to > > >> static CSS automatically) > > >> - JS/CSS minimization > > >> - Do something about Component Report ... turn it into an Ant task, > > >> perhaps, or integrate Component Report into JavaDoc directly > > >> - Minor JS improvements, set expectations for 5.4 rewrite > > >> > > >> 5.4 > > >> - Remove Javassist entirely > > >> - Remove ClassFactory > > >> - Rewrite JS entirely, introduce abstraction layer and backwards > > >> compatibility layer > > >> - Maybe cometd/server-push support > > >> > > >> I'd love to see both these releases in 2011. > > >> > > >> In case you missed in: http://github.com/hlship/plastic > > >> > > >> -- > > >> 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] > > >> > > >> > > > > > > > > > -- > > > Best regards, > > > > > > Igor Drobiazko > > > http://tapestry5.de > > > > > > > > > > > -- > > 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] > > > > > > > -- Best regards, Igor Drobiazko http://tapestry5.de
