You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Malcolm Edgar <ma...@gmail.com> on 2009/03/27 12:14:15 UTC
Click Feature Concepts and Roadmap
Hi All,
I have added some content to the WIKI, outlining feature concepts for
potential inclusion in the Click Roadmap. This builds on content Bob
has already provided. Please see below:
http://cwiki.apache.org/confluence/display/CLICK/Feature+Concepts+and+Roadmap
regards Malcolm Edgar
Re: Click Feature Concepts and Roadmap
Posted by jschmidt <jo...@yahoo.com>.
On the datepicker: The wicket people seems to use a datepicker from
the yui project, have you considered that option already?
http://developer.yahoo.com/yui/calendar/
Instead of the big and bloated Yahoo solution, better a nice and small jQuery one.
There are several jQuery based date pickers:
http://www.ajaxline.com/10-best-jquery-datepickers-plugins
for more possible usage scenarios.
Also, I'm not sure that it's a good idea just to copy Wicket (from the roadmap I can see that
Click is as old too - or maybe even older).
Thanks,
Joseph.
--
View this message in context: http://n2.nabble.com/Click-Feature-Concepts-and-Roadmap-tp2543751p2546634.html
Sent from the click-user mailing list archive at Nabble.com.
Re: Click Feature Concepts and Roadmap
Posted by Bob Schellink <sa...@gmail.com>.
Hi Fredrik,
Fredrik Jonson wrote:
>
> I have a few quick comments on the F&R ideas. Hope it's okay to post
> on the devel list even though I'm just a mere click user.
Yep, sure is.
> On the datepicker: The wicket people seems to use a datepicker from
> the yui project, have you considered that option already?
> http://developer.yahoo.com/yui/calendar/
Nods I did look at the YUI version. My primary reason for not using it
was that YUI calendar is quite large, 250KB compressed, while
JSCalendar is 40KB. For an intranet app this won't matter much but on
the web it could be a factor.
As you probably know the JSCalendar is still alive and well but as a
separate project: http://code.google.com/p/click-calendar/
We could add the JSCalendar project as a dependency to the build
script and have it downloaded. We do the same for Hibernate which is
LGPL as well. I think Will raised the issue that we just need to
provide an option to easily switch off LGPL dependencies. The
project.properties has such an option :)
> On Java 5: I like the annotation proposal. It can become more strong
> typed by using a enum BindableType { Control, Model, Request }
> and declare:
>
> @Bindable(BindableType.Control)
> private Form form = new Form();
+1 strong typing is good idea.
kind regards
bob
Re: Click Feature Concepts and Roadmap
Posted by Fredrik Jonson <fr...@myrealbox.com>.
Hello,
I have a few quick comments on the F&R ideas. Hope it's okay to post
on the devel list even though I'm just a mere click user.
On the datepicker: The wicket people seems to use a datepicker from
the yui project, have you considered that option already?
http://developer.yahoo.com/yui/calendar/
On spring and acegi: For me one of the parameters when selecting
click over the numerous other web frameworks out there was that click
was really useful without having to resort to spring. Also acegi has
been renamed "spring security" nowdays.
On Java 5: I like the annotation proposal. It can become more strong
typed by using a enum BindableType { Control, Model, Request }
and declare:
@Bindable(BindableType.Control)
private Form form = new Form();
--
Fredrik Jonson
Re: Click Feature Concepts and Roadmap
Posted by a_adrian <a....@googlemail.com>.
(sorry for the repost, but nabble is eating quotations lately :( )
> The jQuery controls look very nice. Also quite heavy, though, but if
> you used jQuery extensively in application this overhead would not be
> too bad. I think a site should avoid having heavy controls on the
> front page, to minimise the initial load.
I think there should be a distinction between jQuery and jQueryUI.
Only the latest one is heavy (production jQuery is only 19kb - see jquery.com)
It's also much easier to learn and use than Prototype.
Also several JS/CSS resources are available on google/public servers (with correct version),
so sites using form there, can ease their own traffic, and are also highly cached .
Maybe the performance filter could have this option too: to include conditionally from public urls the correct version.
Regarding Date/Time, there are several other jQuery plug-ins for this (on that list), so it's not necessarily to use the most heavy one jqueryUI Date picker.
Another option would be to use for the default Click Date control a "select" based approach (like the one in Rails) - it is quite efficient too - I think it's much much better than a simple text field.
For pure time entry there are several other interesting time entry plug-ins too:
http://keith-wood.name/timeEntry.html (the same author has a date entry and a date picker plug-in too)
http://www.jnathanson.com/index.cfm?page=jquery/clockpick/ClockPick (innovative way of selecting time)
IMO all jQuery (& plug-ins) based Click controls should be put into a separate package (since many of them may overlap with Prototype based, and usually users don't want both in their application - the same way one is not using Cayenne and Hibernate in the same application).
Thanks,
A.
--
View this message in context: http://n2.nabble.com/Click-Feature-Concepts-and-Roadmap-tp2543751p2548725.html
Sent from the click-user mailing list archive at Nabble.com.
Re: Click Feature Concepts and Roadmap
Posted by a_adrian <a....@googlemail.com>.
The jQuery controls look very nice. Also quite heavy, though, but if
you used jQuery extensively in application this overhead would not be
too bad. I think a site should avoid having heavy controls on the
front page, to minimise the initial load.
I think there should be a distinction between jQuery and jQueryUI.
Only the latest one is heavy (production jQuery is only 19kb - see jquery.com)
It's also much easier to learn and use than Prototype.
Also several JS/CSS resources are available on google/public servers (with correct version),
so sites using form there, can ease their own traffic, and are also highly cached .
Maybe the performance filter could have this option too: to include conditionally from public urls the correct version.
Regarding Date/Time, there are several other jQuery plug-ins for this (on that list), so it's not necessarily to use the most heavy one jqueryUI Date picker.
Another option would be to use for the default Click Date control a "select" based approach (like the one in Rails) - it is quite efficient too - I think it's much much better than a simple text field.
For pure time entry there are several other interesting time entry plug-ins too:
http://keith-wood.name/timeEntry.html (the same author has a date entry and a date picker plug-in too)
http://www.jnathanson.com/index.cfm?page=jquery/clockpick/ClockPick (innovative way of selecting time)
IMO all jQuery (& plug-ins) based Click controls should be put into a separate package (since many of them may overlap with Prototype based, and usually users don't want both in their application - the same way one is not using Cayenne and Hibernate in the same application).
Thanks,
A.
--
View this message in context: http://n2.nabble.com/Click-Feature-Concepts-and-Roadmap-tp2543751p2548720.html
Sent from the click-user mailing list archive at Nabble.com.
Re: Click Feature Concepts and Roadmap
Posted by Malcolm Edgar <ma...@gmail.com>.
The jQuery controls look very nice. Also quite heavy, though, but if
you used jQuery extensively in application this overhead would not be
too bad. I think a site should avoid having heavy controls on the
front page, to minimise the initial load.
The annotations enum looks nice.
regards Malcolm Edgar
On Sat, Mar 28, 2009 at 10:06 AM, Bob Schellink <sa...@gmail.com> wrote:
> a_adrian wrote:
>>
>> What about the "popular issues" from the JIRA?
>> None of them seems to be on the roadmap :(.
>
>
> Sure all JIRA's are up for grabs. The roadmap on the wiki is simply for
> ideas and designs which are more complex and provides a way to collaborate
> easily.
>
> bob
>
Re: Click Feature Concepts and Roadmap
Posted by Malcolm Edgar <ma...@gmail.com>.
The jQuery controls look very nice. Also quite heavy, though, but if
you used jQuery extensively in application this overhead would not be
too bad. I think a site should avoid having heavy controls on the
front page, to minimise the initial load.
The annotations enum looks nice.
regards Malcolm Edgar
On Sat, Mar 28, 2009 at 10:06 AM, Bob Schellink <sa...@gmail.com> wrote:
> a_adrian wrote:
>>
>> What about the "popular issues" from the JIRA?
>> None of them seems to be on the roadmap :(.
>
>
> Sure all JIRA's are up for grabs. The roadmap on the wiki is simply for
> ideas and designs which are more complex and provides a way to collaborate
> easily.
>
> bob
>
Re: Click Feature Concepts and Roadmap
Posted by Bob Schellink <sa...@gmail.com>.
a_adrian wrote:
>
> What about the "popular issues" from the JIRA?
> None of them seems to be on the roadmap :(.
Sure all JIRA's are up for grabs. The roadmap on the wiki is simply
for ideas and designs which are more complex and provides a way to
collaborate easily.
bob
Re: Click Feature Concepts and Roadmap
Posted by a_adrian <a....@googlemail.com>.
I have added some content to the WIKI, outlining feature concepts for
potential inclusion in the Click Roadmap. This builds on content Bob
has already provided. Please see below:
http://cwiki.apache.org/confluence/display/CLICK/Feature+Concepts+and+Roadmap
What about the "popular issues" from the JIRA?
None of them seems to be on the roadmap :(.
Thank you,
A.
--
View this message in context: http://n2.nabble.com/Click-Feature-Concepts-and-Roadmap-tp2543751p2543774.html
Sent from the click-user mailing list archive at Nabble.com.