GlazedList GWT

[Thomas Sorgie]

Hey guys,

I've put together a branch of GL which runs on GWT.  I reduced the functionality quite a bit to the things that i think are applicable to the GWT environment (and what i needed there).

A few examples, of the changes i made:
Definitely good:
1. Removed all locking, and thread management code.  JS is single threaded.
2. Altered any use of unsupported jdk APIs to ones that work in GWT
3. Removed unnecessary swing/swt/networking code which wouldn't build in gwt

Arguably not-so-good:
1. I removed more than i really needed to.  Some features could be made to work that i removed just to thin out the package.  These could be put back in without too much cost since GWT is good at only including what you really need at runtime.
2. I renamed a few things that i really didn't need to, this would be easy to changed back.  Basically i renamed EventList to GlazedList.
3. I'm in the process of removing duplication in the GL library with the Google-collections-GWT library, using the google versions to avoid having two in my applications.  At a glance i think this should include moving Matcher to Predicate, and utilizing their multimap implmentation in place of the GL one.

My version is definitely incomplete, for instance i did not reimplement the equivalent swing table adapters for the gwt ones.  My project is using GXT and so i built adapters to that (with a dependancy on my framework).

I read the original note from Jesse on the subject of GWT, where he mentioned that GL can only really work well in an env where the whole list is in memory.  And while i agree with much of the premise of that, i'd argue that JS environments are really much more constrained by how much can be rendered to DOM than by how many objects and data can be kept in memory.  The fundamentals of what GL offers, really can make a big difference when developing any UI, even JavaScript ones.

I'm really interested in some of the additional comments about how GL often trades off memory for speed, and any suggestions of where we could perhaps provide alternate implementations with different/configurable tradeoffs.

Thanks again for GL, its really a very smart tool.

tom.

[Holger Brands]

Thomas,

that's interesting news.
We intend to provide *some support* for GWT in the future,
but we didn't start to plan or implement anything yet.

I guess the first step would be to identify the core of GL (without UI stuff)
which we could and would like to support on GWT.
Ideally, GWT support for this core would not require a different
implementation, but I don't know yet if that's feasible at all.
(Think about GL code, that you would like to use on the client *and* server)

Some quick thoughts:

- I wonder if we could stick to the EventList interface and use a no-op
LockAdapter for GWT

- how to support property change events? (using GWTx perhaps)

- how to support/deal with reflection?

- what other API problems did you encounter?

If you would like to share more details with us, that would be great.

Thanks,
Holger

>
> Hey guys,
>
> I've put together a branch of GL which runs on GWT.  I reduced the
> functionality quite a bit to the things that i think are applicable to the
> GWT environment (and what i needed there).
>
> A few examples, of the changes i made:
> Definitely good:
> 1. Removed all locking, and thread management code.  JS is single threaded.
> 2. Altered any use of unsupported jdk APIs to ones that work in GWT
> 3. Removed unnecessary swing/swt/networking code which wouldn't build in gwt
>
> Arguably not-so-good:
> 1. I removed more than i really needed to.  Some features could be made to
> work that i removed just to thin out the package.  These could be put back
> in without too much cost since GWT is good at only including what you really
> need at runtime.
> 2. I renamed a few things that i really didn't need to, this would be easy
> to changed back.  Basically i renamed EventList to GlazedList.
> 3. I'm in the process of removing duplication in the GL library with the
> Google-collections-GWT library, using the google versions to avoid having
> two in my applications.  At a glance i think this should include moving
> Matcher to Predicate, and utilizing their multimap implmentation in place of
> the GL one.
>
> My version is definitely incomplete, for instance i did not reimplement the
> equivalent swing table adapters for the gwt ones.  My project is using GXT
> and so i built adapters to that (with a dependancy on my framework).
>
> I read the original note from Jesse on the subject of GWT, where he
> mentioned that GL can only really work well in an env where the whole list
> is in memory.  And while i agree with much of the premise of that, i'd argue
> that JS environments are really much more constrained by how much can be
> rendered to DOM than by how many objects and data can be kept in memory.
> The fundamentals of what GL offers, really can make a big difference when
> developing any UI, even JavaScript ones.
>
> I'm really interested in some of the additional comments about how GL often
> trades off memory for speed, and any suggestions of where we could perhaps
> provide alternate implementations with different/configurable tradeoffs.
>
> Thanks again for GL, its really a very smart tool.
>
> tom.
> --
> View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23002550.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausländische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Thomas Sorgie]

Holger,

Let me try to reply to a few of your questions/thoughts..

1. About trying to get GL useable in GWT but without a different implementation.  Its probably possible but only with a pretty severe refactoring of the core of GL.  Some very useable java-library calls are simply not available in GWT, and if you would want to continue using them, you'd need to abstract that away.

2. As for sticking to the EventList interface with a no-op LockAdaptor, that's very doable.  But trying to keep the same implementations, doesn't quite work.  My first inclination was going to be to suggest creating a sister package called ca.odell.glazedgwt which would really begin with almost all new implmentation classes.  But many of the originals require only minor changes, so its possible to try to tweak those.

3. Property change and Reflection.  Yeah, this is a tough topic in GWT.  In my companies framework, we get around this issue by generating complex ValueObjects with automatic Property accessors.  There are a few opensource projects that do this ok as well.  Essentially the pattern is to work out a way to auto-magically (which means 'generator' in gwt), create support for access to properties via get(String), set(String, Object)  methods on your Beans.  Gwittr has support for a generator that does this, GXT does too.  We could have a few options, i believe even working out a way to just require that any Bean which GL has support for implement a simplfied interface with the requisite methods.  It would be great if Google standardized that sort of interface in the GWT core, but they haven't.


4. Other API problems.  There were definitely a few, and like i originally said, I over reduced at first, and I'm only adding back functionality now.  The great thing, is that the core complex algorithms worked with almost zero modification.  That's really what encouraged me to continue at the begining.  If you are into reviewing the results, i'd love to send over repackaged version of the library in the state i have it now (with a few changes).


