tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Cordenier <christophe.corden...@gmail.com>
Subject Re: A plan for 5.3 / 5.4
Date Wed, 09 Feb 2011 17:10:11 GMT
+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 <igor.drobiazko@gmail.com>

> 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
>



-- 
Regards,
Christophe Cordenier.

Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com

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