tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Drobiazko <igor.drobia...@gmail.com>
Subject Re: A plan for 5.3 / 5.4
Date Wed, 09 Feb 2011 17:03:34 GMT
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 <akochnev@gmail.com> 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 <
> kristian.marinkovic@porscheinformatik.at> 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 <hlship@gmail.com>
> > An:     Tapestry development <dev@tapestry.apache.org>
> > 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 <igor.drobiazko@gmail.com
> >
> > 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 <hlship@gmail.com>
> > 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: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
> >
>



-- 
Best regards,

Igor Drobiazko
http://tapestry5.de

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message