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