Also what do you think about my suggestion/plans to create a dependancy on the new google-collections 1.0 release.  I think if i did that (which i definitely want for my project). I could thin the package out even more, and reduce duplication (which really costs you in js apps), with a library most uses will likely have.  The downside to this, of course, is that it means an even further deviation from the GL core.


Thanks for the reply,  talk to you again soon.

tom.

Holger Brands wrote:

Thomas,

that's interesting news.
We intend to provide *some support* for GWT in the future,
but we didn't start to plan or implement anything yet.

I guess the first step would be to identify the core of GL (without UI stuff)
which we could and would like to support on GWT.
Ideally, GWT support for this core would not require a different
implementation, but I don't know yet if that's feasible at all.
(Think about GL code, that you would like to use on the client *and* server)

Some quick thoughts:

- I wonder if we could stick to the EventList interface and use a no-op
LockAdapter for GWT

- how to support property change events? (using GWTx perhaps)

- how to support/deal with reflection?

- what other API problems did you encounter?

If you would like to share more details with us, that would be great.

Thanks,
Holger

>
> Hey guys,
>
> I've put together a branch of GL which runs on GWT.  I reduced the
> functionality quite a bit to the things that i think are applicable to the
> GWT environment (and what i needed there).
>
> A few examples, of the changes i made:
> Definitely good:
> 1. Removed all locking, and thread management code.  JS is single threaded.
> 2. Altered any use of unsupported jdk APIs to ones that work in GWT
> 3. Removed unnecessary swing/swt/networking code which wouldn't build in gwt
>
> Arguably not-so-good:
> 1. I removed more than i really needed to.  Some features could be made to
> work that i removed just to thin out the package.  These could be put back
> in without too much cost since GWT is good at only including what you really
> need at runtime.
> 2. I renamed a few things that i really didn't need to, this would be easy
> to changed back.  Basically i renamed EventList to GlazedList.
> 3. I'm in the process of removing duplication in the GL library with the
> Google-collections-GWT library, using the google versions to avoid having
> two in my applications.  At a glance i think this should include moving
> Matcher to Predicate, and utilizing their multimap implmentation in place of
> the GL one.
>
> My version is definitely incomplete, for instance i did not reimplement the
> equivalent swing table adapters for the gwt ones.  My project is using GXT
> and so i built adapters to that (with a dependancy on my framework).
>
> I read the original note from Jesse on the subject of GWT, where he
> mentioned that GL can only really work well in an env where the whole list
> is in memory.  And while i agree with much of the premise of that, i'd argue
> that JS environments are really much more constrained by how much can be
> rendered to DOM than by how many objects and data can be kept in memory.
> The fundamentals of what GL offers, really can make a big difference when
> developing any UI, even JavaScript ones.
>
> I'm really interested in some of the additional comments about how GL often
> trades off memory for speed, and any suggestions of where we could perhaps
> provide alternate implementations with different/configurable tradeoffs.
>
> Thanks again for GL, its really a very smart tool.
>
> tom.
> --
> View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23002550.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>


__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausländische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms




---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Endre Stølsvik-8]

On Sat, Apr 11, 2009 at 18:03, Thomas Sorgie <tsorgie@...> wrote:
>
> Hey guys,
>
> I've put together a branch of GL which runs on GWT.  I reduced the
> functionality quite a bit to the things that i think are applicable to the
> GWT environment (and what i needed there).

I would just want to say that I personally find this awesome! Thanks!

I wouldn't be surprised if Jesse also loves it! (He's the GL initiator
and a Googler and is apparently a part of the Google Collection bunch
(and Guice) - just FYI in case you don't study all list traffic - and
he talked about this exact scenario (porting to GWT and integrating
with Google Collections) some months ago)

Is the code available somewhere?

Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Thomas Sorgie]

Endre,

I agree, i'm pretty excited about getting to use GL in GWT too.  I haven't posted the code yet, mostly because i want to get some blessings, and suggestions for change, from these guys before publishing a branch of their library.

As i said, as of now, my version is a severe subset of the main GL branch (some good, some just incomplete).  I also have had to make modifications in most of their core objects (though the complex algorithmic stuff ported with minimal mods).  The only way to publish it in its current state would be to repackage the whole thing.  Ultimately i think that that will need to happen, but there is definitely an argument for trying to abstract and reuse the elements of the base library that require minimal change to run in GWT.

tom.

Endre Stølsvik-8 wrote:

On Sat, Apr 11, 2009 at 18:03, Thomas Sorgie <[e-mail]> wrote:
>
> Hey guys,
>
> I've put together a branch of GL which runs on GWT.  I reduced the
> functionality quite a bit to the things that i think are applicable to the
> GWT environment (and what i needed there).

I would just want to say that I personally find this awesome! Thanks!

I wouldn't be surprised if Jesse also loves it! (He's the GL initiator
and a Googler and is apparently a part of the Google Collection bunch
(and Guice) - just FYI in case you don't study all list traffic - and
he talked about this exact scenario (porting to GWT and integrating
with Google Collections) some months ago)

Is the code available somewhere?

Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[James Lemieux]

Hey Tom,

   First, major kudos to you for this undertaking. About 2ish years ago I worked on a GWT project and naturally would have wanted GL there too, but was daunted by the lack of support at that time for many classes from the JDK that we use within the current GL core implementation. Jesse and I discussed what would be required to integrate with GWT at that time, and our cursory decision was that we didn't think we could support GWT as "just another GL extension" directly in the Glazed Lists project, though this would be the ideal.

   Another subtle difference that pulls us toward a total fork is the large difference in performance characteristics between Javascript's sandbox and JVMs. I can imagine it being extremely difficult to cater to those different beasts from a single code base, and adding abstractions for the sake of speed increases the "mental weight" of the implementation.

   And it would suck to have the vestigial getReadWriteLock() on EventList in a single-threaded environment...

   As for blessings from "the GL project" before publishing a branch... please... go forth and prosper. Our selection of the LGPL and MPL is only to ensure that derivative works are available to the community, whether from private money-making companies or other open projects, and no one forks GL needlessly. A GWT "fork" is a very fair example of a reason to fork GL.

   So please, go ahead with our blessing and don't hesitate to ask us about peculiarities you find! We'll help you in any way we can.

