IPB

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> MVC, htaccess et site "multi-parties"...
Options
toluol
posté 18 May 2016, 23:27
Message #1


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Je me forme actuellement au développement d'une architecture MVC (avec url-rewriting), et j'avoue que je suis un peu perdu quant à l'htaccess qu'il faut écrire si je souhaite organiser mon serveur avec des sous-parties. Du genre :

monsite.com -> site principal
monsite.com/admin -> une autre partie
monsite.com/e-shop -> une autre partie
monsite.com/pro -> une autre partie

chacune de ces sous parties auraient son propre MVC. Le premier soucis, évidemment, c'est que le nom de ces sous-parties ne doivent absolument pas avoir le même nom qu'un controller sur le site principal... Mais ensuite, est-ce dans l'htaccess à la racine du serveur qu'il faut définir les règles des sous-parties ?

Pour l'instant, j'ai appris à mettre un htaccess à la racine du serveur, pour rediriger le site principal vers un dossier spécifique :
Code
RewriteEngine On
RewriteRule (.*) webroot/$1 [L]


et dans ce dossier webroot (qui contient tout mon site principal), j'ai un autre htaccess :
Code
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) index.php/$1 [L]


j'imagine donc qu'il me faut utiliser ce premier htaccess dans chaque sous-parties (elles auront toutes un dossier webroot), le deuxième htaccess écrit ci-dessus, je peux l'utiliser dans chaque webroot, et il me manque plus que l'htaccess à la racine du serveur ? Sans doute quelque chose comme :

Code
RewriteEngine On
RewriteRule ^admin\/(.*) admin/webroot/$1 [L]
RewriteRule ^e-shop\/(.*) e-shop/webroot/$1 [L]
RewriteRule ^pro\/(.*) pro/webroot/$1 [L]
RewriteRule (.*) webroot/$1 [L]


Ou bien ce n'est pas une bonne manière de faire ? Il se peut en plus que ces sites soient multilingues... (ce qui complique encore un peu plus les choses)
Merci d'avance pour vos remarques.
Go to the top of the page
 
+Quote Post
Chris68
posté 1 Jun 2016, 15:37
Message #2


Nouveau Membre


Groupe : Membres
Messages : 1
Inscrit : 1 Jun 2016
Membre no 198 969



A ce que j'ai compris, les 2 notions servent différemment dans la construction d'un site internet:
- Htaccess: permet de fixer les droits et de reécrire les URL,
- MVC: permet d'organiser le code source de ses scripts PHP par exemple.

Ainsi, il n'est pas nécessaire d'organiser son site internet à l'aide du fichier htaccess en fonction de son architecture mvc, voici une illustration
par exemple l'url http://monsite.com/e-shop peut pointer vers n'importe quelle partie du site en interne, c'est juste pour faire 'jolie' pour l'internaute.
Vous pouvez choisir l'organisation interne du site qui vous convient sans se préoccuper de la structure des URL fixée à l'aide d'un htaccess.

Du point de vue de l'achitecture, on essaie de ne pas trop multiplier les fichiers htaccess car en terme de maintenance ou de changement d'url ça devient un peu galère wink.gif
Go to the top of the page
 
+Quote Post
toluol
posté 1 Jun 2016, 16:23
Message #3


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Citation (Chris68 @ 1 Jun 2016, 16:37) *
Ainsi, il n'est pas nécessaire d'organiser son site internet à l'aide du fichier htaccess en fonction de son architecture mvc


Hello. Oui, j'avais commencé à comprendre tout cela... Entre temps, j'ai fait un détour d'apprentissage avec le framework Codeigniter... Le fichier de config routes.php permet justement ces redirections.

