> what i am missing is a decent (official) portlet support in T5. Someone who is working on, or has an interest in portlets should step up and do it, or maybe just prototype it or layout what the issues are that need to be addressed to make it easier to implement. Open Source is about itches, and if it doesn't itch it doesn't get scratched... unless you're bored I guess. ;)
> 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 Sure, the javascript layer needs to be abstracted. This is not "the" reason there are limited fancy JS controls. More likely it's that the people submitting code to share are less concerned with making generic fancy controls. There is at least one open source project for using jquery with tapestry https://github.com/got5/tapestry5-jquery. > 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. This has nothing to do with end user functionality and everything to do with framework builders flexibility. Maven is great for some projects, but falls down with complex multi-module builds. You, as an end-user will see no difference. You still grab stuff from the maven repositories, tapestry developers can still build maven archetypes, etc. I found this article interesting http://community.jboss.org/wiki/Gradlewhy > 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! Ah, so you aren't actually familiar with gradle, which by default uses the same project layout as maven, pulls dependancies from maven repositories (as well as other types of repos that your org might have), and publishes to maven repositories. It took minutes to convert a simple tapestry application from maven to gradle. But of course that doesn't matter because if Tapestry is built using maven then you would never know unless you wanted to build Tapestry! Josh On Wed, Feb 9, 2011 at 4: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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
