[xwiki-devs] upgrade to gwt 1.4
Hi all, we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working). WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
IMO, Pros for migrating to ext, vs. sticking to gwttk: - larger community, visibility on roadmap - lots of widgets/functionnalities available (datepickers, form validation, etc.) - gwt 1.4 already compatible Cons: - every app has to import ext JS scripts in addition to gwt.js - increases total JS size It would be great to have opinions from the Curriki development team on the topic. Regards, Jerome.
WDYT?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jérôme, You might also consider MyGWT: http://mygwt.net/ if you're worried about the ext.js lib. It's a native implementation. For Curriki, there may be some issues with gwt-html-editor which in its 1.4 branch just brings up Fck Editor. I had some issues using gwt-html-editor trunk in 1.4.61. Luis. On Jan 14, 2008 9:55 AM, Jerome Velociter <[email protected]> wrote:
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
IMO,
Pros for migrating to ext, vs. sticking to gwttk: - larger community, visibility on roadmap - lots of widgets/functionnalities available (datepickers, form validation, etc.) - gwt 1.4 already compatible
Cons: - every app has to import ext JS scripts in addition to gwt.js - increases total JS size
It would be great to have opinions from the Curriki development team on the topic.
Regards, Jerome.
WDYT?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo
Hi Jérôme,
You might also consider MyGWT:
I checked it out, it has a lot of nice features, but, unfortunately, no 'date picker' widget (which is one of the reasons we started all this gwt-ext + gwt1.4 thing). So yes, we could use it, but it will not fully replace gwt-ext and fulfill our needs.
if you're worried about the ext.js lib. It's a native implementation.
For Curriki, there may be some issues with gwt-html-editor which in its 1.4 branch just brings up Fck Editor. I had some issues using gwt-html-editor trunk in 1.4.61.
So we definitely need an opinion from Curriki on this...
Luis.
On Jan 14, 2008 9:55 AM, Jerome Velociter <[email protected]> wrote:
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
IMO,
Pros for migrating to ext, vs. sticking to gwttk: - larger community, visibility on roadmap - lots of widgets/functionnalities available (datepickers, form validation, etc.) - gwt 1.4 already compatible
Cons: - every app has to import ext JS scripts in addition to gwt.js - increases total JS size
It would be great to have opinions from the Curriki development team on the topic.
Regards, Jerome.
WDYT?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi everybody, Jerome suggested yesterday that we could handle the upgrade as follows: - use MyGWT widgets library for the web-gwt functionalities (modal dialog boxes) since it is a pure java library and its usage only involves changes in the web-gwt code - if needed, gwt-ext could be used for particular projects using web-gwt api and each project's code could be changed accordingly (this would be the case for watch). Both libraries seem pretty reliable, with active developers and nice community, so, from this point of view, they are both superior to gwttk that we currently use. Here's my +1 for this approach. WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
WDYT?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Non-binding +1 from me too... Eager to have XWatch benefit from the results of this work :-) Guillaume On 17/01/2008, [email protected] <[email protected]> wrote:
Hi everybody,
Jerome suggested yesterday that we could handle the upgrade as follows: - use MyGWT widgets library for the web-gwt functionalities (modal dialog boxes) since it is a pure java library and its usage only involves changes in the web-gwt code - if needed, gwt-ext could be used for particular projects using web-gwt api and each project's code could be changed accordingly (this would be the case for watch).
Both libraries seem pretty reliable, with active developers and nice community, so, from this point of view, they are both superior to gwttk that we currently use.
Here's my +1 for this approach.
WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
WDYT?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
[email protected] wrote:
Hi everybody,
Jerome suggested yesterday that we could handle the upgrade as follows: - use MyGWT widgets library for the web-gwt functionalities (modal dialog boxes) since it is a pure java library and its usage only involves changes in the web-gwt code - if needed, gwt-ext could be used for particular projects using web-gwt api and each project's code could be changed accordingly (this would be the case for watch).
Both libraries seem pretty reliable, with active developers and nice community, so, from this point of view, they are both superior to gwttk that we currently use.
Here's my +1 for this approach.
WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
WDYT?
Hi, I think that the most important think is that updating the products using gwt should be as easy as possible. The two products that intensively use gwt are Watch and Curriki, and since you are a Watch developer, can you try the upgrade and see how much time it takes to update the failing code? Curriki is already on a tight deadline, so I'm sure they won't like long delays (however, they are still using an older branch, so they won't be affected by the trunk update yet). Sergiu
[email protected] wrote:
Hi everybody,
Jerome suggested yesterday that we could handle the upgrade as follows: - use MyGWT widgets library for the web-gwt functionalities (modal dialog boxes) since it is a pure java library and its usage only involves changes in the web-gwt code - if needed, gwt-ext could be used for particular projects using web-gwt api and each project's code could be changed accordingly (this would be the case for watch).
Both libraries seem pretty reliable, with active developers and nice community, so, from this point of view, they are both superior to gwttk that we currently use.
Here's my +1 for this approach.
WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
WDYT?
Hi,
I think that the most important think is that updating the products using gwt should be as easy as possible. The two products that intensively use gwt are Watch and Curriki, and since you are a Watch developer, can you try the upgrade and see how much time it takes to update the failing code?
I already did that with gwt-ext, the changes don't take long at all (6-8 hours, maybe) and they can be done in a transparent manner, without impacting for the code that uses them, except, of course for some appearance changes which are inevitable. There is also some testing to be done to ensure that no behaviour was changed which might also take some time. The problem with the projects using gwt code is that we would also upgrade gwt to gwt 1.4 and they must handle their own dependencies and resolve any code failing due to API breaking changes (which are not too many, actually). While XWiki Watch is OK from this point of view I don't know anything about Curriki yet.
Curriki is already on a tight deadline, so I'm sure they won't like long delays (however, they are still using an older branch, so they won't be affected by the trunk update yet).
Sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Curriki is currently running on the 1.1 branch. There is a possibility to move to the 1.2 branch for Curriki 1.5.1 (released in the next few weeks). Moving to gwt 1.4 is definitively in the plan for 1.6 to especially benefit from performance improvements. Curriki uses gwttk dialogs so would need to switch to other dialogs. There are no big needs of gwt-ext capabilities but I'm sure we can find uses for it afterwards. So from the Curriki point of view +1 to move to 1.4 and use MyGWT for modial dialogs and gwt-ext for more extensive features, as long as all this is in the 1.3 branch. From my point of view +1 also Ludovic [email protected] wrote:
[email protected] wrote:
Hi everybody,
Jerome suggested yesterday that we could handle the upgrade as follows: - use MyGWT widgets library for the web-gwt functionalities (modal dialog boxes) since it is a pure java library and its usage only involves changes in the web-gwt code - if needed, gwt-ext could be used for particular projects using web-gwt api and each project's code could be changed accordingly (this would be the case for watch).
Both libraries seem pretty reliable, with active developers and nice community, so, from this point of view, they are both superior to gwttk that we currently use.
Here's my +1 for this approach.
WDYT?
Hi all,
we want to upgrade XWiki Web gwt to gwt 1.4 for the 1.3 version so, since gwttk does not have a version for gwt 1.4 and we depend on it for creating modal dialogs, we need to replace tk with something else. A good option is gwt-ext, which also can replace gwt-widgets and provides some more nice ui objects and client functionality (like date parsing -- which we get from gwt-widgets for the moment). The trouble with gwt-ext is that it requires ext javascript library to run, which means that any gwt application needs to import, besides the gwt.js file, some ext javascript files. Since the modal dialogs are defined in the web-gwt module (so our gwt-ext dependency is there) and we cannot import the ext javascript files at that level, the only solution is to rely on the application using web-gwt to include right all required files. It doesn't seem to me as good practice but I cannot figure out how big of an issue it is (since that application already has some rules to obey, js files to include, etc to have gwt working).
WDYT?
Hi,
I think that the most important think is that updating the products using gwt should be as easy as possible. The two products that intensively use gwt are Watch and Curriki, and since you are a Watch developer, can you try the upgrade and see how much time it takes to update the failing code?
I already did that with gwt-ext, the changes don't take long at all (6-8 hours, maybe) and they can be done in a transparent manner, without impacting for the code that uses them, except, of course for some appearance changes which are inevitable. There is also some testing to be done to ensure that no behaviour was changed which might also take some time.
The problem with the projects using gwt code is that we would also upgrade gwt to gwt 1.4 and they must handle their own dependencies and resolve any code failing due to API breaking changes (which are not too many, actually). While XWiki Watch is OK from this point of view I don't know anything about Curriki yet.
Curriki is already on a tight deadline, so I'm sure they won't like long delays (however, they are still using an older branch, so they won't be affected by the trunk update yet).
Sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
participants (6)
-
ancapaula.luca＠xwiki.com -
Guillaume Lerouge -
Jerome Velociter -
Ludovic Dubost -
Luis Arias -
Sergiu Dumitriu