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:14:50 GMT
>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