Re: WO5.4 and Java Client

[Paolo Sommaruga]

Hi Jaroslav,

I have finished to develop a first version of my framework and now I'm  
doing some test. It seems to work. Also I'm writing some examples with  
a little doc. Later on I will do it available and I will send you


Regards

Paolo


Il giorno 14/nov/07, alle ore 19:05, Jaroslav Hanus ha scritto:


Hello Paolo

Could you please give me some more info concerning your data-GUI XML  
binding approach? It seems to fit perfectly into our idea where to  
move now with JC stuff. Although Florian's way is also nice and I  
have found interesting info in his tutorial, this GUI - data  
separation I would prefer. And if you have already made some  
progress in this field, I would prefer to collaborate than to  
reinvent the wheel ;)


Regards

Jaroslav


On Nov 8, 2007, at 9:13 PM, [EMAIL PROTECTED]  
wrote:



Hi Florijan,

it's because the core jc stuff still stays that I think It's  
reasonable to continue to use in the jc application EODisplayGroup,  
EOAssociation, etc. I think the status is like as the web WO where  
the core stuff stays but WebObjects Builder is lacking. In the jc  
client development the core stuff largely stays but now Interface  
Builder is lacking. Doubtless in my xml binding approach, to edit  
by hands a xml file is'nt fun as to play with Interface Builder but  
it's much better that to hardcode in the gui java class all the  
EODisplayGroup, EOAssociation code. The gui java class remain a  
pure swing class, the needed EODisplayGroup, EOAssociation, etc.  
stuff are "automagically" added following the binding described in  
the xml file. One have to extends the gui class as EOApplication  
but this requiremet is just only to start the application, in order  
to do the applicationClassName binding in JavaClient.wo working, as  
you has described in your WebObjects Java Client tutorial.  
Furthermore, in the future one can creates a visually tool, an  
eclipse plugin or other, which can generate the xml file


Regards

Paolo




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


 ___
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]

Re: WO5.4 and Java Client

[Jaroslav Hanus]

Hello Paolo

Could you please give me some more info concerning your data-GUI XML  
binding approach? It seems to fit perfectly into our idea where to  
move now with JC stuff. Although Florian's way is also nice and I  
have found interesting info in his tutorial, this GUI - data  
separation I would prefer. And if you have already made some progress  
in this field, I would prefer to collaborate than to reinvent the  
wheel ;)


Regards

Jaroslav


On Nov 8, 2007, at 9:13 PM, [EMAIL PROTECTED]  
wrote:



Hi Florijan,

it's because the core jc stuff still stays that I think It's  
reasonable to continue to use in the jc application EODisplayGroup,  
EOAssociation, etc. I think the status is like as the web WO where  
the core stuff stays but WebObjects Builder is lacking. In the jc  
client development the core stuff largely stays but now Interface  
Builder is lacking. Doubtless in my xml binding approach, to edit  
by hands a xml file is'nt fun as to play with Interface Builder but  
it's much better that to hardcode in the gui java class all the  
EODisplayGroup, EOAssociation code. The gui java class remain a  
pure swing class, the needed EODisplayGroup, EOAssociation, etc.  
stuff are "automagically" added following the binding described in  
the xml file. One have to extends the gui class as EOApplication  
but this requiremet is just only to start the application, in order  
to do the applicationClassName binding in JavaClient.wo working, as  
you has described in your WebObjects Java Client tutorial.  
Furthermore, in the future one can creates a visually tool, an  
eclipse plugin or other, which can generate the xml file


Regards

Paolo



 ___
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]

Re: WO5.4 and Java Client

[Florijan Stamenkovic]

Paolo,

I see why you like a more dynamic approach. Dynamic is good, and it  
should not be very difficult to make a visual editor for your XML.


 Since I have never extensively used EOAssociation classes, and have  
after some initial work with it skipped Apple's JC stuff in total  
(except when used for data distribution) I do not have a very clear  
picture of what kind of results you are getting.


Anyway, once the library I am working on is done, it will be  
accompanied with tutorials, docs, and (hopefully) a demonstration app  
with source code, so you'll be able to see if you like that approach,  
and can use what's best for you.


My best,
Flor

On Nov 08, 2007, at 15:33, Paolo Sommaruga wrote:


Hi Florijan,