Je trouve juste que ça devient assez complexe à gérer avec les sites multilingues (c'est ce que je teste en ce moment). Car dans l'idée, j'ai compris qu'il peut y avoir un controller par défaut et qu'on peut juste appeler mon-site.com/fr/nom-de-ma-page et faire en sorte qu'il affiche la page en question "sans faire directement référence au controller" dans l'URL.

Après, pour l'évolutivité du code et obtenir que mon-site.com/en/page-name retrouve le même controller, je me demande si ce serait une bonne idée de déterminer les controller par défaut de chaque page dans ma base de donnée. Ainsi, lors de chaque chargement de page, je prend la langue en premier paramètre de l'url, vérifie si le slug de la page existe dans cette langue et retourne le nom du controller à charger...

Que pensez-vous de cette technique du "tout en base de donnée" ? Cela fait une requête de plus à chaque page visitée... Sinon, peut-être que je peux déterminer mes controllers par défault dans ma base de données, mais que cela écrive le fichier routes.php avec les bonnes regex (ça me semble encore plus "chaud"...)

Ce message a été modifié par toluol - 1 Jun 2016, 16:24.
Go to the top of the page
 
+Quote Post
yponomeute
posté 1 Jun 2016, 16:55
Message #4


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 4 969
Inscrit : 26 Jan 2011
Lieu : Pollachius virens
Membre no 164 083



Citation (toluol @ 19 May 2016, 00:27) *
Je me forme actuellement au développement d'une architecture MVC (avec url-rewriting), et j'avoue que je suis un peu perdu quant à l'htaccess qu'il faut écrire si je souhaite organiser mon serveur avec des sous-parties. Du genre :

monsite.com -> site principal
monsite.com/admin -> une autre partie
monsite.com/e-shop -> une autre partie
monsite.com/pro -> une autre partie


J'ai du mal à suivre là. Tu veux héberger 4 sites distincts, donc 4 instances de codeigniter ?


--------------------
MBP 2017 15" avec clavier pourri et touchbar inutile
Go to the top of the page
 
+Quote Post
toluol
posté 1 Jun 2016, 18:07
Message #5


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Non, plus maintenant, car j'ai compris à présent que cela était possible sans dupliquer les choses à ce point...

Mais cela reste encore compliqué dans ma tête.
Je souhaiterais par exemple que tous ces liens soient possible sur un même domaine :

mon-site.com/ -----> site de base, index, langue par défault
mon-site.com/fr -----> site de base, index, langue spécifique
mon-site.com/fr/ma-page -----> site de base, page spécifique, langue spécifique
mon-site.com/fr/search/methode/ma-recherche -----> site de base, langue spécifique
----------
mon-site.com/admin -----> partie admin, index, pas de langue déterminée
mon-site.com/admin/users/insert -----> partie admin, controller user, méthode insert
----------
mon-site.com/fr/blog -----> autre partie de site, index, langue spécifique
mon-site.com/fr/blog/ma-page -----> autre partie de site, page spécifique, langue spécifique
mon-site.com/fr/blog/search -----> autre partie de site, controller spécifique

C'est effectivement dans l'idée de faire "joli" * (et d'éviter de mettre des noms de controller et de méthodes dans une autre langue que celle en cours)
Mais divers problèmes se posent...
- Il faudra notamment faire des contrôles lorsqu'on crée de nouveaux controllers ou de nouveaux slug de pages pour que ce soit des noms uniques.
- Que se passe-t-il si une partie n'a qu'une langue, d'autre est multilangue (l'admin, en général, n'a qu'une langue...)

edit :
* et d'avoir l'url le plus efficace possible pour le référencement des pages (mon-site.com/page/1256 n'étant pas terrible et mon-site.com/page/view/1256/nom-de-ma-page à peine mieux)


Ce message a été modifié par toluol - 1 Jun 2016, 18:10.
Go to the top of the page
 
+Quote Post
No6
posté 1 Jun 2016, 19:15
Message #6


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224



>> C'est effectivement dans l'idée de faire "joli" *

l' URL rewritting c'est principalement utile au niveau du référencement des sites, le coté esthétique est franchement secondaire, et les internautes font rarement attention à ce qui est présent dans une URL.

Et rien n’interdit de faire d'utiliser l'URL rewriting de manière complètement basique et finissant par pointer toujours vers une seule et même page PHP qui elle analyse l'URL etr appelle les incudes u concernés.
Mais c'est juste une méthode parmi des tas d'autres.

Perso j'ai une nette préférence pour les sites mono pages et tous les changements de pages en passent par des appels ajax, ce qui n’empêche pas d'utiliser des push dans l'historique et juste quelques lignes dans un htacess si on veut masquer les mots cles
Ca fait des sites beaucoup plus fluides aussi.


--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
toluol
posté 1 Jun 2016, 19:31
Message #7


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Citation (No6 @ 1 Jun 2016, 20:15) *
Perso j'ai une nette préférence pour les sites mono pages


... Alors, j'ai plusieurs questions par rapport à tes remarques :
- Donc toi, tu n'utilises pas de MVC, ou alors si, mais un MVC-javascript ? ...comme AngularJS ?
- Je comprends bien l'intérêt des sites monopages pour le référencement "de la première page", mais n'est-ce pas sacrifier le référencement sur toutes les autres pages (appelées en ajax, et donc invisible aux yeux de google... Je sais qu'il n'y a pas que lui, mais...)?
-Et enfin, le pushstate, est-ce que cela fonctionne dans tous les navigateurs ? utilises-tu un plugin particulier pour ça ?

merci encore pour tes lumières
Go to the top of the page
 
+Quote Post
No6
posté 1 Jun 2016, 22:50
Message #8


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224



Citation (toluol @ 1 Jun 2016, 20:31) *
>>


>> -Et enfin, le pushstate, est-ce que cela fonctionne dans tous les navigateurs ? utilises-tu un plugin particulier pour ça ?
==> http://caniuse.com/#search=pushstate

Bien sur que non, le pushstate ne fonctionne pas sur tous les navigateurs. mais à un moment ou à un autre, on finit par devoir faire un choix.
Par exemple, maintenant je ne fais plus que du HTML5.

Tout dépends surtout du public que tu vise, et il doit y avoir des stats quelque part pour savoir le nombre de Pc sous Windows 2000 et n'utilisant uniquement EI5.
mais pour moi, je ne vois pas vraiment ce que mes sites peuvent leur apporter.
Je n'ai rien contre eux, et j'adorerai que Jules Vernes puisse surfer sur l'un de mes sites, mais à mon avis, ça n'est pas possible.

sinon, il y a aussi la technique utilisant les ancres.

>> - Je comprends bien l'intérêt des sites monopages pour le référencement "de la première page", mais n'est-ce pas sacrifier le référencement sur toutes les autres pages (appelées en ajax, et donc invisible aux yeux de google... Je sais qu'il n'y a pas que lui, mais...)?

ben non, si tu fais bien ton job, en entrant n'importe quelle URL copiée d'un "pushstate", cela reproduit la même page que celle reproduite à la suite d'un appel Ajax; donc pour Google et autres moteur de référencement / recherche, cela revient au même qu'un site multipages.

>> - Donc toi, tu n'utilises pas de MVC, ou alors si, mais un MVC-javascript ? ...comme AngularJS ?

Il y a des tas de frameworks js, même équivalents à Angular et respectant quelques patterns dont le MVC.
c'est même l’embarras du choix.

Le premier problème d'Angular, c'est que Google abandonne progressivement la version 1 pour la version 2, et qui n'est pas vraiment compatible.

Ensuite je ne trouve pas qu'Angular soit vraiment performant sur les "gros" sites. Ou alors cela demande un énorme investissement pour tout bien huiler, et je trouve que c'est du délire comme investissent mental pour un truc qui est sensé te simplifier le code, et qui à terme constitue une pile de connaissance en voie d'obsolescence quand la version 2 sera devenue incontournable.

Alors tant qu'a faire autant regarder du coté d'autres FramesWorks, y a du choix.

Perso, je ne fais pas des sites très gros, alors je n'ai pas besoin de la cavalerie. Il y aussi le fait que mes sites ont une durée de vie variable et plutôt courte. Je ne sais pas si tu a remarqué, mais le design (et autre) des sites ne cesse de bouger.
Internet, pour les boites commerciales ce n'est juste qu'une vitrine, et une vitrine il faut la changer souvent.
J'ai ma petite panoplies d'outils perso, ce n'est pas vraiment un framework non plus, ce qui n'interdit pas d'avoir mes réglés d'écriture, et il ne faut pas oublier non plus que JavaScript ou PHP sont aussi des langages objet ( et de base, les objets sont fait pour être réutilisables eux aussi).

Et perso, le MVC c'est très bien, mais cela impose d'en passer par des tables pour les données, et ca me gave, les perfs en sont dèjà pénalisées, je préfère paramètrer l'appel au PHP pour que les données soient dans le bon sens des le début.
Pour moi, ce sont les perfs d'abord, et mes sites ne sont pas fait pour avoir de la maintenance, et ne vivent que le temps d'une mode.





--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
No6
posté 1 Jun 2016, 23:14
Message #9


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224




Et j'oubliais,
Je ne sais pas si tu à lu mes anciens post ici, mais je fais souvent référence au site codrops ( http://tympanus.net/codrops/ ) sur lequel je pique souvent des idées, pour rester "à la mode".
Et tous ces trucs en JS ne sont pas compatible avec le moindre framework JS happy.gif


--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
scoch
posté 2 Jun 2016, 08:23
Message #10


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 4 800
Inscrit : 1 Jul 2010
Membre no 156 073



À noter que dans le cas de la solution tout AJAX, donc tout JavaScript, cela pose un problème d'accessibilité. Il faut alors que le site fonctionne sans AJAX pour être accessible et avec AJAX pour ceux chez qui JavaScript est activé. Mettre à jour l'URL avec pushstate, c'est un bon début mais pour un bon référencement il faut que la balise title et des meta soient uniques… À moins de vouloir de belles transitions entre les pages, opter pour du tout AJAX va te compliquer la vie. Sans AJAX, avec une bonne optimisation des requêtes SQl, un ordre de chargement de fichiers judicieux, des images très bien compressées et une bonne mise en cache, le changement de page peut être très rapide.


--------------------
L'homme n'est que poussière... c'est dire l'importance du plumeau ! Alexandre Vialatte
Go to the top of the page
 
+Quote Post
toluol
posté 2 Jun 2016, 09:24
Message #11


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Merci No6 pour ta large réponse ! smile.gif

Bon, ce qui n'est pas cool, c'est que tu remets un peu le doute en moi concernant l'utilisation du javascript, et BEAUCOUP l'utilisation d'un framework.

Concernant le javascript, j'ai toujours voulu l'utiliser comme une couche supplémentaire qui ajoute de l'interactivité et de la responsivité au site et qui améliore son ergonomie et sa vitesse de chargement. Ce qui, somme toute, est bel et bien indispensable à un site moderne. Mais je pense toujours qu'il faille l'utiliser comme une "couche supplémentaire". Mes site sont donc accessibles sans javascript.

Si pour des petits sites vitrine qui durent 2-3 ans, l'utilisation du "tout javascript" peut être envisageable, je le vois déjà plus mal pour des parties admin ou de gros sites sensibles. Bon, je n'ai nul l'intention de faire un site bancaire ou de refaire le site d'Apple (je me demande toujours combien de personnes sont dessus en permanence pour le développer laugh.gif )

Donc, je sais que perso, mon noyau sera le php.

C'est plutôt pour le framework que je me pose toujours des questions. J'ai longtemps fait des sites où, même s'ils fonctionnaient très bien pour l'utilisateur final, je les codais n'importe comment en terme de "réutilisabilité" du code. Je souhaite juste changer cela pour ne pas, à chaque fois, refaire des choses que j'ai déjà faites. Et à cette fin, j'avoue que j'hésite toujours à utiliser un framework simple comme noyau. Je n'ai pas envie de construire sur un noyau qui passera à une autre version chaque 6 mois et sur lequel je vais devoir revenir sans cesse. Pour revenir brièvement à codeigniter, ce qui me chagrine, c'est que tout est entremêlé. Si j'utilise un framework, je souhaiterais presque, dans l'idéal, avoir un dossier "framework" et un autre avec tout ce que je construis. Si le framework doit évoluer, je n'aurais ainsi pas à retrouver/gratter chaque chose que j'ai modifié/configuré sur ce framework de base. C'est pour cela que j'hésite toujours à me créer mon propre MVC et voir les choses en terme de "modules" à ajouter ou supprimer. J'imagine presque un système d'installer avec ma librairie que je développe petit à petit.

Ce message a été modifié par toluol - 2 Jun 2016, 09:27.
Go to the top of the page
 
+Quote Post
No6
posté 2 Jun 2016, 15:31
Message #12


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224



Il n'existe pas de vérité absolue en informatique.

En début de carrière je ne jurai que par l'assembleur 370 tant je trouvais le COBOL vraiment nul (Battlestar Galactica n'existait pas encore).
Maintenant je n'aspire à voir que du Javascript partout, avec serveur sous nodeJS et bases de Données noSQL si possible, et uniquement requêtées en JS.

D'ailleurs pour les sites ou on se retrouve avec moins d'une centaine de produits, je préfère éviter d'utiliser une base de données, et recomposer les pages à la demande depuis des données en json, ou composées via du MarkDown.

En tous cas, les p'tits c* qui refusent d'activer JS dans leur navigateur, j'en ai rien à battre.

PHP c'est gentil, mais j'ai du commencer avec un PHP 2 (?) et depuis j'en ai un peu ma claque.

Ceci étant je vois pas l’intérêt d'utiliser du PHP en partant de zéro, sauf à vouloir réinventer la roue.
Il existe des tas de librairies propres et fonctionnelles (comme redbean par exemple).
Et puis c'est vrai la maîtrise d'un framework (ZF ou Symfony) permet de gagner du temps et est garant d'une bonne homogénéisation pour le travail en équipe (sauf que je suis tj en solo, même quand j'aimerai mieux pas).



--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
scoch
posté 2 Jun 2016, 17:35
Message #13


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 4 800
Inscrit : 1 Jul 2010
Membre no 156 073



Citation (No6 @ 2 Jun 2016, 15:31) *
En tous cas, les p'tits c* qui refusent d'activer JS dans leur navigateur, j'en ai rien à battre.

Ah bravo ! Ces petits c*ns sont les handicapés. Généralement c'est le logiciel qu'ils utilisent qui ne supporte pas JavaScript (lecteur d'écran). Si tu faisais des sites pour des institutions publiques tu n'aurais pas le choix.


--------------------
L'homme n'est que poussière... c'est dire l'importance du plumeau ! Alexandre Vialatte
Go to the top of the page
 
+Quote Post
toluol
posté 2 Jun 2016, 22:50
Message #14


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



Citation (scoch @ 2 Jun 2016, 18:35) *
Citation (No6 @ 2 Jun 2016, 15:31) *
En tous cas, les p'tits c* qui refusent d'activer JS dans leur navigateur, j'en ai rien à battre.

Ah bravo ! Ces petits c*ns sont les handicapés. Généralement c'est le logiciel qu'ils utilisent qui ne supporte pas JavaScript (lecteur d'écran). Si tu faisais des sites pour des institutions publiques tu n'aurais pas le choix.


Arf euh... Il voulait sans doute parler de ceux qui, volontairement, désactive le javascript sur leurs navigateurs standards... rolleyes.gif

Et puis s'il fait des sites très "visuels" (comme des visites virtuelles, des portfolios...) ou bien des produits visuels (miroiteries, tablettes graphiques, galerie d'art...), ce choix peut aussi se comprendre car le développement peut être disproportionné par rapport au nombre de personnes viso-déficientes qui seraient intéressés à parcourir ce genre de site...
Enfin, selon mon expérience, les clients qui, dans leur CMS, remplissent le champs de texte alternatif d'une image (balise alt) est malheureusement proche de 0% ...



Ce message a été modifié par toluol - 2 Jun 2016, 22:51.
Go to the top of the page
 
+Quote Post
No6
posté 3 Jun 2016, 01:09
Message #15


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224



Citation (scoch @ 2 Jun 2016, 18:35) *
Citation (No6 @ 2 Jun 2016, 15:31) *
En tous cas, les p'tits c* qui refusent d'activer JS dans leur navigateur, j'en ai rien à battre.
Ah bravo ! Ces petits c*ns sont les handicapés. Généralement c'est le logiciel qu'ils utilisent qui ne supporte pas JavaScript (lecteur d'écran). Si tu faisais des sites pour des institutions publiques tu n'aurais pas le choix.

Hum, comme l'a écrit toluol, mes sites en question ne sont pas vraiment ciblées pour les Handicapés.
C'est pas tellement que je sois contre, mais faudrait me payer plus pour le temps passé pour cette compatibilité.

En fait, c'est un peu comme pour les sites bilingues, faut adapter chaque page en fonction de chaque langue.
On peut aussi détecter quelle est la langue par défaut du navigateur pour aiguiller sur le site correspondant; je crois que préfererai cette solution pour détecter les navigateurs particuliers dédiés pour les handicapés.
Sauf que je n'ai aucune idée de ce qu'ils peuvent utiliser; si tu as des pistes, je suis preneur cool.gif


--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
toluol
posté 3 Jun 2016, 10:49
Message #16


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 792
Inscrit : 14 Nov 2003
Lieu : Genève
Membre no 11 656



C'est vrai qu'on parle tellement de responsive design en ce moment, mais il est souvent loin de "s'adapter à tout", notamment en ce qui concerne l'accessibilité.
Cet article est intéressant : http://www.creativebloq.com/web-design/acc...reader-91516540

Enfin bon... on s'éloigne de mon sujet ! ^^

Pour revenir un peu au sujet, framework ou pas framework ? Je n'ai pas envie de refaire la roue, mais je n'ai pas envie d'utiliser une grosse usine à tic-tac pour produire un seul tic-tac... (C'est une image, hein ! ^^)
Même Codeigniter (qui me semblait plutôt léger par rapport à Symphony) me semble avoir des "fichiers à revendre". Je préfère avec un site "le plus léger possible" et je trouve con d'utiliser drupal pour un blog sur les tic-tac... (C'est encore une image)
Du coup, je me demande si je me sentirai pas plus à l'aise en créant le strict minimum du MVC et en intégrant une classe d'abstraction comme "Doctrine" et des librairies au fur et à mesure des besoins...
Go to the top of the page
 
+Quote Post
No6
posté 3 Jun 2016, 12:47
Message #17


Oui ?
*****

Groupe : Membres
Messages : 3 889
Inscrit : 24 Jun 2003
Lieu : BZH
Membre no 8 224



Pour moi le responsive design c'est juste de pouvoir surfer sur un smartphone ; rien à voir avec une compatibilité pour les mal voyants ou autre handicap.

Avoir un site compatible smartphone, c'est quasiment obligatoire aujourd'hui, plus d'un internaute sur 2 est sur smartphone.

C'est aussi pour cette raison que je préfère faire du tout Ajax, les temps de réponses sont meilleurs et la fluidité est garantie.

Je ne connaissais pas « Doctrine » et ça me semble être un bon compromis face a la technologie des frameworks, qui ont tendance à faire du surpoids au fil du temps.

Pas mal l'article sur creative Blog, ça me conforte dans mon idée de faire des istes à part pour chaque catégorie d'utilisateurs, plutôt que de faire un site unique avec un gros fourre tout indigeste à maintenir ; (et comme mes contenus sont à part, ils ne sont pas dupliqués).

De toutes façons, la remarque de scoch me semble de plus en plus déplacée : je me considère comme un artisan et j’entends me faire respecter sur cette compétence : s'imaginer que les sites sont, de base, fait pour être « naturellement multi-publics », c'est une grosse folie : les "acheteurs" de sites s'imaginent que n'importe quelle fonctionnalité va de soi, et ils deviennent vite déçus et vindicatifs, car les bases d'un dialogue constructif n'ont pas été posées dès le début.


--------------------
"Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n'est pas ce que je pense."
(Alan Greenspan)
Go to the top of the page
 
+Quote Post
yponomeute
posté 3 Jun 2016, 13:21
Message #18


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 4 969
Inscrit : 26 Jan 2011
Lieu : Pollachius virens
Membre no 164 083



Citation (toluol @ 3 Jun 2016, 11:49) *
Pour revenir un peu au sujet, framework ou pas framework ?

Cela dépend de ce que tu as a développer. Il n'y a pas de réponse définitive à cette question.
Si tu as juste besoin d'un formulaire sur une page web tu peux considérer qu'un framework c'est surdimensionné. Sauf qu'un framework ça va t'apporter de base tout ce qu'il faut au niveau sécurité du formulaire, protection contre injections sql etc.
Je pense que c'est à toi de trouver la réponse à cette question, et ça va être compliqué parce que chaque personne qui va te répondre va sans doute avoir un avis différent biggrin.gif

Il n'y a qu'avec l'expérience et le recul que tu sauras si tu as fait le bon choix.

Ce message a été modifié par yponomeute - 3 Jun 2016, 13:22.


--------------------
MBP 2017 15" avec clavier pourri et touchbar inutile
Go to the top of the page
 
+Quote Post
scoch
posté 3 Jun 2016, 15:37
Message #19


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 4 800
Inscrit : 1 Jul 2010
Membre no 156 073



Citation (No6 @ 3 Jun 2016, 12:47) *
De toutes façons, la remarque de scoch me semble de plus en plus déplacée : je me considère comme un artisan et j’entends me faire respecter sur cette compétence : s'imaginer que les sites sont, de base, fait pour être « naturellement multi-publics », c'est une grosse folie : les "acheteurs" de sites s'imaginent que n'importe quelle fonctionnalité va de soi, et ils deviennent vite déçus et vindicatifs, car les bases d'un dialogue constructif n'ont pas été posées dès le début.

Une des composantes du développement de sites adaptatifs, c'est l'amélioration progressive.
On commence par un code HTML sémantique, des CSS et JavaScript discrets (unobtrusive). Le contenu est alors servi de façon universelle, y compris donc pour les handicapés et… les robots des moteurs de recherche.

Les types de media de CSS2 permettent de charger des fichiers CSS adaptés aux lecteurs d'écran, à l'impression ou aux écrans. Les mediaqueries de CSS3 permettent de charger des fichiers CSS dont les règles sont adaptées aux dimensions d'écrans (on voit trop souvent une utilisation « fourre-tout » où toutes les règles sont définies dans un même fichier CSS… ce qui ralentit le chargement et complique la maintenance).

JavaScript permet d'adapter la présentation des contenus et le comportement des composants selon les capacités de l'appareil (tactile / pas tactile, etc). Par exemple, les mêmes données peuvent être présentées sous forme de liste, de tableau ou de graphe interactif selon le contexte mais dans tous les cas, l'information est délivrée. Idem pour l'intégration d'une carte type Google Maps dans une iframe c'est désagréable à utiliser sur mobile, il sera plus efficace de remplacer l'iframe par un bouton qui ouvre l'application native (Google Maps ou Apple Plans). Ou encore transformer un site classique composé de liens http et de pages en application AJAX wink.gif

Le web design adaptatif c'est un workflow, il est bien évident qu'on présente des scénarios au commanditaire du site pour qu'il comprenne que la présentation et les fonctionnalités sont différentes selon que le visiteur arrive avec un smartphone, une tablette, un ordinateur tactile ou pas, une TV connectée, une console de jeu. De toute façon, un projet commence toujours par un audit et du conseil…

Désolé pour le HS, et bon week-end biggrin.gif


--------------------
L'homme n'est que poussière... c'est dire l'importance du plumeau ! Alexandre Vialatte
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 19th March 2024 - 10:08