Mike Schrag stated in the "State of the Union" thread:
<quote>* My understanding is that JavaClient stuff is technically still there, but there's not very good tool support for it. NetBeans project file support for Entity Modeler would allow the combination of Entity Modeler plus the Swing designer tools from NetBeans, which would probably be a good platform to start from for that (Swing builders in Eclipse I think mostly suck still?).
</quote>If anyone outside of Apple could know what the true _current_ state of WO is under the hood, it would be Mike - note, I'm not saying he _does_, just than if anyone could, it would him). He also seems to have a pretty good understanding of the tools for some reason... :) I don't think anyone, even at Apple, knows what is _going_ to happen to the JC libraries that haven't been depreciated. I think that it may take hearing from the development community as to what they use and want to determine it's future. Please don't be quiet!
I don't know if the new javaEOGenerator supports Java Client classes or not, I haven't had a chance to look yet, but with the tool soon-to- be open-sourced, I'm sure it can be added if there are enough people needing it. Other than that, I don't think there's any other WO- specific tools required for doing a Swing/SWT/etc Client. Am I wrong?
As far as ways to continue JC development without D2JC and Nib-based options, please read Florijan Stamenkovic's turorial on how to setup Swing-only UIs: "WebObjects Java Client, the 3rd way" at http:// web.mac.com/flor385/eSwamp/software/wojc_tutorial.html
Building off this tutorial, he's been working on a WO Java client data-binding library that stands completely separate from D2JC and nib-based development. You can then put a Swing, SWT, or other UI on top of it using standard (Non WO-Specific) tools. If the JC libraries are still in WO, then this solution should be a big step to simplifying JC development without any relying on any depreciated technologies. Here's the basics of how far he's gotten so far:
1. Event firing EO class (com.havaso.util.eof.ClientEO class) Quite straightforward.2. EOFDataSource interface and implementations (the com.havaso.util.eof.data package) These are basically EO container classes, made to either store or proxy EOs, listen to their changes and provide event firing support of their own.
3. EOFBinding interface and three implementations (viewing, editing, adding) Classes that interact with EOFDataSource and / or binding groups (EOFAddGroup, EOFEditGroup) to provide EOF data to end objects that will consume it (for example user interface models and such). Deferred editing and adding included.
4 Support classes for the above:
a. KeyPathChangeMonitor - quite important, check JavaDoc for more info
b. ClientDataObject interface and implementations - used by bindings
to enable deferred adding and editing
c. ValidationHandler interface and basic implementations - used by
EOFBindings to handle invalid values
The stuff provided above should make it relatively easy to build concrete Swing, SWT and other client tech specific binding implementations, and thereafter to make filthy rich client apps quite reliably and simply.
I know I'm planning on digging into it soon because a large portion of my application is D2JC, which will need to be replaced.
He sent it out to a bunch of us JC people a few weeks ago, but hasn't gotten any feedback on it yet. He is currently Internet-challenged due to where he's living. I'll get his permission to send it out the library. Anybody who wants it, email me off-list.
Long live JC! Dave On Nov 1, 2007, at 12:54 PM, Jarda Hanuš wrote:
And I have EXACTLY the same question. We develop and maintain quite a huge application with two frontends - html WebObjects for extranet users and Java Client for intranet. For JC we used the NIB- Based IB development, although with quite a lot of hacks to force it to work the way we needed. Now we have about 50 interfaces to rebuild.And we have to decide, where to go from now on.- Whether try to continue the JC way, using the *distributed* wo libraries together with some third party GUI builder for Swing or SWT or even GWT interfaces (by the way - if you, Dave or John would give me just some few hints about the bindings of these libraries with pure Swing or SWT interfaces, I would greatly appreciate that). Personally I think that this would be a bit easier to code for the moment, but definitively we need to know what will happen with all these .distributed. libraries in the future.- or whether go the WO app server + Web Services + not_WO client (for example Flex) path. This seems to me a bit more complicated for the moment, as we would need to completely change the client side logic, and add the Web Services layer to the server. Also I have some little doubts about the performance of this solution. But it would free us from this *will it be or will it not be* (deprecated) dilemma, at least as long as the whole WO world is not deprecated ;)So, please, if somebody has an answer concerning the future of JC internal libraries, let us know!Thanks! JaroslavOkay, I have the same question as John and Flor, and I don't think it's been answered yet. For those of you NOT doing regular Java Client (I guess there a few ;) there have been THREE ways of doing WO JC development in the past:1) D2JC 2) NIB-Based using Interface Builder3) Straight Swing (not using NIBs, rules files, or any other cool, but depreciated tech)1 and 2 have be obviously depreciated, even if they can be tricked into working. That's not the question.The question is, is #3 still a viable option? Saying either 1 or 2 still work with some hacking only confuses the question. Are the libraries that maintains the editing contexts on the client side and their communication back to the server-side UNdepreciated, or is it included in the libraries depreciated as part of D2JC and Nib-Based JC?Does anyone have a definitive answer to this? (please don't invoke curses such as "AJAX" in your answer!)Thanks! Dave_______________________________________________ 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:http://lists.apple.com/mailman/options/webobjects-dev/webobjects% 40avendasora.comThis email sent to [EMAIL PROTECTED]
_______________________________________________ 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: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