James

On Tue, Apr 14, 2009 at 11:42 AM, Thomas Sorgie <tsorgie@...> wrote:

Endre,

I agree, i'm pretty excited about getting to use GL in GWT too.  I haven't
posted the code yet, mostly because i want to get some blessings, and
suggestions for change, from these guys before publishing a branch of their
library.

As i said, as of now, my version is a severe subset of the main GL branch
(some good, some just incomplete).  I also have had to make modifications in
most of their core objects (though the complex algorithmic stuff ported with
minimal mods).  The only way to publish it in its current state would be to
repackage the whole thing.  Ultimately i think that that will need to
happen, but there is definitely an argument for trying to abstract and reuse
the elements of the base library that require minimal change to run in GWT.

tom.

Endre Stølsvik-8 wrote:
>
> On Sat, Apr 11, 2009 at 18:03, Thomas Sorgie <tsorgie@...> wrote:
>>
>> Hey guys,
>>
>> I've put together a branch of GL which runs on GWT.  I reduced the
>> functionality quite a bit to the things that i think are applicable to
>> the
>> GWT environment (and what i needed there).
>
> I would just want to say that I personally find this awesome! Thanks!
>
> I wouldn't be surprised if Jesse also loves it! (He's the GL initiator
> and a Googler and is apparently a part of the Google Collection bunch
> (and Guice) - just FYI in case you don't study all list traffic - and
> he talked about this exact scenario (porting to GWT and integrating
> with Google Collections) some months ago)
>
> Is the code available somewhere?
>
> Endre.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>

--
View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23045533.html

Sent from the GlazedLists - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Thomas Sorgie]

James, Holger, thanks for the encouragement..  Just one final question about packaging and publish location.  Do you want me to package as ca.odell.glazedgwt as i suggested, or just create a branch without the Glazed naming.  I can definitely use my own companies name in the packaging (com.tradecard), if you would prefer.  Also if the latter, do you have any issue with me identifying it as "GlazedLists"?   I would just post it on code.google.com, and i'd love to call it GlazedListsGWT, but if you would prefer i not use that name, that is ok with me.

I'll try to put something together in the next few days (just started the merge with google-collections-gwt)..  just need to do a bit of repackaging.

tom.

James Lemieux wrote:

Hey Tom,

   First, major kudos to you for this undertaking. About 2ish years ago I
worked on a GWT project and naturally would have wanted GL there too, but
was daunted by the lack of support at that time for many classes from the
JDK that we use within the current GL core implementation. Jesse and I
discussed what would be required to integrate with GWT at that time, and our
cursory decision was that we didn't think we could support GWT as "just
another GL extension" directly in the Glazed Lists project, though this
would be the ideal.

   Another subtle difference that pulls us toward a total fork is the large
difference in performance characteristics between Javascript's sandbox and
JVMs. I can imagine it being extremely difficult to cater to those different
beasts from a single code base, and adding abstractions for the sake of
speed increases the "mental weight" of the implementation.

   And it would suck to have the vestigial getReadWriteLock() on EventList
in a single-threaded environment...

   As for blessings from "the GL project" before publishing a branch...
please... go forth and prosper. Our selection of the LGPL and MPL is only to
ensure that derivative works are available to the community, whether from
private money-making companies or other open projects, and no one forks GL
needlessly. A GWT "fork" is a very fair example of a reason to fork GL.

   So please, go ahead with our blessing and don't hesitate to ask us about
peculiarities you find! We'll help you in any way we can.

James

On Tue, Apr 14, 2009 at 11:42 AM, Thomas Sorgie <[e-mail]> wrote:

>
> Endre,
>
> I agree, i'm pretty excited about getting to use GL in GWT too.  I haven't
> posted the code yet, mostly because i want to get some blessings, and
> suggestions for change, from these guys before publishing a branch of their
> library.
>
> As i said, as of now, my version is a severe subset of the main GL branch
> (some good, some just incomplete).  I also have had to make modifications
> in
> most of their core objects (though the complex algorithmic stuff ported
> with
> minimal mods).  The only way to publish it in its current state would be to
> repackage the whole thing.  Ultimately i think that that will need to
> happen, but there is definitely an argument for trying to abstract and
> reuse
> the elements of the base library that require minimal change to run in GWT.
>
> tom.
>
>
>
> Endre Stølsvik-8 wrote:
> >
> > On Sat, Apr 11, 2009 at 18:03, Thomas Sorgie <[e-mail]> wrote:
> >>
> >> Hey guys,
> >>
> >> I've put together a branch of GL which runs on GWT.  I reduced the
> >> functionality quite a bit to the things that i think are applicable to
> >> the
> >> GWT environment (and what i needed there).
> >
> > I would just want to say that I personally find this awesome! Thanks!
> >
> > I wouldn't be surprised if Jesse also loves it! (He's the GL initiator
> > and a Googler and is apparently a part of the Google Collection bunch
> > (and Guice) - just FYI in case you don't study all list traffic - and
> > he talked about this exact scenario (porting to GWT and integrating
> > with Google Collections) some months ago)
> >
> > Is the code available somewhere?
> >
> > Endre.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [e-mail]
> > For additional commands, e-mail: [e-mail]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/GlazedList-GWT-tp23002550p23045533.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Endre Stølsvik-8]

[com|org|net].glazedlist[s] was very available last time I checked.
Why not use that?!

On Tue, Apr 14, 2009 at 21:50, Thomas Sorgie <tsorgie@...> wrote:

