+1 To move fancy components from tapx or other in core. This is what is missing to make it more popular. Why not adding a new module : core still stand as the main module for web development and 'tapestry-ui' for web components as well ?
2011/2/9 Igor Drobiazko <[email protected]> > 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 > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
