http://developer.apple.com/documentation/WebObjects/
DesktopApplications/index.html#//apple_ref/doc/uid/TP30001017
states that the nib files are translated directly to Swing by WO.
So it sounds to me like WO parses the nib file and determines how
to build the Swing interface. Since you aren't building a Cocoa UI,
I don't think the bridge is involved. But you aren't dependent upon
using IB to build your client interface anyway. It's just the Apple
way of doing it.
It's IB that translates the Cocoa UI objects into Java, not WO. IB
uses the Java-Cocoa bridge to do this. We are searching for
alternatives because our current applications depend on IB (which,
I'm fairly sure, does depend on the Java-Cocoa bridge).
I really don't know the future of areas where Java Client may not
depend on the Cocoa-Java bridge. And, if anyone does know they won't
be able to say so in a public forum. The only information I have, is
that which has been made public, or can be inferred from the public
statements.
On May 9, 2007, at 9:36 AM, David Avendasora wrote:
I can't find anywhere where anything talks about Direct-To or Non-
Direct Java Client being depreciated. But I can't find anything
that says otherwise either.
I don't believe that the Java-Cocoa bridge (which, if I understand
correctly, is what was depreciated and therefore all of the Apple
WO Dev tools that used it were too) is in anyway involved in WO
Java Client (Direct or otherwise) development or deployment.
Out-of-the-box D2JC apps Xcode builds are using a Swing interface,
not a Cocoa one that makes calls to underlying Java code. I am
somewhat unclear on the use of Interface Bulder for Non-Direct Java
Client as this page: http://developer.apple.com/documentation/
WebObjects/DesktopApplications/index.html#//apple_ref/doc/uid/
TP30001017 states that the nib files are translated directly to
Swing by WO. So it sounds to me like WO parses the nib file and
determines how to build the Swing interface. Since you aren't
building a Cocoa UI, I don't think the bridge is involved. But you
aren't dependent upon using IB to build your client interface
anyway. It's just the Apple way of doing it.
But, with all that said, note I said "quickly mock-up and
prototype". D2JC is a great tool to make sure my model is valid and
that the entities and relationships, delete-rules, and optionality
I thought were proper on paper, actually work in practice. If they
don't work (generate exceptions or are just "clunky"), I can make a
change to the EOModel, rebuild and have a new app based on the new
structure _literally_ within seconds without writing/rewriting/
refactoring ANY code. The only thing better than Eclipse's
refactoring tools, is not needing to refactor at all. Once I have
tested and proved the model, it makes web development so much
easier because I can simply concentrate on the logic and the UI.
I think that even if D2JC is dead from the perspective of making
deployable applications, it is an incredibly powerful prototyping/
proof-of-concept tool that will keep me using Xcode for the initial
stages of a project, until at least I can create a new D2JC project
in WOLips, point it at a EOModel and click build-and-go.
I just wish it weren't dead. (I know, wish in one hand...)
Dave
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
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]