>
>
> James, Holger, thanks for the encouragement..  Just one final question about
> packaging and publish location.  Do you want me to package as
> ca.odell.glazedgwt as i suggested, or just create a branch without the
> Glazed naming.  I can definitely use my own companies name in the packaging
> (com.tradecard), if you would prefer.  Also if the latter, do you have any
> issue with me identifying it as "GlazedLists"?   I would just post it on
> code.google.com, and i'd love to call it GlazedListsGWT, but if you would
> prefer i not use that name, that is ok with me.
>
> I'll try to put something together in the next few days (just started the
> merge with google-collections-gwt)..  just need to do a bit of repackaging.
>
> tom.
>
>
> James Lemieux wrote:
>>
>> Hey Tom,
>>
>>    First, major kudos to you for this undertaking. About 2ish years ago I
>> worked on a GWT project and naturally would have wanted GL there too, but
>> was daunted by the lack of support at that time for many classes from the
>> JDK that we use within the current GL core implementation. Jesse and I
>> discussed what would be required to integrate with GWT at that time, and
>> our
>> cursory decision was that we didn't think we could support GWT as "just
>> another GL extension" directly in the Glazed Lists project, though this
>> would be the ideal.
>>
>>    Another subtle difference that pulls us toward a total fork is the
>> large
>> difference in performance characteristics between Javascript's sandbox and
>> JVMs. I can imagine it being extremely difficult to cater to those
>> different
>> beasts from a single code base, and adding abstractions for the sake of
>> speed increases the "mental weight" of the implementation.
>>
>>    And it would suck to have the vestigial getReadWriteLock() on EventList
>> in a single-threaded environment...
>>
>>    As for blessings from "the GL project" before publishing a branch...
>> please... go forth and prosper. Our selection of the LGPL and MPL is only
>> to
>> ensure that derivative works are available to the community, whether from
>> private money-making companies or other open projects, and no one forks GL
>> needlessly. A GWT "fork" is a very fair example of a reason to fork GL.
>>
>>    So please, go ahead with our blessing and don't hesitate to ask us
>> about
>> peculiarities you find! We'll help you in any way we can.
>>
>> James
>>
>> On Tue, Apr 14, 2009 at 11:42 AM, Thomas Sorgie <tsorgie@...> wrote:
>>
>>>
>>> Endre,
>>>
>>> I agree, i'm pretty excited about getting to use GL in GWT too.  I
>>> haven't
>>> posted the code yet, mostly because i want to get some blessings, and
>>> suggestions for change, from these guys before publishing a branch of
>>> their
>>> library.
>>>
>>> As i said, as of now, my version is a severe subset of the main GL branch
>>> (some good, some just incomplete).  I also have had to make modifications
>>> in
>>> most of their core objects (though the complex algorithmic stuff ported
>>> with
>>> minimal mods).  The only way to publish it in its current state would be
>>> to
>>> repackage the whole thing.  Ultimately i think that that will need to
>>> happen, but there is definitely an argument for trying to abstract and
>>> reuse
>>> the elements of the base library that require minimal change to run in
>>> GWT.
>>>
>>> tom.
>>>
>>>
>>>
>>> Endre Stølsvik-8 wrote:
>>> >
>>> > On Sat, Apr 11, 2009 at 18:03, Thomas Sorgie <tsorgie@...> wrote:
>>> >>
>>> >> Hey guys,
>>> >>
>>> >> I've put together a branch of GL which runs on GWT.  I reduced the
>>> >> functionality quite a bit to the things that i think are applicable to
>>> >> the
>>> >> GWT environment (and what i needed there).
>>> >
>>> > I would just want to say that I personally find this awesome! Thanks!
>>> >
>>> > I wouldn't be surprised if Jesse also loves it! (He's the GL initiator
>>> > and a Googler and is apparently a part of the Google Collection bunch
>>> > (and Guice) - just FYI in case you don't study all list traffic - and
>>> > he talked about this exact scenario (porting to GWT and integrating
>>> > with Google Collections) some months ago)
>>> >
>>> > Is the code available somewhere?
>>> >
>>> > Endre.
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@...
>>> > For additional commands, e-mail: dev-help@...
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/GlazedList-GWT-tp23002550p23045533.html
>>> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23046715.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Holger Brands]

Hey Thomas,

thanks for the infos.

The disadvantage of having a different GL implementation for GWT
is the lack of support for existing domain models that already use
the "normal" Glazed Lists.
You would have to create some kind of DTO model and copy the list
contents for use with a GWT client.
But often, you have to create these DTOs for other reasons anyway,
so I guess it's not a big problem for most people.

