Bonjour à tous,
Mon apprentissage de Smalltalk avec Pharo se poursuit lentement mais surement... J'ai regardé les exemples de Polymorph. Bravo aux auteurs, ce système semble complet, esthétique et thèmable. C'est plus que j'en espérais. Après quelques expérimentations, je me pose deux questions auquelles je ne trouve pas de réponses. Est-ce qu'il y a une contre indication d'utiliser la fenêtre principale de Pharo pour créer mon interface qui serait complété par des fenêtres modales??? Le but recherché est d'éviter d'avoir une fenêtre principale qui s'ouvre dans une autre fenêtre (celle de Pharo). Ma seconde question est : Comment fait-ons pour effacer ou supprimer un morph sur la dite fenêtre. J'ai remarqué que chaque morph sont identifié par un numéro. Je me demande comment utiliser cet id pour me référer à un morph en particulier afiin de le supprimer ou de le modifier suite à une action le cas échéant. J'ai aussi fais quelques scénarios de mon programme de gestion de recettes et je pense avoir arrivé à quelque chose de réalisable avec un peu d'effort il va de soit. Cela m'a obligé à repensé à la structure du programme. Avant de choisir Pharo, j'avais pensé construire le programme en quatre modules; un de Création (créer une recette, une catégorie, une fiche technique, etc). Un second d'édition (Éditer une recette, une catégorie, etc.). Un troisième de Consultation et un dernier pour l'interface. Cela me semblais aproprié pour avoir un programme fonctionnel avec un minimum de code pour chaque module. Il m'aurais resté à le faire évoluer par l'ajout de fonctions. Mais voilà, j'ai vite constaté que cette structure ne convenait pas vraiment à un langaqge objet comme Pharo. J'ai donc repensé mon programme comme étant des objets qui communiquent entre eux. J'ai donc abandonner mes quatre modules qui regroupaient des fonctions apparentées pour les remplacer par quatre Classes (pour l'instant). Une classe : UIApp pour l'interface regroupant les méthodes de création des morphs. Une seconde : Recette regroupant des variables d'instance (id, titre, description, listeIngredients, portions, etc) avec des méthode accession et de mutations. Une trosième classe Truc pour des fiches de trucs et astuces regroupant elle aussi des variables d'instances avec des méthodes d'accession et de mutation. Et finalement une quatrième : Media regroupant toujours des variables d'instance avec des méthodes d'accession et de mutation. Ce qui donne : Object subclass: #UIApp instanceVariableNames: 'mainWin modalRecette modalTruc modalMedia toolsbar menubar' classVariableNames: '' poolDictionaries: '' category: 'Recettarium' Object subclass: #Recette instanceVariableNames: 'id titre categorie listeIngredients preparation portions notes trucLier mediaLier temps references' classVariableNames: '' poolDictionaries: '' category: 'Recettarium' Object subclass: #Truc instanceVariableNames: 'id titre categorie description' classVariableNames: '' poolDictionaries: '' category: 'Recettarium' Object subclass: #Media instanceVariableNames: 'id titre description formatMime' classVariableNames: '' poolDictionaries: '' category: 'Recettarium' J'aimerais bien connaître votre avis sur cette structure. Est-ce valable??? Je me suis procuré Squeak programmetion et Squeak par l'exemple. Je suis loin d'avoir assimilé le contenu de ces bouquin mais je me demande néanmoins s'il ne serait pas recommendable de me procurer un bouquin sur le langage SmallTalk qui aurait des annexes sur les multiples classes et méthodes du langage. Si vous pourriez me référer des ouvrages en français je vous en serais reconnaissant. Ah ! J'aurais bien d'autres questions concernant les morph, les classes et les méthodes mais je vais poursuivre mes lectures et recherches avant de vous embêter pour tout et pour rien... Merci de me partager vos connaissances et de m'aider dans mon apprentissage. Laurent Bussières Mon site familiale : http://famillebussieres.ca |
Bonjour Laurent,
2010/8/14 Laurent Bussieres <[hidden email]>: > Est-ce qu'il y a une contre indication d'utiliser la fenêtre principale de > Pharo pour créer mon interface qui serait complété par des fenêtres > modales??? Si tu penses à des fenêtres en dehors de la fenêtre de Pharo, ça n'est pas possible. > Le but recherché est d'éviter d'avoir une fenêtre principale qui > s'ouvre dans une autre fenêtre (celle de Pharo). Je ne vois pas d'autre solution que d'utiliser la fenêtre de Pharo comme une sorte de "bureau", dans laquelle ton interface ouvre des fenêtres. Tu peux aussi faire une interface web avec Pharo ou Aida Web. > Ma seconde question est : Comment fait-ons pour effacer ou supprimer un > morph sur la dite fenêtre. Pour effacer un morph, il te faut une référence et ensuite tu envoies le message #delete. Pour trouver une référence, il y a plusieurs techniques. Tu peux la stocker quelque part au moment où tu crée le morph. Tu peux aussi chercher ton morph en partant du morph qui le contient. Par exemple, pour trouver le morph Transcript à partir de la fenêtre principale de Pharo : (World submorphsSatisfying: [:morph | morph isSystemWindow and: [morph labelString = 'Transcript']]) ça retourne une collection de tous les morphs qui répondent à un critère. > J'ai remarqué que chaque morph sont identifié par > un numéro. Je me demande comment utiliser cet id pour me référer à un morph > en particulier afiin de le supprimer ou de le modifier suite à une action le > cas échéant. je ne sais pas de quel numéro tu parles. Si tu parles de ce qui est affiché entre parenthèses quand tu fais un 'print' sur une référence, il s'agit simplement de l'identifiant de l'objet. Tu peux demander son identifiant à n'importe quel objet : 3 identityHash par exemple > J'ai aussi fais quelques scénarios de mon programme de gestion de recettes > et je pense avoir arrivé à quelque chose de réalisable avec un peu d'effort > il va de soit. Cela m'a obligé à repensé à la structure du programme. Avant > de choisir Pharo, j'avais pensé construire le programme en quatre modules; > un de Création (créer une recette, une catégorie, une fiche technique, etc). > Un second d'édition (Éditer une recette, une catégorie, etc.). Un troisième > de Consultation et un dernier pour l'interface. Cela me semblais aproprié > pour avoir un programme fonctionnel avec un minimum de code pour chaque > module. Il m'aurais resté à le faire évoluer par l'ajout de fonctions. Mais > voilà, j'ai vite constaté que cette structure ne convenait pas vraiment à un > langaqge objet comme Pharo. en effet. En objet, on commence souvent par créer un modèle des objets que l'on va manipuler. Dans ton cas, on s'attend à voir une classe Recette, une classe FicheTechnique... > J'ai donc repensé mon programme comme étant des > objets qui communiquent entre eux. J'ai donc abandonner mes quatre modules > qui regroupaient des fonctions apparentées pour les remplacer par quatre > Classes (pour l'instant). Une classe : UIApp pour l'interface regroupant > les méthodes de création des morphs. Une seconde : Recette regroupant des > variables d'instance (id, titre, description, listeIngredients, portions, > etc) avec des méthode accession et de mutations. Une trosième classe Truc > pour des fiches de trucs et astuces regroupant elle aussi des variables > d'instances avec des méthodes d'accession et de mutation. Et finalement une > quatrième : Media regroupant toujours des variables d'instance avec des > méthodes d'accession et de mutation. > > Ce qui donne : > > Object subclass: #UIApp > instanceVariableNames: 'mainWin modalRecette modalTruc modalMedia > toolsbar menubar' > classVariableNames: '' > poolDictionaries: '' > category: 'Recettarium' > > Object subclass: #Recette > instanceVariableNames: 'id titre categorie listeIngredients preparation > portions notes trucLier mediaLier temps references' > classVariableNames: '' > poolDictionaries: '' > category: 'Recettarium' > > Object subclass: #Truc > instanceVariableNames: 'id titre categorie description' > classVariableNames: '' > poolDictionaries: '' > category: 'Recettarium' > > Object subclass: #Media > instanceVariableNames: 'id titre description formatMime' > classVariableNames: '' > poolDictionaries: '' > category: 'Recettarium' > > J'aimerais bien connaître votre avis sur cette structure. Est-ce valable??? Ça semble valable. Quelques remarques : - il faudrait sans doute faire une classe Modele qui a comme champs 'id' et 'titre' et faire hériter tes classes Recette, Truc et Media de cette classe. Comme ça, tu décris une seule fois ces 2 champs - il va aussi falloir un "repository". Un objet qui contient les instances des classes Recette, Truc et Media. Cet objet pourra te permettre de faire des recherches (par exemple, "toutes les recettes de la catégorie FOO classée par temps", ou "tous les médias video/ogg"). - il va sûrement être nécessaire de découper UIApp en plusieurs classes. Tu t'y retrouveras mieux. > Je me suis procuré Squeak programmetion et Squeak par l'exemple. Je suis > loin d'avoir assimilé le contenu de ces bouquin mais je me demande néanmoins > s'il ne serait pas recommendable de me procurer un bouquin sur le langage > SmallTalk qui aurait des annexes sur les multiples classes et méthodes du > langage. Si vous pourriez me référer des ouvrages en français je vous en > serais reconnaissant. Je recommande Smalltalk by Example pour commencer (rien à voir avec Squeak/Pharo By Example) : http://stephane.ducasse.free.fr/FreeBooks/ByExample/. Ensuite, tu peux utiliser le navigateur de code pour avoir les détails des classes et des méthodes. > Merci de me partager vos connaissances et de m'aider dans mon apprentissage. > Laurent Bussières N'hésite pas à utiliser la messagerie instantanée et IRC pour gagner du temps avec les petites questions. Pour me joindre, toutes les informations sont sur mon site web. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
Bonjour Damien,
Je me suis peut-être mal exprimé. Lorsque tu dis :
Ce que je voulais dire c'est que je me demande si il est possible ou plutôt valable d'utiliser la fenêtre de Pharo pour y insérer les widgets de mon interface directement sur la fenêtre de Pharo? Ainsi dès l'ouvertuure de l'image c'est mon interface qui apparait et le tout serait complété par des fenêtres modales. Si cela n'est pas recommandé, est-il envisageable de créer des fenêtres modales sans barre de titre que je pourrais coller sur la fenêtre principale de Pharo. Tel des blocs s'emboîtant les uns les autres pour former mon interface principal ? Merci pour le code : "(World submorphsSatisfying: [:morph | morph isSystemWindow and: [morph C'est exatement ce que je cherchais à faire. "- il faudrait sans doute faire une classe Modele qui a comme champs Encore une fois je me suis mal exprimé: Je ne répète pas les ids et les titres. J'aurais dû écrire idRecette, idTruc, idMedia et la même chose pour les titres. Les seuls répétitions, si il y en a, c'est dans la classe Recette ou sont inscrits les idTruc et idMedia qui sont liés à ladite recette. Cependant, ta réponse éclaire un questionnement que j'avais sur l'utilisation d'une base de données relationnelle. Si je comprend bien cette structure (tables multiples) peut être tout à fait valable mais au lieu d'accéder aux données par requêtes on accède au données par mode d'héritage. Lorsque tu écris : "- il va aussi falloir un "repository". Un objet qui contient les Là je suis un peu perdu... Ce n'est pas les classes elles même qui crées leurs instances ? Je pensais faire mes recherches directement sur les classes de collection. À moins que "repository" soit une sous-classe de collection, un peu comme une base de données ??? "- il va sûrement être nécessaire de découper UIApp en plusieurs La factorisation n'est pas encore natuelles pour moi. J'ai encore de la peine à me retrouver dans les multiples fenêtres de Pharo. Mais je commence à aimer ça... "Je recommande Smalltalk by Example pour commencer" C'est des références en français qu'il me faut car mon anglais est minable voir inexistant. Je vais néanmoins voir si une traduction logicielle ne pourrait pas me convenir. Un grand merci pour ton aide. Laurent Bussières Mon site familiale : http://famillebussieres.ca |
On Aug 15, 2010, at 1:25 PM, Laurent Bussieres wrote: > Bonjour Damien, > > Je me suis peut-être mal exprimé. Lorsque tu dis : > > "Je ne vois pas d'autre solution que d'utiliser la fenêtre de Pharo > comme une sorte de "bureau", dans laquelle ton interface ouvre des > fenêtres. Tu peux aussi faire une interface web avec Pharo ou Aida > Web." > > Ce que je voulais dire c'est que je me demande si il est possible ou plutôt valable d'utiliser la fenêtre de Pharo pour y insérer les widgets de mon interface directement sur la fenêtre de Pharo? Ainsi dès l'ouvertuure de l'image c'est mon interface qui apparait et le tout serait complété par des fenêtres modales. oui bien sur tu peux faire ce que tu veux. > Si cela n'est pas recommandé, est-il envisageable de créer des fenêtres modales sans barre de titre que je pourrais coller sur la fenêtre principale de Pharo. Tel des blocs s'emboîtant les uns les autres pour former mon interface principal ? > > Merci pour le code : > > "(World submorphsSatisfying: [:morph | morph isSystemWindow and: [morph > labelString = 'Transcript']])" > > C'est exatement ce que je cherchais à faire. > > > "- il faudrait sans doute faire une classe Modele qui a comme champs > 'id' et 'titre' et faire hériter tes classes Recette, Truc et Media de > cette classe. Comme ça, tu décris une seule fois ces 2 champs" > > Encore une fois je me suis mal exprimé: Je ne répète pas les ids et les titres. J'aurais dû écrire idRecette, idTruc, idMedia et la même chose pour les titres. Les seuls répétitions, si il y en a, c'est dans la classe Recette ou sont inscrits les idTruc et idMedia qui sont liés à ladite recette. Cependant, ta réponse éclaire un questionnement que j'avais sur l'utilisation d'une base de données relationnelle. Si je comprend bien cette structure (tables multiples) peut être tout à fait valable mais au lieu d'accéder aux données par requêtes on accède au données par mode d'héritage. > > Lorsque tu écris : > > "- il va aussi falloir un "repository". Un objet qui contient les > instances des classes Recette, Truc et Media. Cet objet pourra te > permettre de faire des recherches (par exemple, "toutes les recettes > de la catégorie FOO classée par temps", ou "tous les médias > video/ogg")." > > Là je suis un peu perdu... Ce n'est pas les classes elles même qui crées leurs instances ? Je pensais faire mes recherches directement sur les classes de collection. À moins que "repository" soit une sous-classe de collection, un peu comme une base de données ??? mais tu peux avoir une variable de class ou un singleton qui garde toutes les instances dont tu as besoin. > "- il va sûrement être nécessaire de découper UIApp en plusieurs > classes. Tu t'y retrouveras mieux." > > La factorisation n'est pas encore natuelles pour moi. J'ai encore de la peine à me retrouver dans les multiples fenêtres de Pharo. Mais je commence à aimer ça... > > > "Je recommande Smalltalk by Example pour commencer" Squeak chez eyrolles est en francais > C'est des références en français qu'il me faut car mon anglais est minable voir inexistant. Je vais néanmoins voir si une traduction logicielle ne pourrait pas me convenir. > > Un grand merci pour ton aide. > Laurent Bussières > > Mon site familiale : http://famillebussieres.ca > > > |
Free forum by Nabble | Edit this page |