On Mar 25, 2009, at 2:53 PM, John Huss wrote:
On Wed, Mar 25, 2009 at 12:36 PM, David Avendasora <[email protected]
> wrote:
I've tried several times to use common classes with one class that
both server and client inherit from, but I've never been able to get
it to work correctly. Mike was kind enough to add some features to
Entity Modeler to allow for defining the name of the common class
and such, but I ran into all sorts of problems with actually getting
an application to run.
Interesting. Having a common class seems to be recommended in the
WO documentation, so I would expect to work without much effort.
You must be new here. :-P
Just kidding. You'd think that, but every time I've tried I've met
with frustration and there's not many on the list with the knowledge
or experience to help. My last attempt was last year around WOWODC and
when I couldn't get it working I gave up and haven't looked back since.
It's entirely possible that I missed something fundamental (shut up
Chuck).
There is a wojavaclient.jar that has all the WO client-side
framework jars together in it that you can simply add to your client-
side classpath, but if you use other frameworks that have client-
side jars, you'll still have to manage them yourself.
Hmm, it didn't know that. It's the file here, right: /Library/
WebServer/Documents/WebObjects/Java/wojavaclient.jar. That jar is
rather large (10 mb). It looks like maybe everything is included
twice, once in extracted form and once in an embedded jar. The jar
I built with eclipse using the individual jars from
WebServerResources was half the size (5 mb).
I don't use it other than to reference in my build path because since
WOLips doesn't see the client-side jars in the frameworks on your
build path you get errors in Eclipse. When my app is deployed, it
copies the client-side jars out of the frameworks automatically.
Apart from the WOComponent classes like WOString, is it true that
pretty much all of WO can be used on the client except EOAccess?
Whoops. Yeah, I think I said EOControl, I meant EOAccess, which makes
sense from an MVC standpoint. I believe that pretty much everything
else from an EOF standpoint is available. But the context in which you
use it changes some.
You have an EditingContext on the client side, but it sometimes acts
like a nested EC to the server-side EC and sometimes like a regular EC.
If you call saveChanges on it, they go back to the server and then
back to the DB, but if you use invokeRemoteMethod, it will copy the EC
back to the server and sync-up with the server-side EC, but not save
unless you call saveChnages there.
In most cases if you understand how things work on the server, the
client is either the same or different in a way that makes sense, but
maybe isn't obvious.
I've learned WO by using D2JC so there are many things about EOF and
WO that I don't fully understand, but I've still been able to build a
complex ERP/Nutrition/Recall system with it.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
