On Mar 25, 2009, at 15:02, 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.
I *believe* this comes from the old WO documentation, which is not
taking custom EO generation (Rubicode EOGen, Velocity nowadays) into
account. Since the "new" EO generation is nowadays the de-facto
standard, it means that what you read in the old docs is in fact
incorrect.
Please take into account that "I believe" this. I don't know which
docs you are referring to. Nor the technique.
Conceptually, I remember I was thinking about this a while back, and
came to the conclusion that with my setup (which insists on JBND aware
client side EO classes) this is impossible. But, I'd be happy to be
proven wrong on this issue.
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).
Never used the jar you refer to. The sum of the EOF client side libs I
use is 2.5 MB.
Apart from the WOComponent classes like WOString, is it true that
pretty much all of WO can be used on the client except EOAccess?
Not true. Many things are substantially different. Note that even
though you use classes that have the same interface (exported API),
they are in fact different implementations. Things that are different?
Parent store control. EOAccess is not there. Class descriptions are,
but different ones. Other programatic EOModel representation is mostly
not there, sometimes it is but different. Exceptions thrown by classes
at some points are different. Parts of EOControl are different. Some
things simply don't work the way one would expect... There is a lot to
take into account. Thread carefully. Still, don't be frightened. It's
still the best thing out there for this sort of work.
My best,
F
_______________________________________________
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]
