click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naoki Takezoe <take...@gmail.com>
Subject Re: Apache Click 3
Date Mon, 26 Jul 2010 18:40:14 GMT
Hi Malcolm and Bob,

The target of Click 3 is Servlet 3.0?

It would make possible to introduce Click into web applications plugable.
And also it would make possible to provide file uploading without
Commons FileUpload.

I think that Click 3 might be a just time to shift to Servlet 3.0.

2010/7/26 Bob Schellink <sabob1@gmail.com>:
> 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
>



-- 
Naoki Takezoe

Mime
View raw message