| french | english |
 |
|
| Créer un compte | |
| 19-06-08 / 23:46 : Premier retour sur SproutCore (cjed) |
| Voici ce qu'on peut dire sur SproutCore après avoir lu les premiers tutoriaux : - Il n'y a pas d'outil (pas d'éditeur de code, et pas d'outil Wysiwyg ), mais Interface Builder arrivera peut être par la suite (après tout il en va de même avec GWT). La création des répertoires et des fichiers se fait via la ligne de commande, le tout se base sur le langage de scripting Ruby. - les pages sont des .rhtml (framework de templating Erubis basé sur Ruby). On y définit les tags (labels, contrôles) dynamiques dans des scriptlets <%= %>. - 1ère notion importante, les bindings : on peut lier la valeur d'un label à une propriété d'un objet (défini dans des classes Javascript, voir plus loin), ou encore des contrôles (boutons par ex) à des méthodes du contrôleurs (actions à déclencher au changement d'état du contrôle). Point très important : si on change une propriété (d'un objet contrôleur par ex, ou modèle) en live (via le débugger de Firefox par ex), la valeur est mise à jour dans la vue. Les objets (javascript) sont donc vivants comme dans un runtime, et le binding assure un couplage faible (pas de modif de code requise). Cette approche est complètement différente d'un système de tags (Struts, JSF...) interprétés côté serveur, dont les valeurs, une fois la réponse HTML rendue renvoyée au client, sont immuables. - 2ème notion : les observers (KVO : key value observer) : des méthodes du contrôleur peuvent être déclenchées automatiquement lors de la modification de valeur d'une propriété (sorte de notification). Cette possibilité est à l'origine de nombreuses fonctionnalités/simplifications de mise en oeuvre (et de code) de Cocoa. - on définit une classe contrôleur facilement via un simple constructeur anonyme (méthode create), où on y met les actions ou les méthodes de notification (observers), et également les propriétés (possible sur classe modèle si on veut coller au MVC). Le but est de développer rapidement, en limitant le nombre de classes requises et les instanciations. Le Javascript utilisé est de haut niveau (orienté objet, avec getters et setters) et des APIs de gestion des tâches (timers, etc.) sont incluses (propriété privée _timer acessible par défaut pour traiter rapidement les cas simples). Il n'y a pas de phase de transformation comme avec GWT (coupe le cycle de développement) et le développement se veut le plus rapide possible, avec le moins de code possible. L'appel de services (webservices) côté serveur se fait via JSON-RPC (comme pour GWT et les clients WebObjects en Java Swing), du RPC avec syntaxe particulière (différente du XML-RPC). Il est donc possible d'appeler du code serveur (backend) créé avec n'importe quelle technologie : Java, PHP, etc. On peut s'attendre à ce qu'Apple propose la YellowBox (Cocoa complet, en Objective-C) dans un ou deux ans, afin de contrer Adobe et son AIR, et Microsoft. En attendant il reste des pistes pour introduire des fonctionnalités audio/vidéo côté client via SproutCore : nouveaux tags vidéo HTML5, QuickTime X en préparation pour Snow Leopard (pourrait être un concurrent du container Flash d'Adobe, QuickTime permettant déjà de créer des applications complètes dans un .mov). On attend également le rapprochement avec le framework Cappuccino, qui propose carrément un portage d'objets Cocoa en javascript, et une extension (runtime) du language javascript (Objective-J) - tout comme Objective-C est une extension du C -, qui permet d'appeler ces objets (une phase de compilation à la volée en javascript basique est effectuée, mais ceci est transparent contrairement à GWT). |
| Commentaires |
| Poster un commentaire |