Re: JavaClient Common classes
Re: JavaClient Common classes
- Subject: Re: JavaClient Common classes
- From: David Avendasora <email@hidden>
- Date: Wed, 25 Mar 2009 13:36:29 -0400
On Mar 25, 2009, at 12:46 PM, John Huss wrote:
This is mainly aimed at David, but anyone is welcome to share.
How are you using the common class functionality in WOLips? From
what I gather there is a common class for the each Entity and then
two subclasses (parallel), one for the Server and one for the
Client. Do you have three sets of templates then? Would you be
willing to share? I see the client templates on the wiki, but
nothing for the common ones.
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.
I think possibly the best strategy is to use the Client-Side classes
as the "common" classes, then extend them on the server side with
additional server-side-only functionality. I haven't done more than
just think about this.
Right now, I simply have two classes and if I have to have the same
method on both sides I manually keep them in sync, which is horrible
in concept, but only mildly painful in practice. Usually, if there is
complicated logic, I simply have the client invokeRemoteMethod on the
server-side do the heavy-lifting and then send the results back to the
client - what's great is that EOF manages all the EC stuff when you do
this copying your EC back to the server and syncing it up, then
sending it back to the client after. It really is seamless.
Then, on a different note: are you using Wonder on the client as
well? There isn't a jar in WebServerResources, but there's really
no reason why you couldn't use it is there?
Wonder is an insanely useful/powerful set of tools, but there is no
way to use it on the client without rewriting every class you may want
on the client. There are so many dependancies on parts of EOF
(EOControl for one) that are not available on the client that the one
time I tried (around WOWODC last year) I gave up in less than a day,
which Chuck can attest is very unusual, I'll beat my head against the
wall on something for weeks if I think there's any hope of making it
work. WOnder on the client isn't realistic.
With that said, the server-side half of my JC app _is_ a wonder
application using all the Wonder goodness.
Also, you should really look at what Florijan Stamenkovic has put
together with JBND (http://web.mac.com/flor385/JBND/). It is an
excellent jump-start on the whole non-direct java client development
process and handles numerous things that are specific to Java Client
development. I have yet to actually use it because I am doing Direct
to Java Client development, but I have plans to start using it for
part of my application.
Have you thought about adding project templates to WOLips for
JavaClient apps (server and client)?
That is on the list of things Mike Schrag has said he would do once I
could give him well-defined requirements, which I have yet to do.
On this note, you can architect your JavaClient project in Eclipse in
a couple diffferent ways. The way I do it is using Java WebStart so I
really only have one project for both sides of my application.
Florijan prefers to keep them as two separate projects in Eclipse and
he includes all the required client-side classes in the project
instead of relying on WebStart to grab them from the server-side app
upon launch.
Then on-top of that decision, is the decision of whether you are going
to go with Direct To Java Client (D2JC) or with non-Direct
development. D2JC is very similar to D2W but with a lot less
attention. There is an assistant that will help you write your rule
files and there's a lot you can do to extend D2JC without actually
writing any Swing.
I think D2JC is a great Create Read Update Delete (CRUD) tool and will
force you to get your model right up front. It's very unforgiving of
having delete-rules or ownership properties wrong in the model.
But if your app is going to be doing much more complicated logic and
is more task-based than data-based, I would plan to use non-Direct for
at least a portion of your project. But I'd start with D2JC just to
get started quickly.
Or a built-in library that would add all the standard
WebServerResources jars to the classpath like the "WebObjects
Frameworks" one does for the server?
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.
I'm still on the older WOLips, but are there any ant tasks for
JavaClient now too?
I am on the older WOLips as well, which is one of the reasons I
haven't gotten the project template requirements to Mike for
inclusion. I do have a javaclientbuild.xml file that I call with a
custom incremental builder that will build the client-side jar and
place it in the WebServerResources/Java directory and get your client-
side app launch when you run your project in Eclipse.
As far as the building for production side of things go, I have a
modified build.xml file that will work for non-hotness builds of
WOLips, and the New Hotness build of WOLips will do the Java Client
build thing for you.
Sorry, lots of questions. I'm exploring the possibility of using
JavaClient.
That's great to hear! Come on it the water is great, and not polluted
with all those other WO geeks doing (shudder) web/AJAX dev work.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden