Vue de conditions
laurris
Membre
Bonjour,
Il ne s' agit pas vraiment d' un projet d' application mais d'un élément d'interface réutilisable. J' appelle ça un criteria View mais je ne sais pas comment ça s' appelle en vrai. Un court dessin valant mieux qu' un long discours, j' ai fait une copie d' écran.
On retrouve ce genre de choses dans iTunes, iPhoto, Mail, etc ... et avec spotlight je pense que ça va devenir à la mode.
L' avantage réside dans le fait que tout est paramétrable dans un fichier plist chargé au démarrage (criteria.plist). Les valeurs des objets comparés ainsi que les conditions possibles sont des paramètres.
La ligne de popups correspondant à une condition provient d' un nib chargé à chaque fois qu' on l' ajoute.
Tous les éléments sont pilotés par des bindings.
Bon enfin voilà , le code n' est pas écrit avec la plus grande subtilité et il y a un workaround avec le binding du NSTextField, mais je crois qu' il est facile à comprendre et à améliorer.
Si vous voulez utiliser le code dans vos application, vous pouvez. Dans ce cas, merci de me faire part de vos suggestions. De mon coté je vous indiquerai les endroits qui posent problème et qu' il faut améliorer.
A+ . Laurris.
Téléchargement (xcode 1.5): CriteriaView.dmg
[Fichier joint supprimé par l'administrateur]
Il ne s' agit pas vraiment d' un projet d' application mais d'un élément d'interface réutilisable. J' appelle ça un criteria View mais je ne sais pas comment ça s' appelle en vrai. Un court dessin valant mieux qu' un long discours, j' ai fait une copie d' écran.
On retrouve ce genre de choses dans iTunes, iPhoto, Mail, etc ... et avec spotlight je pense que ça va devenir à la mode.
L' avantage réside dans le fait que tout est paramétrable dans un fichier plist chargé au démarrage (criteria.plist). Les valeurs des objets comparés ainsi que les conditions possibles sont des paramètres.
La ligne de popups correspondant à une condition provient d' un nib chargé à chaque fois qu' on l' ajoute.
Tous les éléments sont pilotés par des bindings.
Bon enfin voilà , le code n' est pas écrit avec la plus grande subtilité et il y a un workaround avec le binding du NSTextField, mais je crois qu' il est facile à comprendre et à améliorer.
Si vous voulez utiliser le code dans vos application, vous pouvez. Dans ce cas, merci de me faire part de vos suggestions. De mon coté je vous indiquerai les endroits qui posent problème et qu' il faut améliorer.
A+ . Laurris.
Téléchargement (xcode 1.5): CriteriaView.dmg
[Fichier joint supprimé par l'administrateur]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Deux questions :
1- Est-ce que je pourrais te donner un coup de main ? (peut-etre pas tout de suite, dans un mois j'espere)
2- Comptes-tu en faire un framework ?
Bravo
pour info, il y a un article sur stepwise sur ce type d'élément
(http://www.stepwise.com/Articles/Technical/2003-12-20.01.html)
Pour fouf: 1/ Oui avec plaisir, quand tu veux. Je n' ai pas touché au projet depuis quelques semaines donc il faudrait que je m' y replonge pour voir dans quelles directions ça peut évoluer.
2/ Un Framework, c' est une bonne idée mais je n' y ai pas réfléchi.
pour cbrandt: j' ai vu cet article. Si je me souviens bien, l' exemple utilisait une Table View. Finalement j' ai utilisé une NSView simple parce qu' avec une NSTableView on ne peut avoir des UI différents dans une même colonne.
PS: Si vous avez des questions sur l' utilisation ou les méthodes (précises si possibles), n' hésitez pas.
D' ailleurs je précise un truc: Le bouton "interpret" est relié à une action qui lit un fichier testRecords.plist situé dans le répertoire ressource et vérifie s' il est satisfait par les conditions données dans l'interface.
A+
J'ai commencer a regarder pour un Framework mais il y a un probleme (enfin pour moi qui ne suis pas un expert pour faire des Frameworks
On peut-etre regarder dans le framework Graphtool de Mala.
A voir.
Sinon, le code a l'air hyper-simple a integrer dans ses applis.
Bravo laurris.
Sinon il me semble plus adéquat de parler d'éditeur de règles au lieu de vue de conditions
Je ressucite temporairement ce fil parce que je viens de découvrir dans les nouvelles classes de Tiger quelque chose qui ressemble à ce projet.
Il s' agit de la classe NSPredicate qui semble représenter une condition, j' imagine dans le but d' être utilisée avec spotlight. Je dis "semble" parce que je n' ai pas vu de documentation et d' ailleurs si quelqu' un a plus d' infos sur le sujet, ça serait utile. Je crois que dans l'idéal, si mon élément d' inteface est destiné à être frameworkisé, il faudrait reprendre les mêmes concepts de code que dans Tiger et essayer de l' adapter le plus possible pour panther ...
Pour répondre à fouf: je ne connais rien aux IBpalettes, je ne sais pas si on peut inclure des bindings. Il faut considérer aussi que dans mon code, les "règles" ou "conditions" sont des nibs chargés dynamiquement quand on les créé... je sais pas si c' est clair quand on voit le code...
Sinon, concernant la comparaison avec un système de TableView avec des rows, il y a du pour et du contre mais je crois que ce système est plus souple et plus modulaire. On peut imaginer toute sorte d' éléments d' interface dans la règle, sans avoir les contraintes imposées par la TableView.
Nucléus: Merci, "Editeur de règles" c' est effectivement plus approprié et plus parlant. hélas je ne paeux pas changer le titre du fil.
A+. Laurris.
Fais gaffe Laurris ! Tu parles de choses intéressantes, mais soumises à un NDA...:-\\
je confirme... :-\\
Autant je peux comprendre,- et j' accepte volontiers- que les administrateurs du site essaient de faire respecter des règles dont la violation pourraient les mettre en cause, autant je saisis pas bien l' interet de jouer du sifflet quand on a pas l' uniforme.
Moi je veux bien "faire gaffe", comme vous dites mais je crois qu' en l'occurence il ne faut pas tomber dans la paranoia ou se faire plus flic qu' on ne l' est.
Pour que ce soit clair, je parle de la classe NSPredicate et je déplore de n' avoir aucune information dessus. Il n' y a là rien de secret puisque le terme NSPredicate est présent sur une page publique d' Apple http://developer.apple.com/macosx/tiger/spotlight.html
Restons zen et buvons du cacao !
Effectivement NSPredicate est cité sur cette page mais ils développent pas dessus. Alors attention quand même.
Alors là , je crois que tu vas être décu, enfin je pense...
Les développeurs attendent beaucoup de Tiger, peut-être trop, on verra bien
Je ne suis pas aussi pessimiste que toi mpergand, d'après les bribes d'infos disponible au vulgaire amateur n'ayant pas 500¤ à dépenser pour ne pas attendre la sortie officielle du tigre, la pluspart des coreMachin seront dispo pour Obj-C sous xCode.
Maintenant peut-être pas en java
Je recopie ici le paragraphe qui est donc complètement NDA free (bien sur):
http://developer.apple.com/macosx/tiger/coreimage.html
C'est une API objet !!
Regardez ce bout de code:
Y a un truc bizarre, CIImage et CIFilter: ce ne sont pas des pointeurs ???
C'est quoi alors, juste un typedef ou alors c'est vraiment alloué dans la pile ???
Curieux, non ?
;D ;D ;D
Dis-moi cbrandt, tous les exemples de code sont du même genre dans la beta de Tiger ;D
Par contre, est-ce que ca marchera sur mon iMac achete en 2002 ?
Ca a l'air d'être une sacrée me..e pour développer de nouveaux modules :
Pas Glop
Si tu veux plus d' infos, demande-moi, c' est pas compliqué (même si c' est pas la méthode officielle d' Apple).
Je ne pense pas qu'il y ait d'erreur de la part d'Apple dans cet exemple (à part le "[" manquant), car c'est une caractéristique des Cores APIs d'utiliser ce genre d'écriture.
Exemples :
[tt]
CFStringRef string=CFSTR("Vive Cocoa !");
CGImageRef image;
CGWindowRef window;
[/tt]
Quand on regarde CGWindowRef, on a un typedef :
[tt]
typedef WindowPtr WindowRef;
[/tt]
Et en cherchant plus loin, on tombe enfin sur le pointeur de structure :
[tt]
typedef struct OpaqueWindowPtr * WindowPtr;
[/tt]
Bien sûr les APIs Core Foundation, Core Graphics sont procédurales alors que Core Image et autres Core Datas sont orientées objets, mais je pense que les racines sont communes et sont la raison de l'utilisation des typedefs.