Programmer en Cocoa pour le Web

muqaddarmuqaddar Administrateur
février 2010 modifié dans Actualités #1
Hello,

On connaissait déjà  SproutCore (Apple) et Objective-J (280North) pour la programmation web objective-C/Cocoa. Il y a quelques jours je suis tombé sur une news d'un autre projet pour programmer en Cocoa pour le Web. Et bien, impossible de remettre la main dessus (je crois que c'était sur MacGé).

ça vous dit quelque chose ?  B)

Réponses

  • wiskywisky Membre
    février 2010 modifié #2
    Oui, c'est un frameworks qui permet d'ecrire une app en Obj-C et après de la publier avec Apache Tomcat ou autre serveur du genre. Il on même leur propre serveur. Mais impossible de trouver le nom.
  • muqaddarmuqaddar Administrateur
    11:36 modifié #4
    Super et merci !
    Ah oui, ça peut être génial comme solution mais il faut un serveur Apple du coup... ;)
  • wiskywisky Membre
    11:36 modifié #5
    Oui, et il n'est pas donnée non plus ! D'autre part, je comprend pas tout et je me demande comment tu fait d'interface graphique du site !
  • muqaddarmuqaddar Administrateur
    février 2010 modifié #6
    dans 1265807281:

    Oui, et il n'est pas donnée non plus ! D'autre part, je comprend pas tout et je me demande comment tu fait d'interface graphique du site !


    Justement : le gros plus de cette solution c'est que tu utilises carrément IB !

    A part ça, Capucino et SproutCore sont 2 APIs différentes !
    J'aimerais bien investir du temps dans une ou l'autre, mais laquelle ?

    Un post sympa.
  • wiskywisky Membre
    11:36 modifié #7
    J'ai déjà  essayer sproutcore et pour l'instant je n'y arrive pas ! Apple ne donne que peux de retour des modif qu'il font pour les besoin interne. Ce qui fait que sproutcore n'a pas beaucoup evoluer depuis 2008 et l'arrivé de MobileMe.
    Capucino me parait plus simple et plus rapide à  prendre en main du simple fait qu'il reprend l'aparence de l'OBJ-C. En plus il est possible de convertir un NIB en CIB pour Capucino. Par contre il me semblait qu'un editeur similaire à  IB mais en version web devais sortir, j'en entend plus parler !

    J'aimerai investir un peu plus de temps à  l'une ou l'autre des technologies mais la barrière de l'anglais est un frein pour moi. Et mon choix se penche plus sur des technique maison ou Capucino.
    Autre chose aussi, Sproutcore n'aime pas IE (moi non plus mais bon) alors que Capucino gère IE6 et IE7 !!

    Il faut voir !


    EDIT : J'ai un serveur Apple sur 10.5 pour des test si tu le souhaite.
  • muqaddarmuqaddar Administrateur
    11:36 modifié #8
    J'avoue que Capucino est très attirant. Plus que SproutCore.

    Le problème des nouvelles technologies, c'est qu'on n'a pas envie de passer des siècles dessus si elles sont abandonnées dans 2 ans...
    Tout cela est très très neuf.

    Merci pour ta proposition de serveur, c'est sympa.
    Mais si j'essaie Capucino, l'avantage c'est que tu déposes tout le package (framework + app) sur n'importe quel répertoire de serveur !

    Reste à  voir comment ces frameworks gèrent les connexions BDD.
  • wiskywisky Membre
    11:36 modifié #9
    Capuchino fait sert uniquement pour la partie navigateur pas BDD. Il est facile d'ecrire une petite API propre à  tes besoins en PHP en utilisant une base MySQL.
    Capucino fera ses demande avec des requêtes ajax ;)
  • muqaddarmuqaddar Administrateur
    11:36 modifié #10
    dans 1265809937:

    Capuchino fait sert uniquement pour la partie navigateur pas BDD. Il est facile d'ecrire une petite API propre à  tes besoins en PHP en utilisant une base MySQL.
    Capucino fera ses demande avec des requêtes ajax ;)


    Tu veux dire une API en objective-J ? (point de PHP ici... à  quoi bon ?)
  • wiskywisky Membre
    février 2010 modifié #11
    dans 1265810050:

    dans 1265809937:

    Capuchino fait sert uniquement pour la partie navigateur pas BDD. Il est facile d'ecrire une petite API propre à  tes besoins en PHP en utilisant une base MySQL.
    Capucino fera ses demande avec des requêtes ajax ;)


    Tu veux dire une API en objective-J ? (point de PHP ici... à  quoi bon ?)


    Ha ! Mais cela dépend de ce que tu veux faire comme Application.

    Capucino te sert uniquement à  réaliser une application pour le navigateur web. Le stockage de document sur le poste de l'utlisateur et la base de données local sont encore trop peux utilisable (je sais que dans safaris c'est prévu mais je sais pas comme y acceder).
    Donc si tu fait une app qui a besoin d'une db elle sera héberger sur un serveur. Pour accéder à  cette DB il va te falloir un middleware qui traduise tes requêtes http et qui te réponde en JSON (je préfère les appeler des API quand cela fait parti d'un service web (un app web quoi)).
    Et pour faite ça je te propose de revenir sur un standard du web, c'est à  dire : PHP et MySQL. Dans le cas de Bombax c'est l'appli bombax qui gère ça !

    Exemple en Obj-J (tiré de l'exemple Flickr Photo Demo) :
    L'envoie d'une requette HTTP à  flickr pour obtenir le résultat d'une recherche en JSON :
    - (void)add:(id)sender<br />{<br />&nbsp; &nbsp; var string = prompt(&quot;Enter a tag to search Flickr for photos.&quot;);<br /><br />&nbsp; &nbsp; if(string)<br />&nbsp; &nbsp; {<br />&nbsp; &nbsp; &nbsp; &nbsp; //create a new request for the photos with the tag returned from the javascript prompt<br />&nbsp; &nbsp; &nbsp; &nbsp; var request = [CPURLRequest requestWithURL:&quot;http://www.flickr.com/services/rest/?&quot;+<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;method=flickr.photos.search&amp;tags=&quot;+encodeURIComponent(string)+<br />&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;&amp;media=photos&amp;machine_tag_mode=any&amp;per_page=20&amp;format=json&amp;api_key=ca4dd89d3dfaeaf075144c3fdec76756&quot;];<br />&nbsp; &nbsp; <br />&nbsp; &nbsp; &nbsp; &nbsp; // see important note about CPJSONPConnection above<br />&nbsp; &nbsp; &nbsp; &nbsp; [CPJSONPConnection sendRequest:request callback:&quot;jsoncallback&quot; delegate:self];<br />&nbsp; &nbsp; &nbsp; &nbsp; <br />&nbsp; &nbsp; &nbsp; &nbsp; lastIdentifier = string;<br />&nbsp; &nbsp; }<br />}<br />
    


    Et là  les fonction du délégate qui traite la réponse à  la demande :
    - (void)connection:(CPJSONPConnection)aConnection didReceiveData:(CPString)data<br />{<br />&nbsp; &nbsp; //this method is called when the network request returns. the data is the returned<br />&nbsp; &nbsp; //information from flickr. we set the array of photo urls as the data to our collection view<br /><br />&nbsp; &nbsp; [self addImageList:data.photos.photo withIdentifier:lastIdentifier];<br />}<br /><br />- (void)connection:(CPJSONPConnection)aConnection didFailWithError:(CPString)error<br />{<br />&nbsp; &nbsp; alert(error); //a network error occurred<br />}<br />
    


    EDIT : J'espère que tu comprend le principe ! C'est pas simple a expliquer sans tableau blanc ;)

    EDIT 2 : Je suis content de voir que j'apporte un peu de connaissance à  ce forums. D'abitude c'est moi qui pose plein de question ;)
  • muqaddarmuqaddar Administrateur
    février 2010 modifié #12
    Oui, mais c'est pas ça ma question. ;)

    Tout comme tu as une app en PHP ou en Ruby qui utilise des ponts pour attaquer une base côté serveur en MySQL ou SQLite (en général, il suffit d'envoyer 4 identifiants), je demandais si il exisitait une API livrée avec le framework pour directement envoyer les requêtes SQL depuis l'application Cappuccino...et récupérer la réponse SQL.

    (Chose qui existe pour une appli locale, voir framework SQLite 3 livré par Apple)

  • wiskywisky Membre
    février 2010 modifié #13
    Ha ! Non, il semble que non et je trouve ce genre de pont peux sécurisé et dangeureux. Car il est facile de faire des injections SQL et tout effacer dans la DB cible.
    Mais bon ce genre de chose n'est pas compliqué à  ecrire non plus (je parle pour moi) ;)

    C'est un point de plus pour Bombax, car il me semble que si il faut une DB elle sera géré avec CoreData ou SQLite ;)

    La doc ne parle pas de DB : http://objective-j.org/learn/documentation/modules.html
  • muqaddarmuqaddar Administrateur
    février 2010 modifié #14
    En fait dans l'approche, et pour simplifier, on peut dire que SproutCore et Cappuccino se rapprochent plus de frameworks JS ou librairies JS (avec un portage d'objective-C pour el second), alors que Bombax est une solution purement serveur un peu comme WebObjects.

    Bombax : http://www.bombaxtic.com/bombax/

    Les avantages sont nombreux pour Bombax : programmer en pur Objective-C, utiliser IB, tous les frameworks Cocoa compatibles !
    Le prix n'est pas excessif : 199$.

    Le point négatif, c'est qu'il faut absolument un hébergeur Mac compatible (souvent beaucoup plus chers).
  • wiskywisky Membre
    11:36 modifié #15
    Je viens de regarder le guide de développement Bombax il ne parle pas de GUI via IB. t'as vu ça où ?
  • muqaddarmuqaddar Administrateur
    11:36 modifié #16
    dans 1265813698:

    Je viens de regarder le guide de développement Bombax il ne parle pas de GUI via IB. t'as vu ça où ?


    Je l'ai lu sur MacGé... et c'est une belle connerie. ;)

    La doc est là  :
    http://www.bombaxtic.com/bombax/developers-guide/Bombax Developers Guide.pdf
  • wiskywisky Membre
    11:36 modifié #17
    Un gros défaut que je vois à  cette solution est le fait qu'il faut un hébergement sur Mac pour le faire tourner. C'est en mon sens le seul gros défaut pour l'adoption de cette solution. D'autre part, vu que l'interface utilisateur est faite en HTML, rien ne t'empêche de la combiner à  OBJ-J.

    Au final c'est un concurrent à  WebObject qu'Apple à  retiré du marche pour se le garder et à  PHP !
  • muqaddarmuqaddar Administrateur
    11:36 modifié #18
    J'aimerais bien savoir pourquoi Apple a préféré SproutCore que Cappuccino...
  • muqaddarmuqaddar Administrateur
    11:36 modifié #19
    En tout cas, je viens de faire tourner le Hello World de Bombax sur mon mac, et c'est vrai que c'est simple à  mettre en place (du moment qu'on a la machine sous la main).
  • wiskywisky Membre
    11:36 modifié #20
    Pour le moment, le gain apporté par Bombax n'es pas assez important pour mes app web. PHP est encore performant et il y a de la marge sur le serveur. Donc, je laisse murir la technologie et l'avenir me dira si oui ou non, il faut une fois de plus réécrire les "ponts" utilisés par les app web.

    Bombax ne m'apporte rien pour le moment, par contre sproutcore ou capicino oui !

    Quand au choix d'apple pour sproutcore il y a peut être une volonté politique propre à  Apple derrière ! Deux des 3 fondateurs de 280North sont des anciens d'Apple. Ils n'ont peut être pas voulu retourner chez Apple ! Pour sproutcore il était seul, c'est plus facile ;)
  • muqaddarmuqaddar Administrateur
    11:36 modifié #21
    Moi je me demande quel moteur Apple utilise derrière SproutCore pour attaquer la base de données justement... ;)

    D'après notre discussion, je pourrais très bien marier SproutCore à  Ruby (ou PHP) et idem pour capuccino...
  • yoannyoann Membre
    11:36 modifié #22
    Pour ce qui est de Bombax j'avais regardé les beta (il y a un post qui traine sur le formum à  ce sujet) et c'est plus pour des webservices que pour du web html.

    Sinon pour ce qu'Apple utilise, n'oubliez pas WebObject, tous les services d'Apple utilise WO pour attaquer leur base de donnée, même si le chief evangielist des techno dev Apple n'aime pas ça.


    Et pour ce qui est de SproutCore, c'est l'équipe MobileMe qui s'en sert, il y a d'autres techno qui ne sont pas forcément publié tel que Gianduia qui est utilisé ici par exemple : http://concierge.apple.com/geniusbar/R276

    Si vous ouvrez le .js associé http://concierge.apple.com/concierge/17024/scripts/common/ccweb/1-2-SNAPSHOT/Gianduia.js vous devriez reconnaitre des NSTruc (utilisez http://jsbeautifier.org/ pour le rendre lisible).

    En lisant le JS vous trouverez des truc comme ça :

    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; P = [&quot;Gianduia.Foundation.NSDOMNode&quot;, &quot;Gianduia.Foundation.NSString&quot;, &quot;Gianduia.Foundation.NSArray&quot;, &quot;Gianduia.Foundation.NSDictionary&quot;, &quot;Gianduia.Foundation.NSNotificationCenter&quot;, &quot;Gianduia.Foundation.NSHTTPRequest&quot;, &quot;Gianduia.Foundation.NSException&quot;, &quot;Gianduia.Foundation.NSKeyValueCoding&quot;, &quot;Gianduia.Foundation.NSImport&quot;, &quot;Gianduia.Foundation.NSObject&quot;],<br />
    



    C'est juste pas publié :-)
  • wiskywisky Membre
    11:36 modifié #23
    Et bien je pense aller du côté de Capucino. Cela fait un petit moment que cela me tente. Actuellement j'ecrit tout à  la main en utilisant PrototypeJS et pour les effets graphiques, une librairie qui se base sur prototype (j'ai plus le nom en tête).

    Pour le côté serveur, je reste sur PHP et MySQL ! C'est pour moi le meilleur couple de choc (surtout qu'il est sur Mac et Linux) ! J'avoue également faire des infidélités à  Mac Os X quand il s'agit de développement Web. Apple livre même sur un serveur un PHP au rabais ce qui n'est pas avantageux pour mes projets mais je développe exclusivement sur Mac !
  • muqaddarmuqaddar Administrateur
    11:36 modifié #24
    Je penbse te suivre.
    Cappuccino est bien présenté, a l'air d'avoir une doc correcte, et déjà  des applis concrètes.

    Regarde du côté de Rails aussi pour le dev web... j'aurais du mal à  revenir à  PHP.  ;)
  • JegnuXJegnuX Membre
    11:36 modifié #25
    Salut à  tous !

    Je me sens obligé de participer à  la conversation étant donné que je suis un peu un fan de Cappuccino. Je suis son évolution depuis à  peu près 1 an et demi.

    Alors quelques précisions pour commencer, SproutCore et Cappuccino sont effectivement des frameworks Javascript (et non de "simple" librairies) Le gros avantage de Cappuccino/ObjJ est sa ressemblance avec Cocoa/ObjC. En effet quand on sait déjà  développer pour iPhone ou OSX on sait développer en Cappuccino. D'ailleurs sur l'IRC où je vais de temps en temps, quand des personnes demandent de l'aider pour tel ou tel sujet (genre les delegates, protocoles etc...) ils renvoient sur la doc Cocoa d'Apple.

    L'avantage est aussi de pouvoir utiliser également Interface Builder pour créer son interface. Quelqu'un en a parlé, et effectivement un IDE est en cours de développement (actuellement en bêta privée, à  laquelle je participe d'ailleurs). ça s'appelle Atlas et c'est une application native OSX (et à  terme windows et linux) codé en Cappuccino.

    Oui car on peut aussi créer une application Cappuccino et en faire non seulement une application web mais aussi une application native à  la façon d'adobe Air et Flex. La différence avec un simple "encapsulage" dans un webkit c'est par exemple qu'en application native ça peut utiliser la vraie menubar, tandis qu'en application web ça en rajoute une dans la page.

    Bref je suis assez fan de 280North et de Cappuccino, j'ai d'ailleurs envoyé ma candidature pour faire un stage chez eux cet été ^^ Mais toujours pas de réponse... :(
    En tout cas c'est sûrement le projet open source pour lequel je souhaite contribuer dès que j'aurais du temps libre :)

    Sinon pour répondre également à  la question "pourquoi Apple utilise SproutCore et pas Cappuccino" c'est que SproutCore était déjà  là  avant. La première release publique de Cappuccino s'est faite peut après la sortie de Mobile Me je crois.
  • wiskywisky Membre
    11:36 modifié #26
    dans 1265831004:

    Je penbse te suivre.
    Cappuccino est bien présenté, a l'air d'avoir une doc correcte, et déjà  des applis concrètes.

    Regarde du côté de Rails aussi pour le dev web... j'aurais du mal à  revenir à  PHP.  ;)

    Redmine travail avec Ruby on Rails et ça rame pas mal (il y a deux instances d'Apache en Cluster) ! Je ne m'y suis jamais vraiment mis. Je connait même pas exactement le principe. Je reste sur PHP car c'est ce que je connait le mieux. En général, je ne change pas ce qui marche... Parfois le coût de l'apprentissage d'une nouvelle technologie est important et peu rentable (l'expérience parle) ;)
    Je promet rien, mais je vais y jeter un oe“il. J'ai entendu qu'une personne avais fait un site de mise en relation graphiste / développeur iphone en une journée ! C'est un beau score !
  • muqaddarmuqaddar Administrateur
    11:36 modifié #27
    Disons que ce que j'aime bien avec Rails c'est :

    - le langage ruby très agréable
    - obligé de bosser en MVC :)
    - les helpers qui font gagner bcp de temps
    - les centaines de plugins

    Pour les perfs, c'est kif kif...

    Ce que je n'aime pas :
    - pas ou très peu d'hébergeurs en France
    - la rétro-compatibilité avec les gems (plugins)
Connectez-vous ou Inscrivez-vous pour répondre.