On Fri, Jan 6, 2012 at 3:18 PM, <[email protected]> wrote: > > I think extracting interfaces and place them in shared won't be the > problem. I'll do that for the next patch set. > I have some questions about that: > - Where is the best place to implement the factory methods? In a nested > factory in the interfaces? One big factory class with "createXXX" > methods?
I'd say one big factory with many createXXX. FYI, Wave has such an approach for "lightweight" collections: - Abstract factory: https://svn.apache.org/repos/asf/incubator/wave/trunk/src/org/waveprotocol/wave/model/util/CollectionFactory.java - "vm" implementation: https://svn.apache.org/repos/asf/incubator/wave/trunk/src/org/waveprotocol/wave/model/util/CollectionUtils.java - "client" implementation: https://svn.apache.org/repos/asf/incubator/wave/trunk/src/org/waveprotocol/wave/client/common/util/JsoCollectionFactory.java You use explicitly one factory implementation or the other, depending on context (I think their idea was that you'd use dependency-injection, so you always code against the CollectionFactory, and you somehow "initialize" or "configure" your app/unit-test to use one implementation or the other at one central place (for your app)); this is similar to using GWT.create() in client code vs. AutoBeanFactorySource/RequestFactorySource in "vm" code. Another approach would be to use super-source (have a look at the com.google.gwt.regexp module) to switch implementation of the factory (you'd then have a "concrete" factory for "vm" mode, with a super-source version for "client" mode). > - Is it possible to place the native code to create the instances used > by the factory in the shared package? Is that working in the Java only > part? As long as you don't *call* the native methods, it'd be OK. > - Shouldn't we move the isSupported() stuff to shared too and return > false if called on the server side? I'd rather return 'true' there, as you would then have an emulated version. IMO, isSupported() should be kept on "client", as I can't see anything that couldn't be coded for a JVM (whether that implementation is built-in GWT –as for the AutoBeanFactorySource/RequestFactorySource– or not) > - What to do if somebody calls the factory from server side, as we > currently have no emulated implementation? Throw an > UnsupportedOperationException? I depends how the factory is implemented: if it's an interface or abstract class then, well, there's just no "vm" implementation; otherwise we'd probably rather provide the "vm" version in GWT. John was suggesting (as I understood it) that we would provide the "vm" implementations ("probably using ByteBuffers") and use super-source to provide the "client" versions; that would allow for a 'static' factory rather than an abstract factory (actually, the only reason to use super-source in this case: see, Wave doesn't use super-source at all). I'd rather have an abstract factory though, in the exact same way Wave does it (with the exception of the packages, of course; they'd all be in the same module, with interfaces in "shared", JSOs in "client", and ByteBuffer-based implementations in "vm") -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
