ce matin, la nouvelle màj de la docum XCode fait état du fait que pour
MacOS > 10.4 les nouvelles interfaces cocoa ne seraient plus disponibles
depuis java...
c'est une sorte de condamnation à mort de Cocoa-Java, amha, qu'en
pensez-vous ?
ceci est certainement du au passage à Intel où java est fourni par Sun
soi-même, ce qui n'est pas une mauvaise chose, vu qu'Apple a tjs trainé
des pieds.
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que
SwinX ???
--
une bévue
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers 10:47, (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple. -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers
10:47, une.bevueVOTEZ@NONfree.fr (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que
SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
--
/*
* Should be panic but... (Why are BSD people panic obsessed ??)
*/
2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers 10:47, (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple. -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
Vincent Bernat
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers 10:47, (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple. Mais je ne sais pas s'il marche avec autre chose que GNUStep. Fondamentalement, cela devrait fonctionner avec Cocoa. -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers
10:47, une.bevueVOTEZ@NONfree.fr (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que
SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par
exemple. Mais je ne sais pas s'il marche avec autre chose que
GNUStep. Fondamentalement, cela devrait fonctionner avec Cocoa.
--
/*
* Should be panic but... (Why are BSD people panic obsessed ??)
*/
2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
OoO En cette matinée pluvieuse du vendredi 08 juillet 2005, vers 10:47, (Une bévue) disait:
donc pour ceux qui souhaitent utiliser les libs java ils ne reste + que SwinX ???
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple. Mais je ne sais pas s'il marche avec autre chose que GNUStep. Fondamentalement, cela devrait fonctionner avec Cocoa. -- /* * Should be panic but... (Why are BSD people panic obsessed ??) */ 2.0.38 /usr/src/linux/net/ipv4/ip_fw.c
une.bevueVOTEZ
Vincent Bernat wrote:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
donc, effectivement JIGS est un concurrant de l'approche SwingX... mais pas de Cocoa-Java, moribond s'il a jamais été "vivant"... -- une bévue
Vincent Bernat <vince@khabale.org> wrote:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien
compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java
ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces
avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de
portage car GNUStep tourne sur pécé et *nix.
donc, effectivement JIGS est un concurrant de l'approche SwingX...
mais pas de Cocoa-Java, moribond s'il a jamais été "vivant"...
--
une bévue
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
donc, effectivement JIGS est un concurrant de l'approche SwingX... mais pas de Cocoa-Java, moribond s'il a jamais été "vivant"... -- une bévue
Vincent Bernat
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers 11:33, (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Java.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers
11:33, une.bevueVOTEZ@NONfree.fr (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien
compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui
- à la fois - est "inférieur" à Cocoa-Java en term d'interfaces
avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de
portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont
Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un
pont Objective-C <-> Java.
Ensuite, ce n'est pas magique, il faut générer les bindings
correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la
doc pour le faire fonctionner plus ou moins correctement avec
GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour
Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas
très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que
tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander
à l'auteur ce qu'il en pense.
--
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers 11:33, (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Java.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
Vincent Bernat
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers 11:33, (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Python.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers
11:33, une.bevueVOTEZ@NONfree.fr (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien
compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui
- à la fois - est "inférieur" à Cocoa-Java en term d'interfaces
avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de
portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont
Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un
pont Objective-C <-> Python.
Ensuite, ce n'est pas magique, il faut générer les bindings
correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la
doc pour le faire fonctionner plus ou moins correctement avec
GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour
Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas
très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que
tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander
à l'auteur ce qu'il en pense.
--
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du vendredi 08 juillet 2005, vers 11:33, (Une bévue) disait:
Ou un pont Objective C d'une tierce partie. Comme JIGS par exemple.
ah oui, merci, c'est très intéressant car en fait JIGS, si j'ai bien compris, n'est pas un pont cocoa<-->java mais GNUStep<-->java ce qui - à la fois - est "inférieur" à Cocoa-Java en term d'interfaces avancées (webkit pdfkit par ex) mais aussi "supérieur" en term de portage car GNUStep tourne sur pécé et *nix.
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Python.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense. -- Make sure special cases are truly special. - The Elements of Programming Style (Kernighan & Plauger)
une.bevueVOTEZ
Vincent Bernat wrote:
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Python.
oui, c'est ce qu'on m'a dit sur cocoa-dev le pont Obj-C<-->Python étant mieux fichu que le bridge java d'apple.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense.
ouais mais bon, l'intérêt, pour moi de java, est la portabilité + la persistence (j'utilise une bd-objet 100% java) donc, à quoi bon cocoa, pourquoi pas GNUstep dont cocoa dérive. j'imagine que porter du GNUStep(Obj-C)-Java est du même ordre de faciliter que SwingX-Java...
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de données 100 % java et oreintée objet (pas du tout du sql) et avec en zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb) donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la persistence orientée objet...
-- une bévue
Vincent Bernat <bernat@luffy.cx> wrote:
En fait, techniquement, je pense que c'est vraiment un pont
Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un
pont Objective-C <-> Python.
oui, c'est ce qu'on m'a dit sur cocoa-dev le pont Obj-C<-->Python étant
mieux fichu que le bridge java d'apple.
Ensuite, ce n'est pas magique, il faut générer les bindings
correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la
doc pour le faire fonctionner plus ou moins correctement avec
GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour
Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas
très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que
tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander
à l'auteur ce qu'il en pense.
ouais mais bon, l'intérêt, pour moi de java, est la portabilité + la
persistence (j'utilise une bd-objet 100% java) donc, à quoi bon cocoa,
pourquoi pas GNUstep dont cocoa dérive. j'imagine que porter du
GNUStep(Obj-C)-Java est du même ordre de faciliter que SwingX-Java...
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de
données 100 % java et oreintée objet (pas du tout du sql) et avec en
zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb)
donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la
persistence orientée objet...
En fait, techniquement, je pense que c'est vraiment un pont Objective-C <-> Java. Dans le même genre, il y a PyObjC qui est un pont Objective-C <-> Python.
oui, c'est ce qu'on m'a dit sur cocoa-dev le pont Obj-C<-->Python étant mieux fichu que le bridge java d'apple.
Ensuite, ce n'est pas magique, il faut générer les bindings correctement. Dans le cas de PyObjC qui privilégie Cocoa, il y a de la doc pour le faire fonctionner plus ou moins correctement avec GNUStep. Il me semble donc techniquement faisable d'utiliser JIGS pour Cocoa, tu vas juste devoir générer les bindings (et GNUStep n'est pas très loin de Cocoa puisqu'ils essaient de suivre, mais c'est vrai que tu n'as ni webkit ni pdfkit). Cela vaut sans doute le coup de demander à l'auteur ce qu'il en pense.
ouais mais bon, l'intérêt, pour moi de java, est la portabilité + la persistence (j'utilise une bd-objet 100% java) donc, à quoi bon cocoa, pourquoi pas GNUstep dont cocoa dérive. j'imagine que porter du GNUStep(Obj-C)-Java est du même ordre de faciliter que SwingX-Java...
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de données 100 % java et oreintée objet (pas du tout du sql) et avec en zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb) donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la persistence orientée objet...
-- une bévue
lucsky
Une bévue wrote:
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de données 100 % java et oreintée objet (pas du tout du sql) et avec en zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb) donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la persistence orientée objet...
Tu veux dire un truc genre CoreData ? :)
-- Luc Heinrich -
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de
données 100 % java et oreintée objet (pas du tout du sql) et avec en
zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb)
donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la
persistence orientée objet...
Aujourd'hui; mon plus grand intérêt pour java est db4o une base de données 100 % java et oreintée objet (pas du tout du sql) et avec en zéro-déploiement (pas d'admin comme sur Postgres ou mysql ou hsqldb) donc, si je trouve l'équivalent en Obj-C, càd une "class" pour la persistence orientée objet...
Tu veux dire un truc genre CoreData ? :)
-- Luc Heinrich -
une.bevueVOTEZ
Luc Heinrich wrote:
Tu veux dire un truc genre CoreData ? :)
p'tet je ne connais pas "Core Data" je suis en train de m'informer dessus...
en tk en java avec db4o pour stocker des objets :
- 1 - je définis l'objet en question, par ex :
public class Bottle { String description; Integer vintage; Integer apogee; public Bottle() {} les setters et getters, toString() (pour le debugg) et éventuellement les comparateurs }
ensuite grosso modo pour stocker un de ses objets, je fais :
je crée un obj : Bottle champ = new Bottle(); champ.setDescription("Perle Rosée"); ...
je le stocke : ObjectContainer db = null; try { db = Db4o.openFile("path/to/fichier.yap"); db.set(champ); db.commit(); db.close(); } finally { if (db != null) db.close(); }
pour retrouver tous les objets "Bottle" :
Bottle bottle = new Bottle(); ObjectSet os = db.get(bottle);
même genre pour update et delete...
la difficulté est reportée au niveau des search...
-- une bévue
Luc Heinrich <lucsky@mac.com> wrote:
Tu veux dire un truc genre CoreData ? :)
p'tet je ne connais pas "Core Data" je suis en train de m'informer
dessus...
en tk en java avec db4o pour stocker des objets :
- 1 - je définis l'objet en question, par ex :
public class Bottle {
String description;
Integer vintage;
Integer apogee;
public Bottle() {}
les setters et getters, toString() (pour le debugg) et éventuellement
les comparateurs
}
ensuite grosso modo pour stocker un de ses objets, je fais :
je crée un obj :
Bottle champ = new Bottle();
champ.setDescription("Perle Rosée");
...
je le stocke :
ObjectContainer db = null;
try {
db = Db4o.openFile("path/to/fichier.yap");
db.set(champ);
db.commit();
db.close();
} finally {
if (db != null)
db.close();
}
pour retrouver tous les objets "Bottle" :
Bottle bottle = new Bottle();
ObjectSet os = db.get(bottle);
même genre pour update et delete...
la difficulté est reportée au niveau des search...
p'tet je ne connais pas "Core Data" je suis en train de m'informer dessus...
en tk en java avec db4o pour stocker des objets :
- 1 - je définis l'objet en question, par ex :
public class Bottle { String description; Integer vintage; Integer apogee; public Bottle() {} les setters et getters, toString() (pour le debugg) et éventuellement les comparateurs }
ensuite grosso modo pour stocker un de ses objets, je fais :
je crée un obj : Bottle champ = new Bottle(); champ.setDescription("Perle Rosée"); ...
je le stocke : ObjectContainer db = null; try { db = Db4o.openFile("path/to/fichier.yap"); db.set(champ); db.commit(); db.close(); } finally { if (db != null) db.close(); }
pour retrouver tous les objets "Bottle" :
Bottle bottle = new Bottle(); ObjectSet os = db.get(bottle);
même genre pour update et delete...
la difficulté est reportée au niveau des search...
-- une bévue
lucsky
Une bévue wrote:
p'tet je ne connais pas "Core Data" je suis en train de m'informer dessus...
Tu fais bien. CoreData offre un tas d'autre choses en plus de la simple persistence d'objets, et en plus tu as le choix entre 3 différents types de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html>
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
-- Luc Heinrich -
Une bévue <une.bevueVOTEZ@NONfree.fr> wrote:
p'tet je ne connais pas "Core Data" je suis en train de m'informer
dessus...
Tu fais bien. CoreData offre un tas d'autre choses en plus de la simple
persistence d'objets, et en plus tu as le choix entre 3 différents types
de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html>
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
p'tet je ne connais pas "Core Data" je suis en train de m'informer dessus...
Tu fais bien. CoreData offre un tas d'autre choses en plus de la simple persistence d'objets, et en plus tu as le choix entre 3 différents types de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html>
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
-- Luc Heinrich -
une.bevueVOTEZ
Luc Heinrich wrote:
persistence d'objets, et en plus tu as le choix entre 3 différents types de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html> c'est la page ouverte dans moz..
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
Tiger only, n'est plus un inconvénient pour moi. Parce qu'avec CoreData je peux sauver mes objets dans un/des fichier/s xml lesquels sont lisibles depuis une appli GNUStep/Obj-C sur une autre bécanne. je gère le X-plateforme autrement et, avantage pour moi qui roule sur Mac OS X, j'ai la version la + performante, au lieu qu'avec [SwingX|Cocoa]-Java j'ai la moins performante, question vitesse...
reste + qu'à se mettre à Obj-C ... -- une bévue
Luc Heinrich <lucsky@mac.com> wrote:
persistence d'objets, et en plus tu as le choix entre 3 différents types
de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html>
c'est la page ouverte dans moz..
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
Tiger only, n'est plus un inconvénient pour moi. Parce qu'avec CoreData
je peux sauver mes objets dans un/des fichier/s xml lesquels sont
lisibles depuis une appli GNUStep/Obj-C sur une autre bécanne.
je gère le X-plateforme autrement et, avantage pour moi qui roule sur
Mac OS X, j'ai la version la + performante, au lieu qu'avec
[SwingX|Cocoa]-Java j'ai la moins performante, question vitesse...
persistence d'objets, et en plus tu as le choix entre 3 différents types de back-ends: XML, SQLite ou archive binaire.
<http://developer.apple.com/macosx/coredata.html> c'est la page ouverte dans moz..
Inconvénient majeur (ou pas, c'est selon): c'est Tiger only.
Tiger only, n'est plus un inconvénient pour moi. Parce qu'avec CoreData je peux sauver mes objets dans un/des fichier/s xml lesquels sont lisibles depuis une appli GNUStep/Obj-C sur une autre bécanne. je gère le X-plateforme autrement et, avantage pour moi qui roule sur Mac OS X, j'ai la version la + performante, au lieu qu'avec [SwingX|Cocoa]-Java j'ai la moins performante, question vitesse...
