oui, mais faire la même présentation avec VisualBasic prends aussi moins de temps...
(ceci dit, les lignes de guide pour le positionnement, ça rulez! de même que la gestion du redimensionnement, pas montré dans la démo, mais qui est bien différente des gestions habituelles)
La différence c'est qu'ici, j'ai un objet controleur/modèle qui est clairement découplé de mes objets graphiques (ie la logique métier est séparée), ce qui d'ailleurs a un avantage immédiat par exemple pour gêrer correctement l'internationalisation (ie, on peut au besoin faire des gui différentes pour accomoder les différentes langues).
L'autre énorme différence, c'est que je manipule directement les objets (j'ai créé directement une classe MyController dans Gorm, je l'instancie, et je link cet objet à mes autres objets, ici des NSTextfields et je link l'action du NSButton sur mon controleur). Tout le code gêrant ça (que j'aurait pu éventuellement taper) est supprimé.
Un fichier .gorm est en fait juste la sérialisation du graph d'objets... donc quand tu charge un fichier .gorm, ça désérialize tous tes objets (= remets les valeurs qui étaient positionnées) et réétablit toutes les connections entre objets (entre parenthèse, on est pas limité à un fichier .gorm par application hein..). Toujours ça de moins à coder. L'autre truc cool, c'est que tu n'est absolument pas limité aux objets "standard" fournis par GNUstep -- la preuve ici j'utilise bien un objet de la classe "MyController". Faire tes propres widgets et te créer une palette d'objet personalisé (avec inspecteurs et tout) est pas bien compliqué.. et ce peux aussi être des objets non-graphique, comme MyController...
Par exemple dans une appli que j'ai créé récemment pour le boulot, j'ai codé mes classes normalement, mais au lieu de créer mes instances à la main et de gêrer tout le truc, j'ai créé mes instances et gêré toutes les relations directement dans Gorm. Ben c'est clairement pratique et plus souple :-)
Sous OSX, ils ont par exemple introduits une classe très cool, NSController. En gros dans le design pattern Modèle-Vue-Controleur, tu sépares en trois objets: un objet modèle (logique métier), un objet vue (interface graphique, ie, ce que Gorm permet de créer très simplement) et un objet controleur, qui fait la "glue" entre la vue et le modèle (vu que très souvent cette glue est simple et donc un peu rébarbative à coder). Ben NSController est dispo dans une palette d'InterfaceBuilder (Gorm est la même chose qu'IB), et tu instancie ton controleur, etc.
Dans mon exemple le controleur et le modèle ne font qu'un, parce que l'exemple est trivial. L'intérêt par contre, et contrairement aux approches à la visual basic, c'est que cette approche monte très bien en charge (c'est à dire que faire une interface graphique complexe est beaucoup plus pratique de cette façon que quand ton code mélanges tout).
Bref. Gorm (ou IB) ne sont pas "juste" des constructeurs d'interface graphique. Fondamentalement, ils sont plutôt des modeleurs de relations inter-objets... ce qui a un tas de répercussions intéressantes.
Bon maintenant, je répète que je connais pas vraiment Delphi, et il est fort probable que Delphi apporte des trucs très sympas aussi (j'en ai entendu du bien..)..
[^] # Re: Mouais...
Posté par Nicolas Roard . En réponse au journal GNUstep demonstration. Évalué à 6.
(ceci dit, les lignes de guide pour le positionnement, ça rulez! de même que la gestion du redimensionnement, pas montré dans la démo, mais qui est bien différente des gestions habituelles)
La différence c'est qu'ici, j'ai un objet controleur/modèle qui est clairement découplé de mes objets graphiques (ie la logique métier est séparée), ce qui d'ailleurs a un avantage immédiat par exemple pour gêrer correctement l'internationalisation (ie, on peut au besoin faire des gui différentes pour accomoder les différentes langues).
L'autre énorme différence, c'est que je manipule directement les objets (j'ai créé directement une classe MyController dans Gorm, je l'instancie, et je link cet objet à mes autres objets, ici des NSTextfields et je link l'action du NSButton sur mon controleur). Tout le code gêrant ça (que j'aurait pu éventuellement taper) est supprimé.
Un fichier .gorm est en fait juste la sérialisation du graph d'objets... donc quand tu charge un fichier .gorm, ça désérialize tous tes objets (= remets les valeurs qui étaient positionnées) et réétablit toutes les connections entre objets (entre parenthèse, on est pas limité à un fichier .gorm par application hein..). Toujours ça de moins à coder. L'autre truc cool, c'est que tu n'est absolument pas limité aux objets "standard" fournis par GNUstep -- la preuve ici j'utilise bien un objet de la classe "MyController". Faire tes propres widgets et te créer une palette d'objet personalisé (avec inspecteurs et tout) est pas bien compliqué.. et ce peux aussi être des objets non-graphique, comme MyController...
Par exemple dans une appli que j'ai créé récemment pour le boulot, j'ai codé mes classes normalement, mais au lieu de créer mes instances à la main et de gêrer tout le truc, j'ai créé mes instances et gêré toutes les relations directement dans Gorm. Ben c'est clairement pratique et plus souple :-)
Sous OSX, ils ont par exemple introduits une classe très cool, NSController. En gros dans le design pattern Modèle-Vue-Controleur, tu sépares en trois objets: un objet modèle (logique métier), un objet vue (interface graphique, ie, ce que Gorm permet de créer très simplement) et un objet controleur, qui fait la "glue" entre la vue et le modèle (vu que très souvent cette glue est simple et donc un peu rébarbative à coder). Ben NSController est dispo dans une palette d'InterfaceBuilder (Gorm est la même chose qu'IB), et tu instancie ton controleur, etc.
Dans mon exemple le controleur et le modèle ne font qu'un, parce que l'exemple est trivial. L'intérêt par contre, et contrairement aux approches à la visual basic, c'est que cette approche monte très bien en charge (c'est à dire que faire une interface graphique complexe est beaucoup plus pratique de cette façon que quand ton code mélanges tout).
Bref. Gorm (ou IB) ne sont pas "juste" des constructeurs d'interface graphique. Fondamentalement, ils sont plutôt des modeleurs de relations inter-objets... ce qui a un tas de répercussions intéressantes.
Bon maintenant, je répète que je connais pas vraiment Delphi, et il est fort probable que Delphi apporte des trucs très sympas aussi (j'en ai entendu du bien..)..