Regarding property change support, we've used
GWTx (http://code.google.com/p/gwtx/) with success in the past,
so it might be helpful to you, too.

With regard to google-collections: is it compatible with GWT or is
there a GWT-specific version somewhere ?

As James already said, don't hesitate to make your Glazed Lists GWT
version available somewhere, so other users can give it a try.
As for the base package name, I don't have any preference.
It just shouldn't collide with the original GL package; "ca.odell" is
probably suboptimal in your case anyway...

Thanks for your effort,
Holger

>
> Holger,
>
> Let me try to reply to a few of your questions/thoughts..
>
> 1. About trying to get GL useable in GWT but without a different
> implementation.  Its probably possible but only with a pretty severe
> refactoring of the core of GL.  Some very useable java-library calls are
> simply not available in GWT, and if you would want to continue using them,
> you'd need to abstract that away.
>
> 2. As for sticking to the EventList interface with a no-op LockAdaptor,
> that's very doable.  But trying to keep the same implementations, doesn't
> quite work.  My first inclination was going to be to suggest creating a
> sister package called ca.odell.glazedgwt which would really begin with
> almost all new implmentation classes.  But many of the originals require
> only minor changes, so its possible to try to tweak those.
>
> 3. Property change and Reflection.  Yeah, this is a tough topic in GWT.  In
> my companies framework, we get around this issue by generating complex
> ValueObjects with automatic Property accessors.  There are a few opensource
> projects that do this ok as well.  Essentially the pattern is to work out a
> way to auto-magically (which means 'generator' in gwt), create support for
> access to properties via get(String), set(String, Object)  methods on your
> Beans.  Gwittr has support for a generator that does this, GXT does too.  We
> could have a few options, i believe even working out a way to just require
> that any Bean which GL has support for implement a simplfied interface with
> the requisite methods.  It would be great if Google standardized that sort
> of interface in the GWT core, but they haven't.
>
>
> 4. Other API problems.  There were definitely a few, and like i originally
> said, I over reduced at first, and I'm only adding back functionality now.
> The great thing, is that the core complex algorithms worked with almost zero
> modification.  That's really what encouraged me to continue at the begining.
> If you are into reviewing the results, i'd love to send over repackaged
> version of the library in the state i have it now (with a few changes).
>
>
> Also what do you think about my suggestion/plans to create a dependancy on
> the new google-collections 1.0 release.  I think if i did that (which i
> definitely want for my project). I could thin the package out even more, and
> reduce duplication (which really costs you in js apps), with a library most
> uses will likely have.  The downside to this, of course, is that it means an
> even further deviation from the GL core.
>
>
> Thanks for the reply,  talk to you again soon.
>
> tom.
>
>
> Holger Brands wrote:
> >
> > Thomas,
> >
> > that's interesting news.
> > We intend to provide *some support* for GWT in the future,
> > but we didn't start to plan or implement anything yet.
> >
> > I guess the first step would be to identify the core of GL (without UI
> > stuff)
> > which we could and would like to support on GWT.
> > Ideally, GWT support for this core would not require a different
> > implementation, but I don't know yet if that's feasible at all.
> > (Think about GL code, that you would like to use on the client *and*
> > server)
> >
> > Some quick thoughts:
> >
> > - I wonder if we could stick to the EventList interface and use a no-op
> > LockAdapter for GWT
> >
> > - how to support property change events? (using GWTx perhaps)
> >
> > - how to support/deal with reflection?
> >
> > - what other API problems did you encounter?
> >
> > If you would like to share more details with us, that would be great.
> >
> > Thanks,
> > Holger
> >
> >>
> >> Hey guys,
> >>
> >> I've put together a branch of GL which runs on GWT.  I reduced the
> >> functionality quite a bit to the things that i think are applicable to
> >> the
> >> GWT environment (and what i needed there).
> >>
> >> A few examples, of the changes i made:
> >> Definitely good:
> >> 1. Removed all locking, and thread management code.  JS is single
> >> threaded.
> >> 2. Altered any use of unsupported jdk APIs to ones that work in GWT
> >> 3. Removed unnecessary swing/swt/networking code which wouldn't build in
> >> gwt
> >>
> >> Arguably not-so-good:
> >> 1. I removed more than i really needed to.  Some features could be made
> >> to
> >> work that i removed just to thin out the package.  These could be put
> >> back
> >> in without too much cost since GWT is good at only including what you
> >> really
> >> need at runtime.
> >> 2. I renamed a few things that i really didn't need to, this would be
> >> easy
> >> to changed back.  Basically i renamed EventList to GlazedList.
> >> 3. I'm in the process of removing duplication in the GL library with the
> >> Google-collections-GWT library, using the google versions to avoid having
> >> two in my applications.  At a glance i think this should include moving
> >> Matcher to Predicate, and utilizing their multimap implmentation in place
> >> of
> >> the GL one.
> >>
> >> My version is definitely incomplete, for instance i did not reimplement
> >> the
> >> equivalent swing table adapters for the gwt ones.  My project is using
> >> GXT
> >> and so i built adapters to that (with a dependancy on my framework).
> >>
> >> I read the original note from Jesse on the subject of GWT, where he
> >> mentioned that GL can only really work well in an env where the whole
> >> list
> >> is in memory.  And while i agree with much of the premise of that, i'd
> >> argue
> >> that JS environments are really much more constrained by how much can be
> >> rendered to DOM than by how many objects and data can be kept in memory.
> >> The fundamentals of what GL offers, really can make a big difference when
> >> developing any UI, even JavaScript ones.
> >>
> >> I'm really interested in some of the additional comments about how GL
> >> often
> >> trades off memory for speed, and any suggestions of where we could
> >> perhaps
> >> provide alternate implementations with different/configurable tradeoffs.
> >>
> >> Thanks again for GL, its really a very smart tool.
> >>
> >> tom.
> >> --
> >> View this message in context:
> >> http://www.nabble.com/GlazedList-GWT-tp23002550p23002550.html
> >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >
> > __________________________________________________________________________
> > Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
> > ausländische Netze zum gleichen Preis!
> > https://produkte.web.de/webde_sms/sms
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23039520.html
> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[James Lemieux]

Jesse and I chatted about the two questions (naming and package structure) and have some ideas:

1. We would like to offer (not require though) you the chance to store your source code in GL's CVS repository so that the two projects are developed in close lockstep. This is just an offer, and you are of course free to host your source code wherever you like, but we thought that it may be easier if your build system literally built from our sources in the same source tree. Our thinking is that:

a) any developments in the GL core that could affect GLGWT will be noticed and dealt with immediately

a) development will occur in a more joint fashion since developers have access to working versions of GL and GLGWT built in lockstep... there is no ambiguity about which GL and GLGWT jars "work with each other"

b) all GWT source and artifacts would live under \gwt at the root level, so you'd "have your own space", but your build files are free to refer to ..\source\ca\odell... directly, and your build system (e.g. ANT build.xml if that's what you use) can pick and choose what classes/interfaces you can share unchanged with the GL core, and what you may want to fork...

2. Regarding package naming, Jesse's thoughts are that it is conceivable that one day we could invent a type of GWT EventList that actually spans from server to client... i.e. I call myGWTBasicEventList.add("Hello World"); on the server in Java using standard GL and all *clients* receive that ListEvent and propagate it naturally throughout the Javascript side of the pipeline in GLGWT. The power is... unimaginable. :-) If such a beast were to ever come to fruition, there's a possiblity we'd want to do some GWT-style class substitution, and it may be nicer for us to have similar/identical package naming in that case.... thoughts? But, I also admit this is pie-in-the-sky speculation, and not a hard-and-fast reason for you to mandatorily adopt our package structure...

3. One of the artifacts produced in a "full GL build" would thus be something like "glazedlists-1.9.0_gwt.jar" which would be a jar of .java files produced from the \gwt area of source control.

4. You could use our Google Site for all of your community documentation, etc. Or, if you wanted, you could create your own public face and just keep the source code in our repository. It's really whatever works for you.

