Click
  1. Click
  2. CLK-529

Refactor Prototype based controls to org.apache.click.extras.prototype

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: extras
    • Labels:
      None

      Description

      Refactor the Prototype base Click controls to a separate package org.apache.click.extras.prototype.

      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

        Hide
        Adrian A. added a comment -

        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?

        Show
        Adrian A. added a comment - 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?
        Hide
        Malcolm Edgar added a comment -

        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.

        Show
        Malcolm Edgar added a comment - 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.
        Hide
        Bob Schellink added a comment -

        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.

        Show
        Bob Schellink added a comment - 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.
        Hide
        Adrian A. added a comment -

        > 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.

        Show
        Adrian A. added a comment - > 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.
        Hide
        Bob Schellink added a comment -

        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).

        Show
        Bob Schellink added a comment - 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).
        Hide
        Adrian A. added a comment -

        > 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?

        Show
        Adrian A. added a comment - > 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?
        Hide
        Bob Schellink added a comment -

        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.

        Show
        Bob Schellink added a comment - 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.
        Hide
        Adrian A. added a comment -

        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)

        Show
        Adrian A. added a comment - 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)

          People

          • Assignee:
            Adrian A.
            Reporter:
            Adrian A.
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development