it's because the core jc stuff still stays that I think It's  
reasonable to continue to use in the jc application EODisplayGroup,  
EOAssociation, etc. I think the status is like as the web WO where  
the core stuff stays but WebObjects Builder is lacking. In the jc  
client development the core stuff largely stays but now Interface  
Builder is lacking. Doubtless in my xml binding approach, to edit  
by hands a xml file is'nt fun as to play with Interface Builder but  
it's much better that to hardcode in the gui java class all the  
EODisplayGroup, EOAssociation code. The gui java class remain a  
pure swing class, the needed EODisplayGroup, EOAssociation, etc.  
stuff are "automagically" added following the binding described in  
the xml file. One have to extends the gui class as EOApplication  
but this requiremet is just only to start the application, in order  
to do the applicationClassName binding in JavaClient.wo working, as  
you has described in your WebObjects Java Client tutorial.  
Furthermore, in the future one can creates a visually tool, an  
eclipse plugin or other, which can generate the xml file


Regards

Paolo

Il giorno 08/nov/07, alle ore 03:05, Florijan Stamenkovic ha scritto:

Thanks to all, and apologies as well, last time I checked (a few  
days ago) I was unable to locate the 5.4 API online, possibly to  
my own stupidity.


My best,
Flor

On Nov 07, 2007, at 14:09, Mike Schrag wrote:

Could we stop the speculation and look at the facts. The  
documentation is here:
http://developer.apple.com/documentation/MacOSXServer/Reference/ 
WO54_Reference/

.. and also
http://developer.apple.com/documentation/MacOSXServer/Reference/ 
WO54_Reference/deprecated-list.html


ms

___
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/flor385% 
40mac.com


This 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/psomma% 
40jpaso.com


This email sent to [EMAIL PROTECTED]

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





___
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]

Re: WO5.4 and Java Client

[Anjo Krank]

Argh, I shouldn't have relied on my memory.

What I meant was the WebServicesAssistant.app, which is only a WOA  
that is repackaged as an app. Sorry. But then I don't know why D2JC  
is deprecated at all, except that all the cocoa components are most  
likely broken and they didn't want to provide an IB replacement or  
conversion tool.


Cheers, Anjo

Am 08.11.2007 um 20:22 schrieb David Avendasora:


Hey Anjo,

Can you give me more information or examples of getting assistant  
to use normal WO files? That would help me a lot right now. I would  
also very much like to try to get D2JC unDEpreciated even if it  
does remain unAppreciated. :)


Thanks,

Dave

On Nov 4, 2007, at 2:56 PM, Anjo Krank wrote:



Am 01.11.2007 um 20:33 schrieb David Avendasora:

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.


Again: D2JC is deprecated, but wrongly so. If you know how to  
write individual components by hand, then you should file a radar  
to get the assistant to use normal WO files and not the D2JC stub  
(sth you can easily do yourself). Also again: I have no idea if  
the JC stuff will be brought forward or not, but at least you  
don't *need* to rewrite your interfaces.


Cheers, Anjo







___
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]

Re: WO5.4 and Java Client

[Paolo Sommaruga]

Hi Florijan,

it's because the core jc stuff still stays that I think It's  
reasonable to continue to use in the jc application EODisplayGroup,  
EOAssociation, etc. I think the status is like as the web WO where the  
core stuff stays but WebObjects Builder is lacking. In the jc client  
development the core stuff largely stays but now Interface Builder is  
lacking. Doubtless in my xml binding approach, to edit by hands a xml  
file is'nt fun as to play with Interface Builder but it's much better  
that to hardcode in the gui java class all the EODisplayGroup,  
EOAssociation code. The gui java class remain a pure swing class, the  
needed EODisplayGroup, EOAssociation, etc. stuff are "automagically"  
added following the binding described in the xml file. One have to  
extends the gui class as EOApplication but this requiremet is just  
only to start the application, in order to do the applicationClassName  
binding in JavaClient.wo working, as you has described in your  
WebObjects Java Client tutorial. Furthermore, in the future one can  
creates a visually tool, an eclipse plugin or other, which can  
generate the xml file


Regards

Paolo

Il giorno 08/nov/07, alle ore 03:05, Florijan Stamenkovic ha scritto:

Thanks to all, and apologies as well, last time I checked (a few  
days ago) I was unable to locate the 5.4 API online, possibly to my  
own stupidity.


My best,
Flor

On Nov 07, 2007, at 14:09, Mike Schrag wrote:

Could we stop the speculation and look at the facts. The  
documentation is here:

