click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <sab...@gmail.com>
Subject Re: Apache Click 3
Date Mon, 26 Jul 2010 08:08:02 GMT
Hi Malcolm,

Comments inline.

On 25/07/2010 23:28, Malcolm Edgar wrote:
> 
> I want to start a discussion about a potential Apache Click 3
> development branch.


If we are talking about changes to the architecture then I agree it should be developed in
a
separate branch.


> The objective of a version 3 would be to:
>  * provide a more explicit and consistent programming model


Agreed. Over the years I've done more and more maintenance work, as opposed to pure "developing
apps
from scratch". One thing I've come to appreciate is that explicit programming really helps
with
maintenance and is only a slight nuisance to the initial developer.

Do have something particularly in mind? Except for stateful pages and autobinding, Click core
is
quite explicit. Click-extras, especially the CayenneForm and HibernateForm, has some implicit
behavior which needs work. I'm not even sure these controls are that useful as most Java apps
uses a
Service/Dao layer anyway.


>  * target HTML 5 support

I assume you mean new input attributes? They can already be used through setAttribute/getAttribute,
unless you have something else in mind.

>  * introduce new rendering pipeline, to significantly improve
> performance and enable pluggable component renderers


Finn did some tests on this which looked quite good. It seemed to be targeted at Velocity
only though.


>  * remove troublesome parts of the framework, and simplify the architecture


+1. Over the years we've deprecated a number of API's but never removed them. This would be
an ideal
time to remove them.


> With a change of this nature I don't think we can expect to maintain
> 100% backward compatibility with Apache Click 2.x. Breaking backward
> compatibility is a big deal as you potentially alienate many users and
> organisations. So any change breaking backward compatibility needs
> have a significant benefit to justify its inclusion. To assist with
> migrating applications from 2 to 3, it would be good to provide some a
> Ant task to perform refactoring as a head start.
> 
> Please note the effort in migrating a v2 to v3 application should not
> be significant. I do not want to see a Tapestry like scenario, where
> people are isolated on older branches.


Agreed. As long as there is an upgrade path it shouldn't be too much of a deal.

Kind regards

Bob

Mime
View raw message