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
ancapaula.luca(a)xwiki.com wrote:
 
ancapaula.luca(a)xwiki.com 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
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
      
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs