Comment bien organiser ses fichiers JS

[php_addict]

Perso, je décompose selon le schéma suivant:
- Un dossier "JS" qui regroupe tous les fichiers JS (pas de JS en dehors)
- Un sous-dossier par "classe" ou par "thème"
- Un fichier JS par fonction / méthode dans ces sous-dossiers

Par exemple:
JS/carte/__constructor.js
JS/carte/charger.js
JS/carte/afficher/case.js
JS/carte/afficher/toutafficher.js
JS/batiment/__constructor.js
...

Ensuite, j'ai un fichier php qui est capable de browser JS/* et de collaber tous ces fichiers en un seul fichier JS. Ce fichier JS peut alors être allégé (en supprimant les commentaires, les lignes vides, les espaces, etc). C'est ce fichier JS qui sera utilisé dans les pages webs.

Ainsi:
- les clients webs n'ont qu'un seul fichier JS de visible, ce fichier est également léger et peut être mis en cache
- les développeurs peuvent manipuler les JS séparément avec une structure assez claire et des fichiers légers, mais nombreux
- les développeurs peuvent modifier ces fichiers JS sans impacter directement le serveur de prod
- il est possible d'archiver les JS ainsi "compilés" (fusionnés) pour un versioning

Mais je suis pas certain d'avoir compris la question :p

oui je fais un peu dans le même style

Mais je suis pas certain d'avoir compris la question :p

oui effectivement, ma question etait plus concernant l'encapsulation, car j'ai revu tout les scripts php pour me servir de l'orienté objet pour tout bien encapsuler, du coup tout est plus clair, plus maintenable, et avec l'autoload ca roule d'enfer...je me demandais si en javascript il était possible de bien encapsuler le code, histoire que le fichier JS qui regroupe tout les fichiers JS ne soit pas un sac de noeud. Ma question est elle plus clair?


concernant le code proposer par Xenos il y a aussi http://code.google.com/p/jsmin-php/

Voici la structure que j'utilise à ce jour pour Seelies. C'est une application Marionette (une extension de Backbone) écrite en CoffeeScript (compilé à la volée en Javascript) et les templates sont écrit en Haml.

merci pour ta longue réponse, je vais me pencher sur la question, mais quel est l'interet réel de CoffeScript?

merci à tous pour vos réponses

[Sephi-Chan]

Voici la structure que j'utilise à ce jour pour Seelies. C'est une application Marionette (une extension de Backbone) écrite en CoffeeScript (compilé à la volée en Javascript) et les templates sont écrit en Haml.

merci pour ta longue réponse, je vais me pencher sur la question, mais quel est l'interet réel de CoffeScript?

merci à tous pour vos réponses

CoffeeScript n'est qu'un gros sucre syntaxique. Son seul intérêt est de réduire considérablement le volume de code et de le rendre très expressif, donc plus facile à lire et à maintenir.

J'invite tout le monde à lire la page de présentation. Ça prend moins de 30 minutes et si vous l'adoptez, ça vous en fera sûrement gagner beaucoup.

[Maks]

C'est propre ce que tu fais mais je comprends pas comment on peut préféré l'héritage par mixin plutôt que prototypal pour Backbone via Coffeescript

Du coup moi je vois ça plutôt rangé dans des classes et espaces de nom.

Par exemple pour du Backbone "simple" :

├── app

│   ├── collections

│   │   ├── messages.coffee

│   ├── models

│   │   ├── message.coffee

│   ├── routers

│   │   ├── main.coffee

│   ├── views

│   │   ├── messages.coffee

│   ├── templates

│   │   ├── message.jade

namespace App:Collections:

  class Messages extends Backbone.Collection

    model: App.Models.Message

namespace App:Models:

  class Message extends Backbone.RelationalModel

namespace App:Routers:

  class Main extends Backbone.Router

namespace App:Views:

  class Messages extends Backbone.View

    template: JST['message']

table

  for model in models

    tr

      td {model.text}

[niahoo]

Bon du coup je vais me faire un petit script auquel je passe une liste de fichiers javascript pour qu'il me les concatène tous séparés pas un saut de ligne (+ un ;) et qu'il les compile ensuite avec closure compiler.

Je viens de le faire à la main avec les scripts actuels de mon jeu, je suis passé de 30 à 6 kb non zippés et il n'y a aucune différence de comportement dans l'appli, donc c'est nickel !

---

vu que je trouve pas de version de sprockets en erlang


Edit : bon bah je vais juste mettre mon script à la poubelle vu qu'on peut passer autant de fichiers qu'on veut au compiler et qu'il se charge lui-même de rajouter les ; manquants .