Description

This would allow a nice separation and easy integration of other javascript frameworks too.
It would be also much easier for the users, since there also might be duplicate components made with other javascript frameworks too.

Activity

May I refactor the Prototype based components to an new package: "org.apache.click.extras.prototype.*"?
The following components would be moved:

Checklist

Colopicker

DateField

PickList
The above, all depend on prototype, so it would be very important to have them isolated into a separate package.
In "org.apache.click.extras.control", would remain only "standalone components".
Than we could add later another package, e.g. "org.apache.click.extras.jquery.*" for the jQuery based components,
so it would be no confusion if several components would do the same thing but with a different javascript framework.

Adrian A.
added a comment - 03/Mar/10 19:46 May I refactor the Prototype based components to an new package: "org.apache.click.extras.prototype.*"?
The following components would be moved:
Checklist
Colopicker
DateField
PickList
The above, all depend on prototype, so it would be very important to have them isolated into a separate package.
In "org.apache.click.extras.control", would remain only "standalone components".
Than we could add later another package, e.g. "org.apache.click.extras.jquery.*" for the jQuery based components,
so it would be no confusion if several components would do the same thing but with a different javascript framework.
Does anyone have any objections to this approach?

Malcolm Edgar
added a comment - 03/Mar/10 22:44 Personally I like the idea of moving this into a prototype package, but it will cause a compile time break with people upgrading to version 2.2. Which is going to annoy people.
One migration strategy is to copy these controls into the new package, and then make the existing controls deprecated in version 2.2. Then in version 2.3 the deprecated controls can be removed.
I would like to see feed back from others before making this change.

Bob Schellink
added a comment - 04/Mar/10 09:10 While I agree with the refactoring I don't see a reason for pushing this change as this stage. I suggest we hold off this change until there is a good reason to refactor.

> I don't see a reason for pushing this change as this stage.
There are a few reasons IMHO:
1. make place for jQuery components
2. prototype libraries need updates too, so those components will be modified anyway (why not do the migration Malcolm proposed with this way?).
3. reduce confusion and make Click more predictable - I'm always asked about jQuery, and what components don't work with it. Having prototype clearly separated into a package makes all questions obsolete. The same is true for mooTools and other ones.
4. users will also see that we don't favor the one over the other JS framework since each one is in it's own separate package
5. as Malcolm mentioned, we can't have the results right away, but need two major releases (2.2 deprecated, 2.3 removed), so we need to do it now to have the results maybe in a year.

Adrian A.
added a comment - 04/Mar/10 09:46 > I don't see a reason for pushing this change as this stage.
There are a few reasons IMHO:
1. make place for jQuery components
2. prototype libraries need updates too, so those components will be modified anyway (why not do the migration Malcolm proposed with this way?).
3. reduce confusion and make Click more predictable - I'm always asked about jQuery, and what components don't work with it. Having prototype clearly separated into a package makes all questions obsolete. The same is true for mooTools and other ones.
4. users will also see that we don't favor the one over the other JS framework since each one is in it's own separate package
5. as Malcolm mentioned, we can't have the results right away, but need two major releases (2.2 deprecated, 2.3 removed), so we need to do it now to have the results maybe in a year.

I'd like to see these Controls moved into their own sub-project -> click-prototytype, making it very clear to users and focusing the projects efforts. Supporting jQuery, Prototype, Mootools, YUI, RightJS inside Click doesn't scale and doesn't work in practice.

ColorPicker anfd CheckList should be an easy move. DateField however will be difficult. HTML5 datetime might help here though. By default DateField could be marketed as HTML5 compliant and have no JS dependency. The click-calendar project can be used as an alternative if HTML4 must be supported (HTML4 will be valid until 2020).

Bob Schellink
added a comment - 21/Nov/10 02:43 I'd like to see these Controls moved into their own sub-project -> click-prototytype, making it very clear to users and focusing the projects efforts. Supporting jQuery, Prototype, Mootools, YUI, RightJS inside Click doesn't scale and doesn't work in practice.
ColorPicker anfd CheckList should be an easy move. DateField however will be difficult. HTML5 datetime might help here though. By default DateField could be marketed as HTML5 compliant and have no JS dependency. The click-calendar project can be used as an alternative if HTML4 must be supported (HTML4 will be valid until 2020).

> I'd like to see these Controls moved into their own sub-project -> click-prototytype, making it very clear to users and focusing the projects efforts.
You mean an Apache Click "subproject", or just a subdirectory (like click examples), or something totally out of Apache like the case of click-jquery?
I proposed for the begining to just use a simple different package, as ANT can be simply changed to create for that package a:
"click-prototype-2.3.0.jar" that would contain only those prototype based classes.

> Supporting jQuery, Prototype, Mootools, YUI, RightJS inside Click doesn't scale and doesn't work in practice.
True. Besides they're mostly never used together, but only one at a time.

> DateField however will be difficult.
Another option might be to have by default a real "DateField" (not a Calendar), i.e. something with comboboxes, like the Rails DateTime Select
from the beginning of this video:http://railscasts.com/episodes/213-calendars
as a fallback mechanism when none of the other mentioned solutions are used.

> HTML5 datetime might help here though. By default DateField could be marketed as HTML5 compliant and have no JS dependency.
> The click-calendar project can be used as an alternative if HTML4 must be supported (HTML4 will be valid until 2020).
Interesting approach. Could be this process automated somehow, so that the users don't need extra effort to have this work with their existing apps?

Adrian A.
added a comment - 21/Nov/10 09:43 > I'd like to see these Controls moved into their own sub-project -> click-prototytype, making it very clear to users and focusing the projects efforts.
You mean an Apache Click "subproject", or just a subdirectory (like click examples), or something totally out of Apache like the case of click-jquery?
I proposed for the begining to just use a simple different package, as ANT can be simply changed to create for that package a:
"click-prototype-2.3.0.jar" that would contain only those prototype based classes.
> Supporting jQuery, Prototype, Mootools, YUI, RightJS inside Click doesn't scale and doesn't work in practice.
True. Besides they're mostly never used together, but only one at a time.
> DateField however will be difficult.
Another option might be to have by default a real "DateField" (not a Calendar), i.e. something with comboboxes, like the Rails DateTime Select
from the beginning of this video:
http://railscasts.com/episodes/213-calendars
as a fallback mechanism when none of the other mentioned solutions are used.
> HTML5 datetime might help here though. By default DateField could be marketed as HTML5 compliant and have no JS dependency.
> The click-calendar project can be used as an alternative if HTML4 must be supported (HTML4 will be valid until 2020).
Interesting approach. Could be this process automated somehow, so that the users don't need extra effort to have this work with their existing apps?

Yeah separate project focused on Prototype. Where it is hosted depends on who has interest in taking the project forward.

However we don't have to decide now, there is no rush and the DateField isn't easy or even possible to replace. I just don't want to introduce a prototype package which suggests we are going to add new controls for every JS lib out there.

Bob Schellink
added a comment - 22/Nov/10 12:20 Yeah separate project focused on Prototype. Where it is hosted depends on who has interest in taking the project forward.
However we don't have to decide now, there is no rush and the DateField isn't easy or even possible to replace. I just don't want to introduce a prototype package which suggests we are going to add new controls for every JS lib out there.

Adrian A.
added a comment - 02/Nov/13 22:21 Fixed in Branch click-3.0.0
Only DateField, CheckList, and ColorPicker were affected by this refactoring (the PickList control does not seem to depend on prototype.js)