click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
Subject Re: Apache Click 3
Date Tue, 27 Jul 2010 11:27:43 GMT
With regard to targeting Servlet 3, I don't think it is supported by
enough application servers.

Personally I have to work with the JBoss 4.x series and the Oracle
WebLogic series of servers and they only support the Servlet 2.5 API.

regards Malcolm Edgar

On Tue, Jul 27, 2010 at 5:19 PM, Md. Jahid Shohel
<development.jsh@gmail.com> wrote:
>> The target of Click 3 is Servlet 3.0?
> I think so.
>
>>It would make possible to introduce Click into web applications plugable.
> Yeah pluggability is another issue, that was not possible to bring in on
> current click implementation. While I was implementing the annotation
> support for click on my google code, and later on while I was thinking to
> write extension of click to add modularity support, it appeared that its
> easy to write a new config service instead of extending the existing
> one(which is in the end will bring in lots of maintenance issues). I hope
> there will be some good scope to bring in modularity. Or at least there
> should be scope for people extend the click implementation to add such
> functionalities as their extension projects. And by modularity/plugability I
> mean dropable jars, but not package level code separation.
>
>
> On Mon, Jul 26, 2010 at 8:40 PM, Naoki Takezoe <takezoe@gmail.com> wrote:
>>
>> 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