5. If we do want to be bound tightly, that would probably necessitate that you use GL style interfaces over Google Collections (e.g. Matcher vs. Predicate). Of course we can trivially make adapters between the two, but this is still a point that should be made now so there is no ambiguity.

Please don't feel we're trying to strongarm you into being assimilated into the GL project. Our motivations are purely for making the best environment for GL and GLGWT to succeed together. If the projects are so closely aligned that GL developers are building GLGWT and vice-versa then I feel we have the best chance at code reuse and refining issues between the projects when they arise. We don't want to steal your thunder here at all...

James (& Jesse)

On Wed, Apr 15, 2009 at 11:57 AM, Holger Brands <hbrands@...> wrote:

Hey Thomas,

thanks for the infos.

The disadvantage of having a different GL implementation for GWT
is the lack of support for existing domain models that already use
the "normal" Glazed Lists.
You would have to create some kind of DTO model and copy the list
contents for use with a GWT client.
But often, you have to create these DTOs for other reasons anyway,
so I guess it's not a big problem for most people.

Regarding property change support, we've used
GWTx (http://code.google.com/p/gwtx/) with success in the past,
so it might be helpful to you, too.

With regard to google-collections: is it compatible with GWT or is
there a GWT-specific version somewhere ?

As James already said, don't hesitate to make your Glazed Lists GWT
version available somewhere, so other users can give it a try.
As for the base package name, I don't have any preference.
It just shouldn't collide with the original GL package; "ca.odell" is
probably suboptimal in your case anyway...

Thanks for your effort,
Holger

>
> Holger,
>
> Let me try to reply to a few of your questions/thoughts..
>
> 1. About trying to get GL useable in GWT but without a different
> implementation.  Its probably possible but only with a pretty severe
> refactoring of the core of GL.  Some very useable java-library calls are
> simply not available in GWT, and if you would want to continue using them,
> you'd need to abstract that away.
>
> 2. As for sticking to the EventList interface with a no-op LockAdaptor,
> that's very doable.  But trying to keep the same implementations, doesn't
> quite work.  My first inclination was going to be to suggest creating a
> sister package called ca.odell.glazedgwt which would really begin with
> almost all new implmentation classes.  But many of the originals require
> only minor changes, so its possible to try to tweak those.
>
> 3. Property change and Reflection.  Yeah, this is a tough topic in GWT.  In
> my companies framework, we get around this issue by generating complex
> ValueObjects with automatic Property accessors.  There are a few opensource
> projects that do this ok as well.  Essentially the pattern is to work out a
> way to auto-magically (which means 'generator' in gwt), create support for
> access to properties via get(String), set(String, Object)  methods on your
> Beans.  Gwittr has support for a generator that does this, GXT does too.  We
> could have a few options, i believe even working out a way to just require
> that any Bean which GL has support for implement a simplfied interface with
> the requisite methods.  It would be great if Google standardized that sort
> of interface in the GWT core, but they haven't.
>
>
> 4. Other API problems.  There were definitely a few, and like i originally
> said, I over reduced at first, and I'm only adding back functionality now.
> The great thing, is that the core complex algorithms worked with almost zero
> modification.  That's really what encouraged me to continue at the begining.
> If you are into reviewing the results, i'd love to send over repackaged
> version of the library in the state i have it now (with a few changes).
>
>
> Also what do you think about my suggestion/plans to create a dependancy on
> the new google-collections 1.0 release.  I think if i did that (which i
> definitely want for my project). I could thin the package out even more, and
> reduce duplication (which really costs you in js apps), with a library most
> uses will likely have.  The downside to this, of course, is that it means an
> even further deviation from the GL core.
>
>
> Thanks for the reply,  talk to you again soon.
>
> tom.
>
>
> Holger Brands wrote:
> >
> > Thomas,
> >
> > that's interesting news.
> > We intend to provide *some support* for GWT in the future,
> > but we didn't start to plan or implement anything yet.
> >
> > I guess the first step would be to identify the core of GL (without UI
> > stuff)
> > which we could and would like to support on GWT.
> > Ideally, GWT support for this core would not require a different
> > implementation, but I don't know yet if that's feasible at all.
> > (Think about GL code, that you would like to use on the client *and*
> > server)
> >
> > Some quick thoughts:
> >
> > - I wonder if we could stick to the EventList interface and use a no-op
> > LockAdapter for GWT
> >
> > - how to support property change events? (using GWTx perhaps)
> >
> > - how to support/deal with reflection?
> >
> > - what other API problems did you encounter?
> >
> > If you would like to share more details with us, that would be great.
> >
> > Thanks,
> > Holger
> >
> >>

> >> Hey guys,
> >>
> >> I've put together a branch of GL which runs on GWT.  I reduced the
> >> functionality quite a bit to the things that i think are applicable to
> >> the
> >> GWT environment (and what i needed there).
> >>

> >> A few examples, of the changes i made:
> >> Definitely good:
> >> 1. Removed all locking, and thread management code.  JS is single
> >> threaded.
> >> 2. Altered any use of unsupported jdk APIs to ones that work in GWT
> >> 3. Removed unnecessary swing/swt/networking code which wouldn't build in
> >> gwt
> >>
> >> Arguably not-so-good:
> >> 1. I removed more than i really needed to.  Some features could be made
> >> to
> >> work that i removed just to thin out the package.  These could be put
> >> back
> >> in without too much cost since GWT is good at only including what you
> >> really
> >> need at runtime.
> >> 2. I renamed a few things that i really didn't need to, this would be
> >> easy
> >> to changed back.  Basically i renamed EventList to GlazedList.
> >> 3. I'm in the process of removing duplication in the GL library with the
> >> Google-collections-GWT library, using the google versions to avoid having
> >> two in my applications.  At a glance i think this should include moving
> >> Matcher to Predicate, and utilizing their multimap implmentation in place
> >> of
> >> the GL one.
> >>
> >> My version is definitely incomplete, for instance i did not reimplement
> >> the
> >> equivalent swing table adapters for the gwt ones.  My project is using
> >> GXT
> >> and so i built adapters to that (with a dependancy on my framework).
> >>
> >> I read the original note from Jesse on the subject of GWT, where he
> >> mentioned that GL can only really work well in an env where the whole
> >> list
> >> is in memory.  And while i agree with much of the premise of that, i'd
> >> argue
> >> that JS environments are really much more constrained by how much can be
> >> rendered to DOM than by how many objects and data can be kept in memory.
> >> The fundamentals of what GL offers, really can make a big difference when
> >> developing any UI, even JavaScript ones.
> >>
> >> I'm really interested in some of the additional comments about how GL
> >> often
> >> trades off memory for speed, and any suggestions of where we could
> >> perhaps
> >> provide alternate implementations with different/configurable tradeoffs.
> >>
> >> Thanks again for GL, its really a very smart tool.
> >>
> >> tom.
> >> --

> >> View this message in context:

> >> http://www.nabble.com/GlazedList-GWT-tp23002550p23002550.html

> >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >>
> >
> >

> > __________________________________________________________________________
> > Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
> > ausländische Netze zum gleichen Preis!
> > https://produkte.web.de/webde_sms/sms
> >
> >
> >
> >
> > ---------------------------------------------------------------------

> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
>
> --

> View this message in context: http://www.nabble.com/GlazedList-GWT-tp23002550p23039520.html

> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Thomas Sorgie]

