Re: WO5.4 and Java Client
Re: WO5.4 and Java Client
- Subject: Re: WO5.4 and Java Client
- From: "Mr. Pierre Frisch" <email@hidden>
- Date: Wed, 7 Nov 2007 09:42:24 -0800
Could we stop the speculation and look at the facts. The documentation
is here:
http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/
Pierre
--
Pierre Frisch
email@hidden
On Nov 7, 2007, at 9:32, Florijan Stamenkovic wrote:
Hm, one might think that if a number of developers are wondering
about the same point, the release notes might be somewhat confusing.
And that the vendor (and it's respected representatives) might be
considered nice if they would politely clarify the point (an action
taking a total of 2 minutes), as opposed to ignoring it.
However, I do apologize for any shouting, which was, I am sure,
unnecessary.
So, could any one who has their hands on Leopard (I am lagging
behind), go through the WO5.4 API, and see if the class:
com.webobjects.eodistribution.EODistributionContext
has been marked as depreciated. It would seem that this is the
undeniable proof we need of Apple's plans with WO JC. I just hope
the documentation authors have not screwed up, but then again, heck,
it's only maybe 10 - 20 companies eagerly trying to understand what
in the world's name is happening...
My best,
Flor
On Nov 07, 2007, at 12:19, Mr. Pierre Frisch wrote:
I do not respond to shouts. Just look in the documentation. What is
deprecated is marked, it if is not marked it is not deprecated.
Pierre
--
Pierre Frisch
email@hidden
On Nov 7, 2007, at 7:37, Florijan Stamenkovic wrote:
Hi all,
Great to see some JC discussions going on :)
Uhm, here is my two cents. Let's all do whatever we can to get a
straight answer from Apple about the core JC being depreciated or
not. Cliff Tuel NOT being the WO Apple person on the list anymore,
I do not know whom can be directly contacted with this question.
Clff however suggested that bug reporting (http://bugreport.apple.com
) might be the right channel to get an answer through, by
indicating that the 5.4 release notice is not clear enough on the
point of JC. Next to that, if you know whom from Apple can be
directly approached about WO, please do it.
About the library I am working on, I can not make any promises as
of yet, our company needs to know if in the future the pure Swing
WO JC will be an option. If so, I will continue working on the (to
be open-source) library. The currently published version will
receive some major changes, but is a good base to comment or
contribute ideas to.
As for the people using D2JC and IB approaches... The library I am
working on is meant to allow very streamlined interface and basic
data process definitions (in that sense being similar to the IB's
visual programming approach), but completely Java oriented. My
point being, it *might* be possible, by people who understand and
use the D2JC and IB file conventions, to create a conversion
script/program, to convert your current apps to pure Swing + EOF
code. IF this will be desired, I can contribute to the Swing (EOF
bound) code generation part of it. Uhm, to me this kind of sounds
like more trouble then it's worth, but I'm not doing D2JC nor IB,
so I don't have a clear picture. The same *might* be applicable to
Paolo Sommaruga's approach, if he (they) would choose to switch to
pure Swing + EOF. I know this all sounds like an enormous amount
of work (and it is), but if WO JC is not doomed, I am willing and
committed to invest a whole lot into it.
Next, a question was raised about publicizing the "Java Client,
the 3rd way" tutorial I wrote, feel free to do whatever you like
with it, link to it, publish it on other sites or whatever. Let me
know however if you think something should be changed, added,
removed etc., I am very glad to help, though I am currently way to
busy to activate myself much over it.
So, my concluding point: let's just GET SOMEONE FROM APPLE TO TELL
US IF JC IS GOING DOWN TOTALLY. Before that, I doubt anyone is
willing to do much more then speculate.
My best,
Flor
On Nov 01, 2007, at 15:33, David Avendasora wrote:
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!
Jaroslav
Okay, 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 Builder
3) 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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