http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/

.. and also
http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/deprecated-list.html

ms

___
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/flor385%40mac.com

This 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/psomma%40jpaso.com

This email sent to [EMAIL PROTECTED]

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



 ___
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]

Re: WO5.4 and Java Client

[David Avendasora]

Hey Anjo,

Can you give me more information or examples of getting assistant to  
use normal WO files? That would help me a lot right now. I would also  
very much like to try to get D2JC unDEpreciated even if it does  
remain unAppreciated. :)


Thanks,

Dave

On Nov 4, 2007, at 2:56 PM, Anjo Krank wrote:



Am 01.11.2007 um 20:33 schrieb David Avendasora:

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.


Again: D2JC is deprecated, but wrongly so. If you know how to write  
individual components by hand, then you should file a radar to get  
the assistant to use normal WO files and not the D2JC stub (sth you  
can easily do yourself). Also again: I have no idea if the JC stuff  
will be brought forward or not, but at least you don't *need* to  
rewrite your interfaces.


Cheers, Anjo





___
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]

Re: WO5.4 and Java Client

[Florijan Stamenkovic]

Thanks to all, and apologies as well, last time I checked (a few days  
ago) I was unable to locate the 5.4 API online, possibly to my own  
stupidity.


My best,
Flor

On Nov 07, 2007, at 14:09, Mike Schrag wrote:

Could we stop the speculation and look at the facts. The  
documentation is here:
http://developer.apple.com/documentation/MacOSXServer/Reference/ 
WO54_Reference/

.. and also
http://developer.apple.com/documentation/MacOSXServer/Reference/ 
WO54_Reference/deprecated-list.html


ms

___
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/flor385% 
40mac.com


This 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]

Re: WO5.4 and Java Client

[Mike Schrag]

Could we stop the speculation and look at the facts. The  
documentation is here:

http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/

.. and also
http://developer.apple.com/documentation/MacOSXServer/Reference/WO54_Reference/deprecated-list.html

ms

___
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]

Re: WO5.4 and Java Client

[David LeBer]

On 7-Nov-07, at 12:32 PM, 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.


;david

--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site:   http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org


___
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]

Re: WO5.4 and Java Client

[Mr. Pierre Frisch]

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 PROTECTED]


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 PROTECTED]


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:


* 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?).



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 t

Re: WO5.4 and Java Client

[Florijan Stamenkovic]

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 PROTECTED]


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:


* 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?).



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 ther

Re: WO5.4 and Java Client

[Mr. Pierre Frisch]

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 PROTECTED]


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:


* 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?).



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 straigh

Re: WO5.4 and Java Client

[Florijan Stamenkovic]

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:


* 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?).



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 suppo

Re: WO5.4 and Java Client

[Paolo Sommaruga]

sorry, I forgot Interface Builder ...

Il giorno 05/nov/07, alle ore 16:57, Paolo Sommaruga ha scritto:


Hi,

we are in production some nib based jcs. Such jcs are complex  
enough. Therefore in order to migrate in a world without


Interface Builder

 we need to use the existing code as much as possible in order to  
avoid altering the entire applications. Besides a great deal of  
Apple jc stuff works well even though it is poor in terms of  
documentation. So we’d better cling to Apple frameworks, where we  
can, rather than reinvent the whole wheel.


My approach was  the following: I created gui with jigloo,
http://www.cloudgarden.com an eclipse gui builder plugin, and for  
every existing interface class of the jc I replaced the nib file  
with a xml  file which describes the  bindings between the view  
objects (buttons, tables, text fields, etc) and the model objects  
(EODisplayGroup, EOAssociation, etc.).

They are the same bindings which had been created with Interface
Builder. Such model objects are automatically generated in a clear  
way for the developer by some class in our framework. Thus I started  
to make some applications migrate to eclipse-wolips-jigloo-xml  
binding WO5.3 in tiger and that seems to work even with WO5.4.


The only problem  at the moment is that with leopard jigloo is  
broken in eclipse 3.3.1 but I hope that its  author can resolve the  
issue.


When I finish I’ll be able to send the framework to those who may be  
interested in


Regards

Paolo Sommaruga


Il giorno 04/nov/07, alle ore 20:56, Anjo Krank ha scritto:



Am 01.11.2007 um 20:33 schrieb David Avendasora:

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.