James,

I think this sounds great.  I will say that i'm a lot more familiar with svn than with cvs, but i'm sure i'll adapt.  As for sharing space for documentation etc, again i think that's great, i prefer to try to the expand on the already existing community around GL, rather than create another one.

The only minor point of contention is probably around the idea of trying to take more advantage of the google-collections library.  Its really quite fantastic, and likely to be soon embedded in gwt.  With the code size limitations of any js app, any duplication seems really wrong.  If all we're really talking about is Matcher, we can work it out with a simple adapter.  My bigger concerns are around implementation classes that can be removed from GL, if we find duplication.

On the subject of "thunder stealing", seriously, no worries.  I really feel that i should be more concerned about hijacking the GL name, than you should be about taking any thing from me.  So lets just agree to pass on the platitudes from this point forward.

tom.

James Lemieux wrote:

Jesse and I chatted about the two questions (naming and package structure)
and have some ideas:

1. We would like to offer (not require though) you the chance to store your
source code in GL's CVS repository so that the two projects are developed in
close lockstep. This is just an offer, and you are of course free to host
your source code wherever you like, but we thought that it may be easier if
your build system literally built from our sources in the same source tree.
Our thinking is that:

a) any developments in the GL core that could affect GLGWT will be noticed
and dealt with immediately

a) development will occur in a more joint fashion since developers have
access to working versions of GL and GLGWT built in lockstep... there is no
ambiguity about which GL and GLGWT jars "work with each other"

b) all GWT source and artifacts would live under \gwt at the root level, so
you'd "have your own space", but your build files are free to refer to
..\source\ca\odell... directly, and your build system (e.g. ANT build.xml if
that's what you use) can pick and choose what classes/interfaces you can
share unchanged with the GL core, and what you may want to fork...

2. Regarding package naming, Jesse's thoughts are that it is conceivable
that one day we could invent a type of GWT EventList that actually spans
from server to client... i.e. I call myGWTBasicEventList.add("Hello World");
on the server in Java using standard GL and all *clients* receive that
ListEvent and propagate it naturally throughout the Javascript side of the
pipeline in GLGWT. The power is... unimaginable. :-) If such a beast were to
ever come to fruition, there's a possiblity we'd want to do some GWT-style
class substitution, and it may be nicer for us to have similar/identical
package naming in that case.... thoughts? But, I also admit this is
pie-in-the-sky speculation, and not a hard-and-fast reason for you to
mandatorily adopt our package structure...

3. One of the artifacts produced in a "full GL build" would thus be
something like "glazedlists-1.9.0_gwt.jar" which would be a jar of .java
files produced from the \gwt area of source control.

4. You could use our Google Site for all of your community documentation,
etc. Or, if you wanted, you could create your own public face and just keep
the source code in our repository. It's really whatever works for you.

5. If we do want to be bound tightly, that would probably necessitate that
you use GL style interfaces over Google Collections (e.g. Matcher vs.
Predicate). Of course we can trivially make adapters between the two, but
this is still a point that should be made now so there is no ambiguity.

Please don't feel we're trying to strongarm you into being assimilated into
the GL project. Our motivations are purely for making the best environment
for GL and GLGWT to succeed together. If the projects are so closely aligned
that GL developers are building GLGWT and vice-versa then I feel we have the
best chance at code reuse and refining issues between the projects when they
arise. We don't want to steal your thunder here at all...

James (& Jesse)

On Wed, Apr 15, 2009 at 11:57 AM, Holger Brands <[e-mail]> wrote:

