Document-based ou pas ?

BornToBeCocoaBornToBeCocoa Membre
18:17 modifié dans API AppKit #1
Hello,

Comme tout bon débutant, j'essaie de créer une petite appli pour gérer ma bibliothèque (mais cela aurait aussi bien pu être mes comptes).

Telle que je l'imagine, ma bibliothèque a 3 niveaux (voir dessin) :
- l'application sera la bibliothèque (AppController.m)
- les livres seront des objets de la bibliothèque (Book.m)
- les extraits seront des objets d'un livre (Extract.m)

Je ne souhaite pas que chaque livre soit un document indépendant, c'est-à -dire que lorsque je vais sauvegarder ma bibliothèque, je ne veux pas un fichier pour chaque livre mais un gros fichier qui contiendra les livres et les extraits.

A priori mon projet ne devrait donc pas être Document-based.

:why?: Mon problème est le suivant :
- si je fait un Doc-based, je peux créer des livres, les enregistrer, les récupérer... super mais il y a plusieurs fichiers et c'est ce que je ne veux pas.
- si je ne fait pas un Doc-based, ça marche plus. Impossible de sauver ou de récuperer. J'ai pourtant implémenté initWithCoder / encodeWithCoder dans l'objet livre et dataRepresentationOfType / fileWrapperRepresentationOfType dans l'objet bibliothèque mais on dirait que ça n'écrit pas et que ça ne charge pas.

est-il possible de le faire sans passer par Document-based ?

