click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel" <development....@gmail.com>
Subject Re: Apache Click 3
Date Tue, 27 Jul 2010 20:17:18 GMT
About JBoss

http://www.h-online.com/open/news/item/JBoss-6-M2-supports-Servlet-3-and-JPA-2-933807.html

On Tue, Jul 27, 2010 at 10:14 PM, Md. Jahid Shohel <
development.jsh@gmail.com> wrote:

> >With regard to targeting Servlet 3, I don't think it is supported by
> >enough application servers.
>
> GlassFish already supports Servlet 3, and the new release of Tomcat 7,
> which was released 2 weeks back, which supports Servlet 3.
>
>
>
> On Tue, Jul 27, 2010 at 1:27 PM, Malcolm Edgar <malcolm.edgar@gmail.com>wrote:
>
>> 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