Bonnes pratiques jQuery

steeve · 23-09-2013 09:31:38

Bonjour a tous !!!
Ça fait bien longtemps que je ne suis pas revenu sur ce forum mais c'est avec plaisir que je le retrouve aujourd’hui, je me souvient que les blagues étaient régulière et l'humeur très bonne, je souhaite que cela n'ai pas changé

Si non, depuis un bon moment déjà je bricole un framework 100% adaptatif.
J'utilise compass pour la gestion des css. Dans ce dossier compass j'ai un fichier de variables permettant de centraliser de nombreux réglage (jusque la tous va bien).
Les parties HTML et CSS sont déjà bien avancés et j'en arrive maintenant j'en arrive a l'intégration de jQuery dans le but de modifier certains comportement en fonction de la résolution.

J'ai une fonction qui permet du jouer avec les url (la aussi tous va bien), a part quelques paramétrages comme le chemin du dossier css et le choix des devive, ça va l'entretient est la mise en place sont limités...
En revanche, pour le menu (qui s'adapte aussi) la j'ai des soucis de choix sur l'utilisation de jQuery, le menu fonctionne très bien mais je me pose des questions.

Comme je l'ai dis au début, j'ai un fichier de variable ou je peux jouer avec certaines propriétés CSS "MAIS" jQuery m'offre tellement de possibilités que que je dérègle un peut mon principe de simplicité d'administration...
J'ai l'impression qu'il est plus simple dans mon cas d'utiliser: $('#' + id).addClass() que $('#' + id).css() qui me permet de jouer avec mon fichier CSS plutôt qu'avec le fichier JS auquel je ne voudrais plus toucher !

Voici donc ma question, y a t'il ou connaissez-vous des règles ou bonne pratiques de ce genre ?
Je suis preneur de tous conseils ou techniques

Merci d'avance, a plus.

Jc · 23-09-2013 14:00:26

Bonjour,

Tout ça m'a l'air intéressant
Permettez-moi juste quelques questions

Si non, depuis un bon moment déjà je bricole un framework 100% adaptatif.

Pour faire quoi?

J'utilise compass pour la gestion des css

Qu'elle est l'intérêt et l'apport fonctionnel apporté à votre Framework? D'autant que compass oblige à l'installation d'une distribution spécifique côté serveur qui peut le rendre incompatible dans un contexte d'hébergement mutualisé.

En revanche, pour le menu (qui s'adapte aussi) la j'ai des soucis de choix sur l'utilisation de jQuery

Rendre dépendant votre Framework de jQuery c'est bien, mais cela vous obligera à faire évoluer votre Framework en fonction des évolutions de jQuery.
Donc face à une telle contrainte, quel est l'apport de votre Framework face à jQuery?

je dérègle un peut mon principe de simplicité d'administration

Compass nécessite des compétences supplémentaires pour l'utilisateur, qui peuvent ne pas paraître simple pour un simple utilisateur de CSS3, donc votre affirmation reste relative tout de même. De là comment vous concevez/définissez l'administration de votre Framework?

J'ai l'impression qu'il est plus simple dans mon cas d'utiliser: $('#' + id).addClass() que $('#' + id).css() qui me permet de jouer avec mon fichier CSS plutôt qu'avec le fichier JS auquel je ne voudrais plus toucher !

Ces deux fonctionnalités n'ont pas le même rôle ni impact au niveau du code, et dans une application web moderne, les deux restent utiles pour ne pas dire nécessaires, et faire l'impasse sur l'une ou l'autre reste une mauvaise solution.
Quand vous dites ne plus vouloir toucher au fichier JS, lequel parlez-vous? dans quel contexte? et quel est son rôle dans votre Framework?

Merci pour vos réponses.

++

steeve · 23-09-2013 14:55:21

Bon, quand je dis framework, c'est en fait un mot plus gros que celui que j'aurais du employer...
C'est en faite une base de départ html et css plus un peut de js
- Un reset + une base css
- Une grille de 16 colonnes en %
- Un dossier scss très structuré
- Certaines fonctions js comme modifier certaines url(media, css, img, video...), aligner des colonnes a la même taille avec une classe, un menu adaptatif et quelque autres trucs qu'ils n'est pas nécessaire de modifier d'un site a l'autre...
En revanche, d'un site a l'autre, il faut pouvoir toucher aux css et c'est dans ce sens que je ne souhaite pas y revenir...

En ce qui concerne compass, il n'est pas prévu de l'installer sur le serveur, il ne me sert qu'a sur-structurer les classes css comme celle du menu, des alertes, du contenu ou header dans plusieurs dossiers avec une hiérarchie qui me convient... Ce système me permet aussi de générer plusieurs fichiers css qui sont utilisés avec js en fonction des besoins...

Si non, pour ce qui est du but, bien c'est le plaisir de créer une base qui me convienne et honnêtement l’intérêt général n'est absolument pas la distribution ou peut être un jour, sais t'on jamais !!!

Si autre chose, je ne peux plus me passer des mixins qui me permette de rendre mon html un peut agréable a lire tout en limitant le nombre de règles css a écrire...

Voila en gros, pour finir, je cherche a réer une base de classe css et fonction js utilisable sur de nombreux sites en limitant les modifs a quelques paramétrage comme les font, color, size contenu dans un fichier variable

merci de votre intérêt.

Jc · 23-09-2013 15:21:29

Bonjour,

Juste une petite précision, compass utilise sass pour fonctionner du côté serveur (initialement prévu avec ruby on rails) et compile le code pour générer des css dynamiquement délivrées au navigateur statiquement. Le navigateur n'étant pas capable d'interpréter le code propre à compass, mais uniquement du CSS3 ou inférieur.

Pour le reste, merci pour vos précisions, mais décidément vos objectifs avec votre structure applicative standard et comment vous avez conçu votre environnement "statique" pour standardiser vos applis, restent très obscures pour moi.
Si votre but est de découper votre affichage en un tableau de 16 colonnes sur 100% de largeur, pourquoi avoir choisi 16 colonnes, ce nombre n'étant même pas multiple de 100?

Donc désolé, mais je ne suis pas du tout.

++

Dernière modification par Jc (23-09-2013 15:22:09)

steeve · 23-09-2013 15:44:31

Ah, je vous ais mal compris, mais aussi expliquer simplement...
Par serveur, j'avais compris serveur en ligne... Bien entendu qu'il fait compiler, je travail avec wamp et je compile avec l'invite de commandes...

pour ce qui est de la grille, elle est de 16 colonnes et 15 marges de 2%:
100 - (15 * 2%) = 30 reste 70
70 / 16 = 4.375 %
voici la mixin:

@mixin bloc-colonnes($couleurFond, $colonne, $fin: non){

    background: $couleurFond;

    display: inline; 

    float: left;

    width: $colonne * 4.375% + (($colonne * 2%) - 2%);

    @if $fin == "fin"{

        margin: 0;

    }

    @else{

        margin: 0 2% 0 0;

    }

}

Pour ce qui est de la structure, une capture s'impose: http://i70.servimg.com/u/f70/13/05/90/60/captur10.png
le dossier éléments n'est pas ouvert car trop grand pour voir le haut et le bas mais il contient des fichiers dédié a une série de règles css comme le menu, les alertes, le tooltype et d'autre encore...

Voila, espérant combler ta curiosité, je suis ouvert a toutes critiques ou erreurs ca va de soit !

steeve · 23-09-2013 15:55:34

Ah juste pour finir, voici une autre capture: http://i70.servimg.com/u/f70/13/05/90/60/captur11.png

Jc · 23-09-2013 16:10:35

Bonjour,

Après avoir vu vos captures, je pense deviner l'objectif. Donc corrigez-moi si je me trompe, mais il me semble que vous cherchez à faire un environnement standard de type responsive pour tout environnement mais en particulier pour environnement mobiles.

Si tel est le cas, je ne sais pas si votre expérience dans ce domaine est grande, mais en ce qui concerne un environnement desktop, je trouve l'approche non appropriée.
En effet, ce pré-découpage peut rendre l'intégration de chartes graphiques rapidement complexe. De plus, dans un contexte HTML5, le "calage" des éléments constitutifs de l'affichage (conteneurs primaires ou élémentaires de l'affichage) se fait par margin et non via padding comme sur n'importe quelle autre DTD ou presque, ce qui complique encore l'intégration dans le contexte de votre approche.

Sinon pour des supports plus restreints comme les tablettes, l'interface étant généralement plus légère, pourquoi pas en effet, mais je la trouve gourmande en calcul et cela risque de réduire les perfs inutilement sur ce point. Il faudrait faire du benchmarck sur un environnement classique applicatif, pour avoir des certitudes, mais je suis à peu près certain, que vous serez derrière d'autres solutions existantes, du moins sur cette partie.

++

steeve · 23-09-2013 16:33:43

Il est vrai que mon expérience mobile est un peut juste ainsi que celle de jquery mais bon, c'est un peut mon exercice pour apprendre...
Pour ce qui est des perfs, en effet il est possible qu'il faille changer des choses et je ferais des tests bien entendu...

L'idée principale n'est pas forcement l'environnement mobiles mais plutôt de ne pas charger ce qui ne convient pas a la résolution d'affichage(images, css...) les images, par exemple ne sont chargé qu’après jquery pour être sur de la prendre dans le dossier correspondant a la résolution en cours...

La partie desktop n'est en fait plus utilisé, c'est devenu le css principale "style.css" qui lui est afficher pour toutes les résolutions, j'ai quand même garder les fichiers et la fonction js intacte au cas ou je revienne en arrière plus tard...

Par contre je ne comprend pas gourmand en calcul, je ne dis pas que vous vous trompez, vraiment je ne comprend pas ?

Jc · 23-09-2013 17:22:11

Bonjour,

Pour la partie gourmand en calcul, voir le dernier message de ce post qui date de quelques temps déjà.
Ensuite du Template complexe nécessite toujours un calage au pixel près au niveau de l'affichage, ce qui implique que l'on doit toujours travailler avec des valeurs entières, et qui dans votre cas, peut provoquer des effets de bords difficiles à résoudre.

L'idée d'aller prendre l'image dans le dossier correspondant à la résolution en cours, est sympathique je le reconnais, l'idée me plaît. Cependant, il ne faut pas perdre de vue que ce n'est pas à l'environnement de décider de ce genre de choses mais au cahier des charges métier de l'application. En général les images nécessitent une gestion indépendante (sur un plan technique) du reste de l'applicatif, car les dimensions vont dépendre non pas exclusivement de la surface d'affichage mais d'abord de l'information à rendre à l'utilisateur, car son expérience doit rester maîtrisée au regard des objectifs et contraintes de vente. Par contre je vous rejoins sur le fait que l'application doit pouvoir trouver l'image qu'elle a besoin dans l'arborescence sans passer par sa base de données pour avoir de la performance (parmi quelques autres points), tout comme le fait prestashop d'ailleurs soit dit en passant.

++

Dernière modification par Jc (23-09-2013 17:39:52)

steeve · 23-09-2013 17:48:27

Ok, je comprend le temps du calcul !!!

Pour les images, il n'est pas nécessaire d'utiliser le code js, si en cas de besoin l'image doit changer d'url, il suffit de l'écrire comme ça: <img src="" data-nom="resolution.png" class="hidden" alt=""/> et dans ce cas elle est prise en compte, je signale que je compte changer cette façon d'appeler l'image au moyen d'une autre balise mais je ne sais pas encore la quel...

Pour les reste hé bien je vais réfléchir a tous ça, et dés que j'aurais réussi a faire fonctionner jQuery sur IE9 pourtant ca fonctionne avec IE7, IE8, IE10 , il ne me restera que quelques réglages et faire des test et je pourrais vous le faire tester si vous le souhaitez...

kia kha · 28-03-2015 08:06:38

J'ai volontairement mis invoice_number = '1' (alors que j'aurais du mettre invoice_number = '0') pour voir si j'obtenais une erreur et non, l'update demandé ne se fait pas mais aucune erreur n'est retournée !? J'aimerais comprendre pourquoi, comment testé si les données ont bien été mises à jour (un truc du style if(mysql_error() != 0) echo 'erreur'; n'existe pas ?)

PHP|Débutant :: Forums

Advertisement

#1 23-09-2013 09:31:38

Bonnes pratiques jQuery

#2 23-09-2013 14:00:26

Re : Bonnes pratiques jQuery

#3 23-09-2013 14:55:21

Re : Bonnes pratiques jQuery

#4 23-09-2013 15:21:29

Re : Bonnes pratiques jQuery

#5 23-09-2013 15:44:31

Re : Bonnes pratiques jQuery

#6 23-09-2013 15:55:34

Re : Bonnes pratiques jQuery

#7 23-09-2013 16:10:35

Re : Bonnes pratiques jQuery

#8 23-09-2013 16:33:43

Re : Bonnes pratiques jQuery

#9 23-09-2013 17:22:11

Re : Bonnes pratiques jQuery

#10 23-09-2013 17:48:27

Re : Bonnes pratiques jQuery

#11 28-03-2015 08:06:38

Re : Bonnes pratiques jQuery

Pied de page des forums