« Return to Thread: GlazedList GWT
Re: GlazedList GWT
by Holger Brands
::
Rate this Message:
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@...
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@...
« Return to Thread: GlazedList GWT
| Free embeddable forum powered by Nabble | Forum Help |
