Michael Neale wrote:We can certainly upgrade to GWT 2.0. If we run into any problems during
> I know someone was looking at upgrading to GWT 2.0, even with gwt-ext,
> it may still work
>
the upgrade, we can always fix them. There is a Jira ticket relates to
this topic: https://jira.jboss.org/jira/browse/GUVNOR-158 (Upgrade key
libary dependencies (post 5.0)).
Who is working on GWT 2.0 upgrade? If no one else is already starting
looking into GWT2.0, I will volunteer to do this.
Cheers,
Jervis
> On Tue, Feb 2, 2010 at 10:13 AM, Esteban Aliverti
> <esteban.aliverti@gmail.com <mailto:esteban.aliverti@gmail.com>> wrote:
>
> Ok, I agree with you. We have discussed this with conan today and
> get the same conclusion as you. We started looking at mosaic, but
> the biggest limitation we have right now is the GWT version we are
> using. New libraries are already using gwt 2.0, so we canīt use
> the latest versions of them. The same problem arise when composing
> widgets. GWT 1.5.3 is very basic.
> We will continue using native GWT or GWTExt until Guvnor is moved
> to GWT 2.x (I donīt know the effort required for that).
>
> Best,
>
>
> On Mon, Feb 1, 2010 at 11:31 PM, Michael Neale
> <michael.neale@gmail.com <mailto:michael.neale@gmail.com>> wrote:
>
> I don't think it would be a good idea unless migrating to
> SmartGWT overall - it would just drag on a whole other heavy
> framework.
>
> Longer term it would be nice to NOT depend on any JS
> frameworks- but use GWT native ones - the reason being that
> only the used bits are compiled in, and also as GWT compiler
> innovations continue apace, that insures compatability and
> speed improvements.
>
> I don't really see the need to use a JS library like SmartGWT
> - the only place we used GWT-ext was for the overall "chrome"
> look - (eg the accordion, tabs) and a few grid views, and a
> couple of trees, barely 10% of what is in the ext framework.
>
> I certainly think it is a very bad idea to use a framework
> like smart GWT now for widgets - the built in GWT ones are
> pretty basic, but it is worth the effort to compose them into
> richer ones, or look for GWT "native" ones to reuse - as at
> least they will be resolved at compile time. Some GWT ones to
> take a look at: http://vaadin.com/home
> and http://code.google.com/p/gwt-mosaic/
>
> (not that I have anything against javascript, just it makes
> things much harder with GWT, and kind of defeats the purpose
> of using it).
>
> Of course we would like to get off gwt-ext eventually, I don't
> think SmartGWT is the way to go, and certainly not introducing
> it unless we plan to migrate to it.
>
> On Tue, Feb 2, 2010 at 1:46 AM, Esteban Aliverti
> <esteban.aliverti@gmail.com
> rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>> <mailto:esteban.aliverti@gmail.com>> wrote:
>
> Hi all,
> Baunax and I are making some improvements in Guvnor's rule
> editor (from/collect/accumulate support, expression
> builder widget, etc.) and we want to start using Smart GWT
> (http://www.smartclient.com/). This library is the
> successor of GWText (the one Guvnor is using now). You can
> see this in GWText home
> page http://code.google.com/p/gwt-ext/.
> Some of the reasons we have to move to Smart GWT are:
>
> * GWTExt is deprecated. It is no longer under active
> development.
> * Smart GWT is under LGPL license (just like GWTExt)
> * Smart GWT support any version of GWT (from 1.5.3 to
> 2.0). There shouldn't be any problem when we start
> using GWT 2.xx
> * Smart GWT has a lot of widgets, effects, layouts
> etc. that can make our life easier ;).
>
> Of course we are not going to migrate Guvnor to Smart GWT;
> we want just to use it for the new features we are
> implementing.
>
> So, are you guys agree? Does anyone have any objection?
>
> We are currently working
> on guvnor_expressionEditor3_baunax_esteban branch.
>
> Best,
>
> --
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
>
> _______________________________________________
> rules-dev mailing list
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev> rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
>
>
>
> --
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Esteban Aliverti
>
> _______________________________________________
> rules-dev mailing list
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev