Reprise du message précédent :
sauf que ce n'est pas la solution que tu as décris un peu plus haut

là, tu en as deux ( dojo et le reste )

Quand a servir un fichier custom par page, ce n'est pas mieux que le code js en bas de page

 
C'était un cas hypothétique, là c'est un cas pratique. Bref, tu fais comme tu préfères.

Le code simple en inline, prêt des éléments auquel il se rattache.
Le reste (classes/objets) dans des .js
+ un petit <script> dynamique en haut/bas de page qui contient quelques variables générées côté serveur.
 

Si c'est juste pour ajouter un observer au domready (=99% des cas), ça gène pas.

 
Yuck c'est sale.
Si c'est pôur faire un :
 
jQuery('element').click(doSomething);
 
Autant le faire dans un fichier à part.

Pourquoi c'est sale ?

 
Ca bloque le chargement de la page à cet endroit là, c'est de l'éparpillage de code difficile à factoriser et maintenir, c'est une invitation à rajouter "juste un petit fix" qui se finira en spaghetti code. Et si par malheur ça touche au dom (même un simple attribut class) alors des browsers (ie entre autres) vont re-render toute la page pour rien.
 
Autant avoir un code propre et centralisé dès le départ.

moi y'a le bootstrap en inline, et tout ce qui est dans des fichiers séparés est namespacé.

Sauf que ça n'a aucun rapport avec ta déclaration d'origine ce setup

Ton cas hypothétique était con

Si ya un truc qui est de l'éparpillage de code, c'est bien de déplacer un code qui s'applique à un seul élément à 10 km de celui-ci.

Jamais eu ce pb, quand ça devient gros je crée un objet, et le problème est de toute façon le même si tu regroupes les domready.

Tu préfères regrouper le JS, je préfère regrouper par sujet.

On n'utilise jamais d'attribut class pour setter un domready.

edit : Et comment tu fais pour synchroniser le JS avec le contenu de la page ? t'as un système qui mémorise le JS "inline" et le sort en fin de page ? Ou t'as tout le temps le même JS, et tu mets des conditions (si tel élément existe alors tu fais ça) ?

ah heu moi je compresse mes fichiers JS en assemblages.
 
mon site c'est comme imgur, y'a une page d'index avec un répertoire et des pages d'items individuels, donc un assemblage de JS pour l'index (en fait 2 pour que le chargement de l'index bloque pas le stylage de l'upload) et un assemblage de JS qui est référencé par toutes les pages de détail.

Tu as compris ce que je voulais dire (et dire que ça n'a "rien à voir" est pour le moins de l'exagération). Mais si tu veux avoir raison je te l'accorde: tu as raison.

10km est la distance qui sépare un fichier inclus du code source? C'est de la mauvaise foi.

Alors tu n'as jamais bossé dans un grand projet où X personnes vont maintenir le code, et pas que des lumières. Keep it simple.

Je sais que "on n'utilise jamais d'attribut class pour setter un domready". Le rapport avec la choucroute?
Je ne comprends pas la suite. Que veux tu dire par synchroniser? Puisque je n'ai pas de js inline je n'ai pas à le mémoriser pour le regrouper.... C'est le serveur qui sert les fichiers utiles à la page en choisisant les pertinents...

 
Vous êtes bien obligés de maintenir un mapping, non ?

C'est pas de la mauvaise foi vu que c'est la raison pour laquelle je fais comme je fais
 

Je peux être d'accord sur ton premier point (je suis souvent seul sur mes projets) mais le "Keep it simple", pour moi le plus simple c'est ma façon de faire, qui est l'utilisation de base
 

Bah c'est toi qui dis qu'il faut pas utiliser de class directement dans un code inline.
 

Ah oui pardon je croyais que tu mettais du inline à la fin de ta page.
Dans ce cas comment tu organises les fichiers JS qui comportent le code non réutilisable ? un fichier par page ?

Un exemple fictif pour voir comment j'inclus du js:
monsite.com/page1.html incluera l'appel a page1.js. Le serveur va lui servir page1.js qui sera composé des include de tous les fichiers js pertinents.

Une autre page similaire pourra inclure aussi page1.js si il a besoin du même code, ou une autre. En général on crée un fichier js par page.

En pratqiue c'est un poil plus compliqué mais la logique est là: on se sert du nom de la page comme "clef de mapping".

Ca c'est pas ma question : avant le merge, où est le code non réutilisable (genre l'appel à swfobject qui va charger la seule anim flash du site)  ?

