Re: Why has D2JC been deprecated?
Re: Why has D2JC been deprecated?
- Subject: Re: Why has D2JC been deprecated?
- From: David Avendasora <email@hidden>
- Date: Wed, 14 Nov 2007 15:11:01 -0500
On Nov 12, 2007, at 7:07 PM, Pierce T. Wetter III wrote:
On Nov 12, 2007, at 1:53 PM, Jean Pierre Malrieu wrote:
I am not using it, so my question is just for curiosity.
I thought that dynamic D2JC apps were not using nib files, and
that swing interfaces where created out of xml descriptions, or by
programmatically creating controllers.
Is there a technical reason for deprecating D2JC, or is it that
without the possibility of mixing with nib-based interfaces, D2JC
looses so much interest that maintaining it becomes more costly
than useful?
If the reason for deprecating D2JC is not technical, I find it a
little bit sad that all this amount of code (and there seems to be
quite a lot code for controllers, etc.) just disappears. I
understand that Apple does not want to maintain a tool that is not
widely used, and that will be even less used now that the
possiblity of mixing dynamic and nib based interface is gone. But
If xml-based D2JC can still be used, maybe the relevant parts of
the code could be made public?
Of course, if there is a purely technical reason for deprecating
D2JC (like the reason for deprecating WOBuilder), please forget my
last question.
Because while D2JC sounds good in theory, in practice D2JC
applications are a nightmare to maintain. You end up factoring your
code 3 days:
.common
.server
.client
On top of whatever splitting EOGenerator does for you.
A couple things.
Here lies a fundamental misunderstanding of _Direct To_ Java Client
(D2JC) and Java Client. If you have a D2JC application, the
likelihood is that there is very little code written and maintaining
one is much easier than a Web or pure Java Client application. Change
the model, _maybe_ tweak a couple things in the .d2wmodel file if you
have customized things that are specific to your model changes, and
deploy. Only once you get to the point of writing a lot of custom
logic do you risk breaking a D2JC app by modifying the model - and
business logic changes will almost always be in the server-side classes.
Usually model changes in a D2JC app will simply be reflected in the
UI the next time you run the application, you don't have to worry
about broken bindings or writing the code to get your new attribute
to show up, just open the assistant and add or remove the attribute.
This saves a HUGE amount of time during the prototyping and
validating the model stages. In a PURE D2JC app, you don't even need
to generate any java files. Just the .eomodel file and the .d2wmodel
files are all you need to have a fully-functional rich-client/server
application. That's IT.
Now, with both straight (non-direct) Java Client development, and
more advanced D2JC applications, you do have at least one or both
Server and/or Client classes (I've always felt the "common" abstract
class was overkill). A well-designed Java Client app should be pretty
straight-forward as to where any given code is. Business Logic is on
the Server Side, Most validation and UI-only functionality is on the
Client Side. You should not have any (or very little) code
duplication between the two sets of classes. Divide it the same way
you would for a Web-UI WebObjects project. If it is something that
the browser would be going to do (javascript/AJAX type stuff) then it
goes in the client-class. Everything else goes in the server class.
You want to a text field based on what item they pick from a popup?
Easy, that's client-side and about 3 lines of plain-old Java.
I am working on a project now that the Admin side of the application
is a D2JC app that allows the user to go in and modify all the
Entities directly (without writing any code), and a Web UI that is
for the normal users. They both share the same server-side code in a
framework. This framework contains all the business logic and is
therefor available to both UIs. The D2JC UI only has the client-side
classes in it. The WebUI only has the Components in it. Two
completely different UIs to the same core business logic and
database. To me this, on top of EOF, is what makes WebObjects so
incredible. You can put any number of UIs on the front of the
business-logic framework. JC, D2JC, Web, WebService, etc. WO worries
about all the DB and session stuff, and you just worry about business-
logic.
Now with all that said, JC is much more difficult to debug because
you do have classes running in two places, and the client-side will
only report back that a specific error occurred on the server and
writes it to the console of the client. On top of this it doesn't
send back the stack-trace, so you are left to more creative debugging
methods, but you get used to it pretty quickly.
Now, as far as the question of "Why was D2JC Depreciated?", I have no
idea. The only thing I can think of is that you _can_ integrage NIBs
and such into a D2JC application, and those were depreciated, so
maybe it was just easier to depreciate D2JC along with NIB-based
development as they are entwined. I for one am going to complain
about D2JC being depreciated as it is entirely possible to run a very
powerful D2JC app without using NIB-based development. THere are no
special tools, other than the rules-editor, which is also used for
D2Web development and has been replaced anyway. Otherwise D2JC is
simply a set of libraries.
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