[Fichier joint supprimé par l'administrateur]

Réponses

  • 18:17 modifié #2
    J'aurais tendance à  dire Document Based, mais en prenant comme "document" la bibliothèque et non le livre, quitte à  ce qu'on ouvre toujours le même document (comme ça par exemple ceux qui veulent gérer une bibliothèque loisirs, et une "études" par exemple peuvent ne pas mélanger les deux).

    Par contre si tu ne fais pas document based, il y a tout à  fait moyen de sauver ou récupérer. Tu dois "simplement" remettre en place manuellement les facilités offertes par NSDocument.
  • Eddy58Eddy58 Membre
    18:17 modifié #3
    Une document based appli serait pas mal dans ton cas, mais utilise plutot ces méthodes-ci, très pratiques dans le cas d'une appli "classique", et de plus tu utilises le protocole NSCoding dans tes classes :

    Récupérer tes données :
    NSMutableArray *array=NSMutableArray alloc] initWithArray:[NSUnarchiver unarchiveObjectWithFile:@"CheminFichier";

    Enregistrer tes données :
    [NSArchiver archiveRootObject:array toFile:@CheminFichier];

    OK ? :)
  • BornToBeCocoaBornToBeCocoa Membre
    18:17 modifié #4
    Merci à  vous deux. 

    Après ces conseils et après avoir butiné sur la toile, j'en tire plusieurs conclusions :
    - lorsqu'on choisit Document based, toute la mécanique liée à  NSDocument est implémentée "automatiquement".
    - si on ne choisit pas cette solution, il faut réimplementer manuellement. Il faut donc savoir quoi implémenter exactement.
    Bref, Document based semble plus simple mais moins "puriste". Au final cela ne semble pas vraiment peser sur le code (taille, rapidité, etc.).

    Par curiosité (et pour apprendre, finalement je suis là  pour ça) je vais essayer la solution proposée par Eddy58.
    Si je galère trop, je pense qu'au final je choisirait la solution de Renaud même si dans mon cas il ne devrait, a priori, y avoir qu'un seul document. Il faudra simplement que je débranche le menu New et que je gère différement Open, Open, Save, Save As et Revert.
  • ClicCoolClicCool Membre
    18:17 modifié #5
    Ah ben non Eddy ;)

    Renaud a raison, et si tu veux offrir à  ta femme une bibliothèque de livre de cuisine alors ? (je sais, je suis macho sur ce coup là  ;D )
    Ou si tu veux à  l'avenir gérer plusieurs bibliothèques ?

    La solution de Renaud est celle qui te laisse le plus de possibilités ultérieures.  :)
  • BruBru Membre
    18:17 modifié #6
    Avant même de penser à  l'architecture de l'application, il faut se poser quelques questions fondamentales (et y donner une réponse évidemment).

    1 - est-ce qu'une seule bibliothèque sera gérée à  la fois (même si on peut avoir plusieurs bibs), où plusieurs bibs seront simultanément gérables ?

    2 - un livre peut-il appartenir à  plusieurs bibs ou à  aucune (genre un livre non-classé, en attente de classement) ?

    3 - etc...

    A vue de nez, pour moi, l'archirtecture "document based" ne convient absolument pas. Mais ce jugement peut être revu en fonction de tes réponses. Moi je verrais plus une gestion du style "carnet d'adresse".

    Quant à  ré-écrire ce que te fournit "document based" (open, save...), cocoa est si riche que ce n'est pas compliqué à  faire soit même (voir le début de réponse de Eddy58 plus haut).

    .
  • BornToBeCocoaBornToBeCocoa Membre
    18:17 modifié #7
    dans 1095579525:

    1 - est-ce qu'une seule bibliothèque sera gérée à  la fois (même si on peut avoir plusieurs bibs), où plusieurs bibs seront simultanément gérables ?

    Une seule sera gérable à  la fois.


    2 - un livre peut-il appartenir à  plusieurs bibs ou à  aucune (genre un livre non-classé, en attente de classement) ?

    Non, chaque livre n'appartiendra qu'à  une seule bibliothèque et il n'y aura pas de livres non classés


    Moi je verrais plus une gestion du style "carnet d'adresse".


    C'est exactement ce à  quoi j'avais pensé. Mais en procédant sans l'architecture Doc-based je n'arrive plus à  sauvegarder. Ce que je parviens à  faire avec Doc-based.
    Même en réimplémentant le coding et en essayant chacune des 3 méthodes
    <br />- (NSData *)dataRepresentationOfType:(NSSTring *)type<br />- (NSFileWrapper *)fileWrapperRepresentationOfType:(NSString *)type<br />- (BOOL)writeToFile:(NSSTring *)filename ofType:(NSString *)type<br />
    

    Impossible de sauver le tableau qui représente ma bibliothèque et qui contient les objets livres.


    Quant à  ré-écrire ce que te fournit "document based" (open, save...), cocoa est si riche que ce n'est pas compliqué à  faire soit même (voir le début de réponse de Eddy58 plus haut).

    Il semble que dans le livre Cocoa Programming de S. Anguish il y ait un chapitre sur la manière de construire une appli du style doc-based à  partir de rien. J'irai voir le bouquin pour en apprendre plus.

    Au final je suis d'accord avec toi, doc-based ne me semble pas le plus "propre". Mais pour un débutant c'est peut-être le plus rapide sachant que j'ai déjà  beaucoup à  apprendre.
  • mpergandmpergand Membre
    18:17 modifié #8
    Si comme bru, de prime abord, je pencherais pour le non document-based, je pense néanmoins qu'il est préférable dans ton cas de l'utiliser. Si dans un premier temps tu n'envisage que de gérer une seule biblio (car tu penses que c'est plus simple),  il se peut que rapidement, tu réalises que ça serait pas si mal d'en gérer plusieurs ;) et si tu utilises d'emblée la structure document-based tu n'auras aucun problème pour le faire.

    De plus la structure document-based est bien pratique au debut, car elle possède tout ce qu'il faut pour le chargement, la sauvegarde des données et plein d'autres choses (le undo, le status du doc (modifié ou pas) etc ).

    Bien sûr on peut s'amuser à  tout récrire (ce que je fais dans bon nombre de mes applis) mais c'est peut-être pas très utile dans un premier temps ;)
  • 18:17 modifié #9
    En penchant sur le document Based, je pensais à  iView Media Pro qui est un programme de catalogage de photos. Au départ, je trouvais stupide de ne pas avoir qu'un seul catalogue, mais au final c'est un très bon choix, ne fut-ce que pour permettre de séparer les photos "professionnelles" des photos personnelles. Il te suffit de régler le programme pour qu'il ouvre la dernière bibliothèque ouverte au démarage, ce qui permet à  ceux qui n'ont qu'une seule bibliothèque de penser qu'ils ne sont pas dans une Appli Document-Based (ou du moins de ne pas en subir les inconvénients s'ils n'ont qu'un seul fichier à  gérer), et à  ceux qui veulent en gérer plusieurs de pouvoir le faire.
  • ClicCoolClicCool Membre
    18:17 modifié #10
    Bien d'accord avec toi,
    je trouve très pénible le fonctionnement d'iPhoto et du carnet d'adresses sur ce point.
    Je suis obligé d'ouvrir sur ma bécane autant de comptes que j'ai de contextes d'utilisation et ça me fout un basar pas possible tout ça !  >:(

    Même si la phylosophie de ces logiciel est basée sur un seul "contenaire" on devrait pouvoir définir d'autres conténaires selon les circonstance.

    Comme dit Arldnaud ;) le mélange des photos de famille avec celle du boulot est très pénible, d'autant que mes photos de boulot sont en général peu ragoutantes (plaies et escarres en tout genre :( )
  • Eddy58Eddy58 Membre
    18:17 modifié #11
    dans 1095556643:

    Ah ben non Eddy ;)

    Renaud a raison, et si tu veux offrir à  ta femme une bibliothèque de livre de cuisine alors ? (je sais, je suis macho sur ce coup là  ;D )
    Ou si tu veux à  l'avenir gérer plusieurs bibliothèques ?

    La solution de Renaud est celle qui te laisse le plus de possibilités ultérieures.  :)


    ;D Apparemment il n'y a pas de filles sur OC ClicCool ! Tu espérais des réactions d'éventuels membres féminins ? ;) Les filles vous êtes où ?? :adios!:

    Je suis tout a fait d'accord avec Renaud, moi personnellement j'aurais conçus une appli de bibliothèque en document-based. Je montre a BornToBeCocoa qu'on peut très bien se débrouiller sans toutes ces "assistances", et qu'il n'y a rien de compliqué a sauvegarder ces données dans une appli "classique"... :)
  • TiffTiff Membre
    18:17 modifié #12
    Si ça peut t'aider, j'avais commencé une petite appli Vidéothèque, avec une classe Film et une classe Acteur. Une appli sans document.
    On trouve les 5 états successifs du projet ici.
  • muqaddarmuqaddar Administrateur
    septembre 2004 modifié #13
    Ah Tiff, je viens de trouver une partie de mon bonheur dans cet exemple que j'avais oublié concernant l'achivage. Merci !

    Dis moi comment on peut faire pour céer le(s) dossier(s) du chemin automatiquement ? Toi tu dis qu'il est nécessaire de créer le dossier avant mais c'est dommage... (projetVidéothèque)
  • TiffTiff Membre
    septembre 2004 modifié #14
    Il y a eu un post la-dessus il n'y a pas longtemps. Malheureusement j'ai oublié de le consigner. Une méthode permet de vérifier qu'un chemin existe, et sinon elle le crée. Je fais une petite recherche rapide. Sinon un "pro" va bien savoir te répondre !  :)

    [EDIT] Ben zut alors, je le trouve plus !  :'(
  • TiffTiff Membre
    septembre 2004 modifié #16
    Ah ben oui, c'est celui-là . Déjà  15 jours ?

    [EDIT] Faudrait peut-être le déplacer vers le forum Sauvegarde ?
  • muqaddarmuqaddar Administrateur
    18:17 modifié #17
    Merci à  tous les deux ;)
Connectez-vous ou Inscrivez-vous pour répondre.