tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: A plan for 5.3 / 5.4
Date Wed, 09 Feb 2011 17:52:37 GMT
Seems like there's a lot of discussion as if I'm the only one writing code!

I'm working from the feedback from my main clients and they generally
want, desperately, JavaScript minification and stylesheet aggregation.
They also want improved startup times and reduced reload times, which
falls into the domain of Javassist -> ASM/Plastic (not to mention
improved stability and lowered memory utilization).

Anyway, I like doing the deep internals.

I'd be very happy to see work on improved components. I think a lot of
the built-in components could use a refresh.  The JS changes could
span a couple of releases, perhaps prototyping the new JS APIs.


On Wed, Feb 9, 2011 at 9:10 AM, Christophe Cordenier
<christophe.cordenier@gmail.com> wrote:
> +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
>



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


Mime
View raw message