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 <[email protected]>: > 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