> Hey Thomas,
>
> thanks for the infos.
>
> The disadvantage of having a different GL implementation for GWT
> is the lack of support for existing domain models that already use
> the "normal" Glazed Lists.
> You would have to create some kind of DTO model and copy the list
> contents for use with a GWT client.
> But often, you have to create these DTOs for other reasons anyway,
> so I guess it's not a big problem for most people.
>
> Regarding property change support, we've used
> GWTx (http://code.google.com/p/gwtx/) with success in the past,
> so it might be helpful to you, too.
>
> With regard to google-collections: is it compatible with GWT or is
> there a GWT-specific version somewhere ?
>
> As James already said, don't hesitate to make your Glazed Lists GWT
> version available somewhere, so other users can give it a try.
> As for the base package name, I don't have any preference.
> It just shouldn't collide with the original GL package; "ca.odell" is
> probably suboptimal in your case anyway...
>
> Thanks for your effort,
> Holger
>
>
> >
> > Holger,
> >
> > Let me try to reply to a few of your questions/thoughts..
> >
> > 1. About trying to get GL useable in GWT but without a different
> > implementation.  Its probably possible but only with a pretty severe
> > refactoring of the core of GL.  Some very useable java-library calls are
> > simply not available in GWT, and if you would want to continue using
> them,
> > you'd need to abstract that away.
> >
> > 2. As for sticking to the EventList interface with a no-op LockAdaptor,
> > that's very doable.  But trying to keep the same implementations, doesn't
> > quite work.  My first inclination was going to be to suggest creating a
> > sister package called ca.odell.glazedgwt which would really begin with
> > almost all new implmentation classes.  But many of the originals require
> > only minor changes, so its possible to try to tweak those.
> >
> > 3. Property change and Reflection.  Yeah, this is a tough topic in GWT.
>  In
> > my companies framework, we get around this issue by generating complex
> > ValueObjects with automatic Property accessors.  There are a few
> opensource
> > projects that do this ok as well.  Essentially the pattern is to work out
> a
> > way to auto-magically (which means 'generator' in gwt), create support
> for
> > access to properties via get(String), set(String, Object)  methods on
> your
> > Beans.  Gwittr has support for a generator that does this, GXT does too.
>  We
> > could have a few options, i believe even working out a way to just
> require
> > that any Bean which GL has support for implement a simplfied interface
> with
> > the requisite methods.  It would be great if Google standardized that
> sort
> > of interface in the GWT core, but they haven't.
> >
> >
> > 4. Other API problems.  There were definitely a few, and like i
> originally
> > said, I over reduced at first, and I'm only adding back functionality
> now.
> > The great thing, is that the core complex algorithms worked with almost
> zero
> > modification.  That's really what encouraged me to continue at the
> begining.
> > If you are into reviewing the results, i'd love to send over repackaged
> > version of the library in the state i have it now (with a few changes).
> >
> >
> > Also what do you think about my suggestion/plans to create a dependancy
> on
> > the new google-collections 1.0 release.  I think if i did that (which i
> > definitely want for my project). I could thin the package out even more,
> and
> > reduce duplication (which really costs you in js apps), with a library
> most
> > uses will likely have.  The downside to this, of course, is that it means
> an
> > even further deviation from the GL core.
> >
> >
> > Thanks for the reply,  talk to you again soon.
> >
> > tom.
> >
> >
> > Holger Brands wrote:
> > >
> > > Thomas,
> > >
> > > that's interesting news.
> > > We intend to provide *some support* for GWT in the future,
> > > but we didn't start to plan or implement anything yet.
> > >
> > > I guess the first step would be to identify the core of GL (without UI
> > > stuff)
> > > which we could and would like to support on GWT.
> > > Ideally, GWT support for this core would not require a different
> > > implementation, but I don't know yet if that's feasible at all.
> > > (Think about GL code, that you would like to use on the client *and*
> > > server)
> > >
> > > Some quick thoughts:
> > >
> > > - I wonder if we could stick to the EventList interface and use a no-op
> > > LockAdapter for GWT
> > >
> > > - how to support property change events? (using GWTx perhaps)
> > >
> > > - how to support/deal with reflection?
> > >
> > > - what other API problems did you encounter?
> > >
> > > If you would like to share more details with us, that would be great.
> > >
> > > Thanks,
> > > Holger
> > >
> > >>
> > >> Hey guys,
> > >>
> > >> I've put together a branch of GL which runs on GWT.  I reduced the
> > >> functionality quite a bit to the things that i think are applicable to
> > >> the
> > >> GWT environment (and what i needed there).
> > >>
> > >> A few examples, of the changes i made:
> > >> Definitely good:
> > >> 1. Removed all locking, and thread management code.  JS is single
> > >> threaded.
> > >> 2. Altered any use of unsupported jdk APIs to ones that work in GWT
> > >> 3. Removed unnecessary swing/swt/networking code which wouldn't build
> in
> > >> gwt
> > >>
> > >> Arguably not-so-good:
> > >> 1. I removed more than i really needed to.  Some features could be
> made
> > >> to
> > >> work that i removed just to thin out the package.  These could be put
> > >> back
> > >> in without too much cost since GWT is good at only including what you
> > >> really
> > >> need at runtime.
> > >> 2. I renamed a few things that i really didn't need to, this would be
> > >> easy
> > >> to changed back.  Basically i renamed EventList to GlazedList.
> > >> 3. I'm in the process of removing duplication in the GL library with
> the
> > >> Google-collections-GWT library, using the google versions to avoid
> having
> > >> two in my applications.  At a glance i think this should include
> moving
> > >> Matcher to Predicate, and utilizing their multimap implmentation in
> place
> > >> of
> > >> the GL one.
> > >>
> > >> My version is definitely incomplete, for instance i did not
> reimplement
> > >> the
> > >> equivalent swing table adapters for the gwt ones.  My project is using
> > >> GXT
> > >> and so i built adapters to that (with a dependancy on my framework).
> > >>
> > >> I read the original note from Jesse on the subject of GWT, where he
> > >> mentioned that GL can only really work well in an env where the whole
> > >> list
> > >> is in memory.  And while i agree with much of the premise of that, i'd
> > >> argue
> > >> that JS environments are really much more constrained by how much can
> be
> > >> rendered to DOM than by how many objects and data can be kept in
> memory.
> > >> The fundamentals of what GL offers, really can make a big difference
> when
> > >> developing any UI, even JavaScript ones.
> > >>
> > >> I'm really interested in some of the additional comments about how GL
> > >> often
> > >> trades off memory for speed, and any suggestions of where we could
> > >> perhaps
> > >> provide alternate implementations with different/configurable
> tradeoffs.
> > >>
> > >> Thanks again for GL, its really a very smart tool.
> > >>
> > >> tom.
> > >> --
> > >> View this message in context:
> > >> http://www.nabble.com/GlazedList-GWT-tp23002550p23002550.html
> > >> Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [e-mail]
> > >> For additional commands, e-mail: [e-mail]
> > >>
> > >>
> > >
> > >
> > >
> __________________________________________________________________________
> > > Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und
> viele
> > > ausländische Netze zum gleichen Preis!
> > > https://produkte.web.de/webde_sms/sms
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [e-mail]
> > > For additional commands, e-mail: [e-mail]
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/GlazedList-GWT-tp23002550p23039520.html
> > Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [e-mail]
> > For additional commands, e-mail: [e-mail]
> >
> >
>
>
> ____________________________________________________________________
> Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
> Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>