Again: D2JC is deprecated, but wrongly so. If you know how to write  
individual components by hand, then you should file a radar to get  
the assistant to use normal WO files and not the D2JC stub (sth you  
can easily do yourself). Also again: I have no idea if the JC stuff  
will be brought forward or not, but at least you don't *need* to  
rewrite your interfaces.


Cheers, Anjo

___
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/psomma%40jpaso.com

This email sent to [EMAIL PROTECTED]

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. ___
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/psomma%40jpaso.com

This 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]

Re: WO5.4 and Java Client

[Paolo Sommaruga]

Hi,

we are in production some nib based jcs. Such jcs are complex enough.  
Therefore in order to migrate in a world without  we need to use the  
existing code as much as possible in order to avoid altering the  
entire applications. Besides a great deal of Apple jc stuff works well  
even though it is poor in terms of documentation. So we’d better cling  
to Apple frameworks, where we can, rather than reinvent the whole wheel.


My approach was  the following: I created gui with jigloo,
http://www.cloudgarden.com an eclipse gui builder plugin, and for  
every existing interface class of the jc I replaced the nib file with  
a xml  file which describes the  bindings between the view objects  
(buttons, tables, text fields, etc) and the model objects  
(EODisplayGroup, EOAssociation, etc.).

They are the same bindings which had been created with Interface
Builder. Such model objects are automatically generated in a clear way  
for the developer by some class in our framework. Thus I started to  
make some applications migrate to eclipse-wolips-jigloo-xml binding  
WO5.3 in tiger and that seems to work even with WO5.4.


The only problem  at the moment is that with leopard jigloo is broken  
in eclipse 3.3.1 but I hope that its  author can resolve the issue.


When I finish I’ll be able to send the framework to those who may be  
interested in


Regards

Paolo Sommaruga


Il giorno 04/nov/07, alle ore 20:56, Anjo Krank ha scritto:



Am 01.11.2007 um 20:33 schrieb David Avendasora:

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.


Again: D2JC is deprecated, but wrongly so. If you know how to write  
individual components by hand, then you should file a radar to get  
the assistant to use normal WO files and not the D2JC stub (sth you  
can easily do yourself). Also again: I have no idea if the JC stuff  
will be brought forward or not, but at least you don't *need* to  
rewrite your interfaces.


Cheers, Anjo

___
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/psomma%40jpaso.com

This email sent to [EMAIL PROTECTED]

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



 ___
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]

Re: WO5.4 and Java Client

[Anjo Krank]

Am 01.11.2007 um 20:33 schrieb David Avendasora:

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.


Again: D2JC is deprecated, but wrongly so. If you know how to write  
individual components by hand, then you should file a radar to get  
the assistant to use normal WO files and not the D2JC stub (sth you  
can easily do yourself). Also again: I have no idea if the JC stuff  
will be brought forward or not, but at least you don't *need* to  
rewrite your interfaces.


Cheers, Anjo

___
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]

Re: WO5.4 and Java Client

[Jarda Hanuš]

Mike Schrag stated in the "State of the Union" thread:


* 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?).



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!




Good point. We'll send some feedback and questions directly to Apple  
and hope we'll not be the only ones...


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?




AFAIK you're right, important are the libraries.

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




Thanks, and I definitively will read it.

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.


It would probably be good to make some more publicity to his page, if  
he's not against that? Maybe just to start with some editing of  
http://wiki.objectstyle.org/confluence/display/WO/Java+Client- 
Overview. Because I really tried to google out some more info about  
the JC future and about the 3rd way posibilities, and what I found  
was rather sad. Style "No Future" ;)


Last thing - in a review I have read, that there are at least about  
50 organizations, who use Java Client. So we are not many, but  
definitively not alone. Do you have some idea, how to get a bit more  
of the actual JC info/people together? Maybe to share info, maybe  
just do discuss the alternatives, maybe to send to Apple/WO community  
a message, that there are some people using it and that it's a viable  
solution?




Long live JC!

Dave



;)))

Jarda ___
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]

Re: WO5.4 and Java Client

[David Avendasora]

Mike Schrag stated in the "State of the Union" thread:


* 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?).



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 

Re: WO5.4 and Java Client

[Jarda Hanuš]

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  (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]

Re: WO5.4 and Java Client

[David Avendasora]

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



On Oct 31, 2007, at 8:53 AM, Anjo Krank wrote:

All I'm saying is that you can get D2JC to still work by fixing up  
the package to a plain WO app. However, my uneducated guess is that  
there won't be much development going on with the Java client stuff.


Cheers, Anjo

Am 31.10.2007 um 13:38 schrieb John Pollard:

I am not quite clear on what you are saying. I am not concerned  
about the Java interface for which we happen to use JFormDesigner  
at present. I really want to know whether the EOF / distribution  
jars are deprecated - the ones that let me write code on the  
client side, almost as if I were coding on the server side. Here  
is the list of jars that I currently load onto the client via jnlp:


___
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.com


This 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]

Re: WO5.4 and Java Client

[Anjo Krank]

All I'm saying is that you can get D2JC to still work by fixing up the  
package to a plain WO app. However, my uneducated guess is that there  
won't be much development going on with the Java client stuff.


Cheers, Anjo

Am 31.10.2007 um 13:38 schrieb John Pollard:

I am not quite clear on what you are saying. I am not concerned  
about the Java interface for which we happen to use JFormDesigner at  
present. I really want to know whether the EOF / distribution jars  
are deprecated - the ones that let me write code on the client side,  
almost as if I were coding on the server side. Here is the list of  
jars that I currently load onto the client via jnlp:


___
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]

Re: WO5.4 and Java Client

[John Pollard]

Hi Anjo,

I am not quite clear on what you are saying. I am not concerned about  
the Java interface for which we happen to use JFormDesigner at  
present. I really want to know whether the EOF / distribution jars  
are deprecated - the ones that let me write code on the client side,  
almost as if I were coding on the server side. Here is the list of  
jars that I currently load onto the client via jnlp:










We may not actually use / need all of these as we are not using the  
NIB system, but most are needed. I am not sure if some of these are  
actually the same jar as on the server side, but wojavaclient.jar is  
client only.


Thanks
John

On 31 Oct 2007, at 12:25, Anjo Krank wrote:

The D2JC stuff still works if you replace the binary in the  
assistant package with a normal WO launch script. IB is pretty much  
dead for WO dev, but you can code your own components or write some  
GUI editor for it (or reuse the stuff other editors create for you).


Cheers, Anjo

Am 31.10.2007 um 08:39 schrieb John Pollard:


Deprecations in WO5.4:

Java Client Nib based applications
Direct to JavaClient based applications

Does this mean the end of Java Client full stop? We use Java  
Client but NOT Nibs or Direct To. Our Java interface is pure swing.


What we do depend on is basically the distributed EOF  
functionality to cache the object graph on the client side for run- 
time efficiency and ease of programming in traversing the object  
graph and executing queries in client side code. Am I clutching at  
straws in hoping that core client side jars will live on even if  
Nib-based interfaces / direct to are on the way out (no problem  
for us)?


Thanks,
John


___
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/krank% 
40logicunited.com


This 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]

Re: WO5.4 and Java Client

[Anjo Krank]

The D2JC stuff still works if you replace the binary in the assistant  
package with a normal WO launch script. IB is pretty much dead for WO  
dev, but you can code your own components or write some GUI editor for  
it (or reuse the stuff other editors create for you).


Cheers, Anjo

Am 31.10.2007 um 08:39 schrieb John Pollard:


Deprecations in WO5.4:

Java Client Nib based applications
Direct to JavaClient based applications

Does this mean the end of Java Client full stop? We use Java Client  
but NOT Nibs or Direct To. Our Java interface is pure swing.


What we do depend on is basically the distributed EOF functionality  
to cache the object graph on the client side for run-time efficiency  
and ease of programming in traversing the object graph and executing  
queries in client side code. Am I clutching at straws in hoping that  
core client side jars will live on even if Nib-based interfaces /  
direct to are on the way out (no problem for us)?


Thanks,
John


___
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/krank%40logicunited.com

This 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]

WO5.4 and Java Client

[John Pollard]

Deprecations in WO5.4:

Java Client Nib based applications
Direct to JavaClient based applications

Does this mean the end of Java Client full stop? We use Java Client  
but NOT Nibs or Direct To. Our Java interface is pure swing.


What we do depend on is basically the distributed EOF functionality  
to cache the object graph on the client side for run-time efficiency  
and ease of programming in traversing the object graph and executing  
queries in client side code. Am I clutching at straws in hoping that  
core client side jars will live on even if Nib-based interfaces /  
direct to are on the way out (no problem for us)?


Thanks,
John


___
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]