Je pensais pas susciter un tel débat Merci pour les réponses en tous cas, pour l'attachement d'event simples sur des pages uniques j'ai aussi tendance à faire comme theredled et à le coder directement dans la page HTML.

Les fichiers js globaux minimifiés + un js par page le tout minimifié dans un js, chaque page étant reconnue par un id.

Si t'avais une anim flash dans le header, tu mettrais où le JS associé à cette anim ? header-block.js ?

http://www.twig-project.org/documentation <- sexuellement attirant ou pas ?

je suis en train de regarder ça de pret ( en meme temps que symfony 2.0) et ça a l'air pas mal du tout

symphony utilise twig je crois. J'hésite et je pense que je vais arrêter mon combo limonade+smarty

ಠ_ಠ

En dehors de ça, c'est un port de Jinja2. Ils l'ont réimplémenté en PHP... et ont repompé la doc directement:
Jinja2

Twig

(toute la section semble avoir été repompée plus ou moins directement de jinja)

et si tu compares les markups, ils sont étrangement propres... sachant que la doc de twig indique:

pendant que la doc de Jinja2 sort directement de Sphinx. D'ailleurs la doc de Twig est en fait en rst (c'est fréquent dans un projet PHP?) mais sans les builders et la structures d'une doc sphinx. En fait ils ont pas l'air de fournir les outils pour builder la doc facilement...

I R NOT IMPRESSED

La question n'est pas là, c'est est-ce que ça poutre plus que smarty, est-ce plus intéressant à utiliser (genre smarty c'est mort, twig c'est plus récent, vive twig), etc...
 
Est-ce que je peux faire comme dans smarty, utiliser des fichiers pour la langue ?

T'as pensé à lire la doc? (hint: extensions > i18n)

pomper une bonne idee est une bonne idée  
gatsu : http://www.twig-project.org/doc/extensions/i18n.html   ?

J'dis pas que porter un bon template engine est une mauvaise idée (enfin vous auriez pas ce problème si vous codiez en Python ), mais récupérer la doc mot pour mot me semble un peu abusé, surtout sans attribution (la seule que j'ai trouvé est dans AUTHORS et liste Armin en "project founder". Je doute fort qu'il ait jamais bossé sur twig...)

je n'avias pas compris ton post dans ce sens
Maintenant je suis d'accord  

Bon ben apparemment Armin a bel et bien bossé sur twig, donc voilà

C'est pas grave, mais ce truc il a l'air aussi sexy que les fesses nues de flo850. Donc je pense que je vais passer dans un premier temps à silex (qui utilise twig).  
 
Mais d'abord je vais finir le truc que j'étais en train de coder en limonade/smarty.
 
Merci mes chéries

TWIG FTW \o/

ET SYMFONY 2 AUSSI \o/

 
Dans le js qui contient toutes les fonctions communes du site ?

 
au passage, je vais aller en formation symfony 2 en octobre

Quel organisme ?

directement par sensio labs  
http://trainings.sensiolabs.com/fr [...] -framework , le 12/13 octobre  
( là, j'ai un projet sur le feu qui va m'occuper jusqu'en septembre , ensuite je commence un autre projet en symfony 2 , la formation va tomber pile poil)

C'est pour les losers les formations

 
Va mourir.
 

 
Oué voila

N'empêche Yell, jpense que SF 2 c'est d'ici peu la bonne carte à jouer pour trouver du taf (et jpense aussi que tu le sais déja )

Mais clair \o/

Le code que tu mettrais en inline c'est des trucs du genre :

$('#foo').foobarize()

Si tu travailles sous forme de widget (ce que tu devrais faire anyway)

En réalité t'as deux cas :

• Soit ton code est systématiquement ou presque, utilisé sur toutes tes pages
• Soit il est utilisé un peu n'importe quand en fonction des pages (j'ai le cas pour un intranet ou y'a pas mal de templates incluses sans trop de controle sur le flux)

Dans le premier cas : tu utilises un truc comme django-compressor, du coup t'as des fichiers séparés en dev, et un seul fichier "versioné" en prod et la première page affichée te sert de bootstrap pour le cache.
Dans le second cas : un truc du genre de require.js

Ce que suggèrait gelatine est à éviter.

une fois de temps en temps, voir comment il faudrait faire plutot que le découvrir soit meme est un plus ( a la base, dans toutes mes études, je n'ai eu que 12h de developpement web te 12h de bases de données, j'ai plutot fait de l'apprentissage automatique )  
et les formation, ça sert aussi ( et surtout ) a rencontrer des gens  

   
 
Des développeurs en plus