Comments (5)
Merci d'avoir soulevé ce point !
Il y a 2 notions que nous voulons respecter sur ce projet :
- A terme, l'application doit être utilisable partiellement hors ligne. C'est à dire qu'une fois un épisode chargé, l'utilisateur pourra y accéder même en étant déconnecté. S'il veut enchainer sur l'épisode suivant, il devra ponctuellement retrouver une connexion. Le noyau n'est pas encore au point là dessus, mais cela fait partie de notre ambition.
- le projet doit être utilisable en local, principalement pour faciliter la vie des intervenants (créateur d'histoires ou autres), mais non pour l'utilisateur final. Nous ne proposerons pas aux gens de le télécharger pour y jouer localement (et ce, car des épisodes viendraient s'ajouter régulièrement).
PrefixFree nous pénalise sur ce point sauf sur Firefox (pour les autres navigateurs, cf http://leaverou.github.io/prefixfree/#local-xhr)
La remarque est donc pertinente, gardons l'Issue ouverte pour l'instant.
from docky.
Je viens de regarder ce qui est indiqué sur ton lien. C'est en effet assez contraignant :/ Sachant qu'il n'y a pas que prefix-free qui pose problème mais également le chargement des histoires, car dans le core c'est fait avec getJSON donc XHR.
Est-ce qu'il n'y aurait pas moyen de patcher ça en utilisant les nouvelles API JS ?
http://www.html5rocks.com/en/tutorials/file/filesystem/
Sinon après dans l'absolu il suffit d'indiquer les mêmes choses que sur le site de Prefix Free et puis voilà, mais ça n'est pas totalement satisfaisant je pense.
from docky.
Avant d'expliquer ma propre vision des choses, je vais tenter de résumer les 4 utilisations possibles du "framework".
- Mode online : l'utilisateur se rend sur une url externe et consulte les histoires, sans aucune contrainte technique
- Mode offline : l'utilisateur (après un chargement d'épisode réussi) retourne sur l'url externe et, grâce au local Storage, peut toujours jouer.
- Mode debug : un développeur passant par là veut forker le projet (il aura besoin d'un serveur http local type Apache)
- Mode local : un auteur passant par là enregistre le zip, pour jouer avec (toutes les ressources sont donc local, côté client)
Le mode local est clairement incompatible avec la partie XHR (qui pourra évoluer par la suite).
Si l'on tente avec ces nouvelles API filesystem, nous répondrons au mode local mais perdrons la compatibilité avec les 3 autres modes (où les ressources ne sont pas côté client). Il semble impossible de marier ces 4 modes.
Ce qui nous ramène finalement à la question : quelle est l'utilité du mode local ?
Après réflexion, voici ma réponse
- Pour l'utilisateur lambda, aucune. Nous ne lui proposerons pas de télécharger de zip.
- Pour l'auteur (qui ne sait pas ce qu'est Apache), ça lui permettrait de tester son propre fichier Json.
Suggestion de contournement : une page test (disponible online) sur laquelle on peut fournir son fichier Json et cela charge l'histoire avec les ressources fournies. Cette page test s'appuiera probablement sur les nouvelles API filesystem.
Autrement dit, je pense qu'il ne faut pas essayer de rendre le mode local possible, il faut plutôt fournir tous les outils au créateur d'histoires (avec l'interface et l'ergonomie qui conviennent), et l'aider à se concentrer sur la création de contenu et non sur les contraintes techniques.
Malgré tout, il est possible de décliner le code pour qu'il fonctionne en local, mais cela revient à sacrifier un grand nombre de fonctionnalités. C'est pratiquement une version alternative du projet, et sûrement la moins intéressante.
from docky.
bonjour
je ne sais pas si c'est a cause du --allow-access-from-files
mais je viens de tester docky et ça marche sous chrome en version hébergé, mais avec ce que j ai téléchargé de github ca bloque et ne m affiche pas la fleche play et le menu option.
même en activant --allow-access-from-files
j ai bien vérifié que chrome était lancé en allant avec le bon flag en allant sur la page chrome://version/
je trouve que c est un projet bien pratique pour que les enfants puissent programmer en html5
merci
from docky.
Salut,
Personnellement, j'ai mis "security.fileuri.strict_origin_policy;false" sur firefox (dans about:config), et je n'ai aucun problème en local mise à part des erreurs de JSON mal formés qui ne stop en rien la progression de le bon déroulement de l'aventure.
from docky.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docky.