Quelle technologie utiliser?

Flash un peu depassé?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonsoir à tous, Je me suis lancé dans le projet de faire une application web similaire à Prezi qui servirait à faire des diapos ou des animations, c est là son avantage par rapport à prezi. J'ai décidé d utiliser RoR car je suis habitué à ruby. J'ai déjà fait une système d'inscription login/ sign up et session. Mais je me pose une interrogation: quelle serait la meilleure technologie pour faire la partie édition/création d'animations et de diapos? Parce que prezi utilise flash mais cette techno commence à être assez ancienne et elle nécessite d'avoir flash d installé alors que html5 est natif sur de nombreux navigateurs notament mobiles… Qu'en pensez-vous? Je suppose que un couple JS/html5 va s'imposer même si j ai pas mal lu un peu partout que RoR intègre mal le js ( via coffee script). Merci de toutes vos réponses. :) Edit : je m'excuse par avance si je suis dans la mauvaise section…

Édité par GouleFutée

+0 -0

Un truc genre strut ou deckjs ou slides.com ?

A mon avis pas besoin de se casser la tête pour la liaison back/front. Laisse le front vivre sa vie de son côté et stocker les données en local storage, et crée un lien entre les deux uniquement lorsque l'utilisateur sauvegarde sa prés'. Et pour ça, tu lui envoies un JSON (par exemple) qui décrit la présentation, tu savegardes ça où tu veux (en base, dans une fichier, peu importe) et quand l'utilisateur se reconnecte tu lui envoies la liste de ses présentations en JSON (toujours).

Si tu veux changer de techno côté back, tu pourras changer sans problème. Si tu veux faire autre chose côté front (du elm, par exemple :) ) bah pareil. T'as une séparation franche entre les deux, c'est ton format JSON.

Happiness is a warm puppy

+0 -0
Auteur du sujet

Hum… Oui je comprends en plus l'architecture MVC de RoR est bien pratique… Donc un JSON qui sauvegarde toutes les données sur les diapos en DB et les lie avec les users correspondants… Mais du coup pour générer ces diapos(donc le front-side), quelle techno est préférable ?

+0 -0

T'as pas énormément de choix. A mon avis faut jouer avec du JS et éventuellement l'API canvas d'HTML5.

Après tu peux te faire plaisir avec n'importe quel langage qui se transpile en JS : typescript, coffeescript, Ceylon, ClojureScript, elm, si t'aimes pas trop le JS et que t'as envie de tester autre chose.

A mon avis il te faudra aussi une techno capable de construire des "webapps" (ou SPA, ou client-side application, ou n'importe quel autre mot). Là aussi t'as le choix des armes : Ember, Meteor, React, Angular2, … A toi de voir la philosophie que tu préfères et lequel offre le support le plus simple de l'API canvas. Après regarde aussi la "concurrence" c'est un secteur où y'a pléthore d'acteurs (typiquement tu peux regarder ce que font les 3 que j'ai mentionnés). Si tu fais ça dans un but académique, choisis la stack technique sur laquelle t'as envie de monter en compétence et fais-toi plaisir.

Happiness is a warm puppy

+0 -0
Staff

Bah coté front il y a pas des tonnes de choix hein. Si tu écarte flash (et tu as raison) il ne reste plus que html+js de viable. Après rien ne t’empêche d'utiliser une des nombreuses bibliothèques qui existe pour ce type de chose ou de prendre un autre langage qui transpile vers JS, mais fondamentalement à la fin ça utilisera ces technos.

+1 -0
Auteur du sujet

OK mais d après ce que j ai pu voir, j'ai l impression que l'utilisation d'Angular(parce que c'est celle que je souhaite utiliser) rend l utilisation de RoR totalement inutile vu que ça gère les échanges avec la bdd. Est-ce juste une impression? Ou suffit-il juste d inclure angular dans mes fichiers .html.erb et de garder mes controllers et models? Ou le faire en dur sans utiliser de Fw puisque ce n'est pas vraiment une SPA?

Édité par GouleFutée

+0 -0

Généralement quand on utilise Angular, le serveur Web est exposé sous la forme d'une API (et donc ne gère pas du tout le service de fichiers statiques), et l'application front-end est ailleurs (sur un autre serveur). Les deux sont complètement indépendants.

+0 -0

Tu les sépares en ayant deux serveurs différents (pas forcément physiquement, mais disons que le back-end sera accessible à api.tonsite.com et le front-end à tonsite.com).

On les fait communiquer avec des API, je te conseille de te renseigner à ce sujet. Néanmoins si tu n'es pas familier avec tout ça, commence doucement, parce que même si c'est une architecture moderne ça fait entrer en jeu beaucoup de nouveaux concepts. N'hésite pas à faire des tests avec des petits projets avant. :)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte