Hi John, I did D2JC development for quite a while, but never got past using rules and frozen XML for the UI, but I did do quite a bit of business-logic type customizations and what code was on the client and what code was on the server. EOF is perfectly fine with a Server-side class being different from a Client-side class and it takes care of all the pushing data back and forth.
EODistribution handles this and really does quite a good job of keeping the client and server in sync, as long as you maintain a connection to the server. Using it on anything other than a local network I think will be a somewhat less than positive experience. It requires a continuously live connection. The client side has no means of fetching or persisting data other than by talking to the server-side EOF. All client-side editing contexts are basically child ECs of a server-side EC - which can cause some interesting double-awake-from-insertion calls. With that said, you *have* ECs on the client side and you have real EOs to work with, not some JS-equivalent. The benefits of this are HUGE. You simply call editingContext().saveChanges() on the client side and EOF takes care of all the work to push the data back to the server-side, synchronize your changes with what is now on the server, saving to the database and then pushing changes back to the client that the client might not yet have. I learned WO by developing a Java Client and a Web Client simultaneously talking to one server application, and I can tell you that the EOF client and server APIs for everything from EOControl up are pretty much identical. As you can see by the jars listed, there is no EOAccess or EOAdapter, and because of this you'll need to be careful what pieces of Wonder you use. There are LOTS of places in Wonder where it violates MVC, doing things like requiring "EOAccess" classes in "Foundation" classes. I brought this up to Anjo once, saying that it was a poor coding practice to violate MVC that way. My therapist says I might soon stop having the flashbacks. Maybe. His advice: Just add those .jars to your classpath and just be careful not to call any of the things that talk to EOAccess or EOAdaptor. Anyway, good luck! Java Client doesn't get the respect it deserves! Dave On Oct 11, 2013, at 4:37 AM, John Pollard <j...@pollardweb.com> wrote: > Has anyone used any Wonder frameworks in a Java Client application? > I have a long-standing JC app which uses Wonder on the server side, but not > on the client side; what if anything from Wonder might be useful on the > client? > > These are the WO jars the client uses at present: > > <jar href="JavaFoundation.jar" /> > <jar href="JavaEOControl.jar" /> > <jar href="JavaEOApplication.jar" /> > <jar href="JavaEOInterface.jar" /> > <jar href="JavaEOInterfaceSwing.jar" /> > <jar href="JavaEODistribution.jar" /> > > Many thanks, > John > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to webobje...@avendasora.com ————————————————————————————— WebObjects - so easy that even Dave Avendasora can do it!™ ————————————————————————————— David Avendasora Senior Software Abuser Nekesto, Inc. _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
