Re: GlazedList GWT

[Holger Brands]

Just for the record:
I'm +1 for providing GWT support under the "official Glazed Lists umbrella".
If that happens, I'm also +1 for aligning it with the current package structure.

Holger

>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 documentatio
> n, 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@....
> net
> > >>
> > >>
> > >
> > >
>
> > > __________________________________________________________________
> ________
> > > 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@...
>
>
>

____________________________________________________________________
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@...