Amélioration du framework et de son site

Exact, google analytics est un outil très bien qui "indexe" le nom des pages affichés: l'url, donc pas de soucis ;)

Après le plus propre sur un site est d'utiliser l'url rewriting pour avoir une adresse

Code:

---

telechargement.html

---

plutot que

Code:

---

index.php?:nav=pages::telechargement

---

Tuto sur l'url rewriting :
http://mkdevs.com/faq.html#urlrewriting

et

http://mkdevs.com/screencasts_7.html

Bonjour,

Après un long temps d'inaction (3 ans) en terme de développement, je souhaite m'y remettre pour un projet perso et utiliser un framework que, pour une fois, je n'aurai pas cherché à développer.
C'est effrayant parce que j'ai l'impression qu'en pourtant si peu d'années, le monde est à nouveau passé d'une époque préhistorique à une époque futuriste et que tout est à nouveau à réapprendre.

Je viens de découvrir avec un intérêt particulier ce framework qui me semble plus simple à aborder que Symfony.
Un choix de framework n'étant pas simple, coûteux en temps et impactant j'aimerais connaître votre roadmap sur ce produit.
J'ai un tout petit peu décortiquer votre produit et j'ai évidemment des questions/remarques à formuler (voir ci-après)
L'important pour moi est vraiment de connaître :
* comment vous compter faire évoluer ce framework et sur quel rythme.
* est-il possible d'y participer et comment.
Merci d'avance.
Philippe

Générateur :
============
- M'a détecté un projet Symfony2. Ne détecter QUE les projets MK via l'identification d'un fichier spécifique à ce framework.

index.php :
===========
Le parse du fichier site.ini me paraît coûteux juste pour récupérer path/lib.
Suggestion :
réorganiser les .ini :
0_onLoad.ini (juste ce qui concerne le lancement du premier fichier .php de l'appli)
0_mode.ini
0_connexion.ini
0_site.ini

Demarrage :
===========
Il faudrait pouvoir gérer le fait d'avoir un environnement dev et prod :
- Pouvoir démarrer via un index_dev
- Avoir des fichiers ini dev dans un sous-répertoire dev de conf (plus facile à supprimer en prod que lorsque tout est mélangé)

i18n :
======
Ne serait-il pas intéressant au niveau de la création du projet de pouvoir indiquer si le projet a vocation à être multi-lingue.
NON => suppression de ce qui concerne cet aspecct (ini, répertoire)
OUI => mise à jour fichier ini et ajout des fichiers nécessaires.

Dans votre FAQ, vous indiquez "et dans vos modules pensez à intercepter...."
Cela ne pourrait-il pas être fait automatiquement par classe_root.

La classe plugin_check accepte une valeur par défaut pour le paramètre $sErrorMsg des fonctions is...
Je n'ai pas trouvé la référence des traductions correspondantes.
Dans model_albums.php, vous indiqez un exemple pour isLowerOrEqualThan :
- Vous ne précisez pas que un exemple sans le paramètre message
- la fonction ne semble pas produire un message aussi riche que celui par défaut (pas de prise en compte de min et max)

Toujours d'après cette FAQ, on a droit à un fichier par langue. Pour une appli conséquente, cela peut être coûteux en temps et en occupation mémoire.
Vaut-il donc mieux charger un gros fichier ou plusieurs petits ?
Je vois cela plutôt en 2D :
- Application | plugin
- classe du modèle |
=> chargement avec deux niveaux dans l'array.


Répertoire plugin :
===================
Un plugin est-il une simple classe php ou bien serait-il intéressant qu'il puisse disposer :
- d'un fichier de config (exemple classe mail)
- d'un fichier de traduction (exemple plugin_chek)
auquel cas créer un niveau de répertoire intermédiaire du nom du plugin.

Tout d'abord bonsoir et merci de vous interesser à ce framework.

Citation:

---

comment vous compter faire évoluer ce framework et sur quel rythme.

---

Ce framework, initié en 2009 evolue en suivant 2 choses:
- rétrocompatibilité:
la majorité des frameworks ne pense pas à ce détail, on se retrouve au bout de quelques années avec des applications tournant sur une version différente du framework, on a ainsi une fragmentation pénible à maintenir.
- on alourdit pas on étend
- depuis le départ, à chaque modification, ajout de fonctionnalité on pense à ne pas alourdir l'existant, c'est entre autre pour cela qu'on passe beaucoup par des plugin pour étendre les fonctionnalités

Citation:

---

est-il possible d'y participer et comment.

---

Deux possibilités:
- par ce forum, comme vous le faites ici
- via le projet github: vous faites un fork, puis un pull request une fois que la modification est terminée et stable pour que je la fusionne au projet principal :)

Je réponds aux autres points un peu plus tard

Citation:

---

Envoyé par plr_fr

Générateur :
============
- M'a détecté un projet Symfony2. Ne détecter QUE les projets MK via l'identification d'un fichier spécifique à ce framework.

---

Faut que je regarde, d'habitude soit on laisse les applications dans data/genere du framework, soit on fait des liens symbolique vers les projets installé autre part.

Citation:

---

Envoyé par plr_fr

index.php :
===========
Le parse du fichier site.ini me paraît coûteux juste pour récupérer path/lib.
Suggestion :
réorganiser les .ini :
0_onLoad.ini (juste ce qui concerne le lancement du premier fichier .php de l'appli)
0_mode.ini
0_connexion.ini
0_site.ini

---

Bonne idée en effet, plutot path.ini.php car il contiendra que les differents chemins (seul chose nécessaire au demarrage)

Citation:

---

Envoyé par plr_fr

Demarrage :
===========
Il faudrait pouvoir gérer le fait d'avoir un environnement dev et prod :
- Pouvoir démarrer via un index_dev
- Avoir des fichiers ini dev dans un sous-répertoire dev de conf (plus facile à supprimer en prod que lorsque tout est mélangé)

---

C'est l'objectif du fichier "conf/mode.ini.php"
on modifie le chemin du addConf des fichiers mode et connexion (2-3 repertoires plus haut) et ainsi on peut livrer l'application sur differents serveurs de dev/test/prod...

Citation:

---

Envoyé par plr_fr

i18n :
======
Ne serait-il pas intéressant au niveau de la création du projet de pouvoir indiquer si le projet a vocation à être multi-lingue.
NON => suppression de ce qui concerne cet aspecct (ini, répertoire)
OUI => mise à jour fichier ini et ajout des fichiers nécessaires.

---

Oui pourquoi pas activer/desactiver ces 2 fichiers à l'installation.

Citation:

---

Envoyé par plr_fr

Dans votre FAQ, vous indiquez "et dans vos modules pensez à intercepter...."
Cela ne pourrait-il pas être fait automatiquement par classe_root.

---

J'ai pas bien saisi la question "intercepter" quoi ?

Citation:

---

Envoyé par plr_fr

Toujours d'après cette FAQ, on a droit à un fichier par langue. Pour une appli conséquente, cela peut être coûteux en temps et en occupation mémoire.
Vaut-il donc mieux charger un gros fichier ou plusieurs petits ?
Je vois cela plutôt en 2D :
- Application | plugin
- classe du modèle |
=> chargement avec deux niveaux dans l'array.

---

On ne charge que le fichier de la langue courante, c'est peu d'occupation memoire, mais je serais curieux de savoir comment fragmenter ce fichier et comment trouver quel ficheir charger pour afficher la traduction. (beaucoup de tag sont transverses)

Citation:

---

Envoyé par plr_fr

Répertoire plugin :
===================
Un plugin est-il une simple classe php ou bien serait-il intéressant qu'il puisse disposer :
- d'un fichier de config (exemple classe mail)
- d'un fichier de traduction (exemple plugin_chek)
auquel cas créer un niveau de répertoire intermédiaire du nom du plugin.

---

Un plugin est une simple classe en effet
Si il y a besoin de fichiers, il faut créer un module plutot ;)
Créé un fichier de configuration pour la classe mail alourdirait l'application en demandant de charger un fichier supplementaire pour 3-4 variables :(
En revanche, on pourrait deporter la configuration du plugin dans le ficheir site.ini dans une section mail :)

La traduction quant à elle devrait plutot etre centralisée dans le fichier de langue, j'ai l'habitude de le traduire en csv pour les traductions ;)

Bonjour,

Merci déjà pour vos réponses rapides.

Concernant le problème de détection d'un projet symfony, je suis sur un PC sous Windows (désolé :( ) et j'utilise WampServer.
--------------------------------

Citation:

---

C'est l'objectif du fichier "conf/mode.ini.php"
on modifie le chemin du addConf des fichiers mode et connexion (2-3 repertoires plus haut) et ainsi on peut livrer l'application sur differents serveurs de dev/test/prod...

---

je ne saisis pas trop votre explication:oops:. Votre FAQ pourrait peut-être contenir un paragraphe sur ce sujet avec du code commenté.
Faut-il avoir un fichier xxx.ini spécifique à la dev et un autre à la prod ?
--------------------------------
Dans votre FAQ vous indiquez "Et dans vos modules pensez à intercepter la valeur pour charger le bon fichier" pour $_SESSION['lang']
Cela ne pourrait-il pas être traité automatiquement , en lien avec site.ini[language]
-------------------------------
Concernant les fichiers de langue, je n'ai dans l'idée que des appels de chargement bien classiques et bourrins. Je pose ma question différemment :
Concernant par exemple les messages d'erreurs classiques sur un contrôle de formulaire,
- vaut-il mieux que ces messages soient chargés à chaque appel d'une page puisqu'ils sont dans le fichier global de traduction ou bien si et seulement si il y a une erreur dans un formulaire.
- comment gérer l'évolution de ces messages sur plusieurs projets s'ils sont dans un fichier spécifique à chaque appli.
-------------------------------
La classe plugin_check accepte une valeur par défaut pour le paramètre $sErrorMsg des fonctions is...
Je n'ai pas trouvé la référence des traductions correspondantes.
Dans model_albums.php (tuto réseau social), vous indiquez un exemple pour isLowerOrEqualThan :
- Vous ne précisez pas que un exemple sans le paramètre message
- la fonction ne semble pas produire un message aussi riche que celui par défaut (pas de prise en compte de min et max)
-------------------------------
Serait-il judicieux de mettre en place un groupe de discussion juste pour les questions qui concernent le fonctionnement technique du framework et ainsi des questions comme ce qui suit :

Je décortique votre classe classe_root et je suis un peu perdu (Elle est à la fois instanciable et statique). Elle est instanciée dans index.php mais
- $oRoot->addConf alors que addConf est static
- $oRoot->run() : OK mais les commentaires précisent * @access public static

Dans index.php vous faites :

Code:

---

1 2 3

$oRoot->addRequest($_GET); $oRoot->addRequest($_POST);

---

Mais dans classe_root on trouve :

Code:

---

1 2 3 4 5 6 7

//desactivation des magic quotes if (get_magic_quotes_gpc()) { $_POST = array_map('stripslashes_deep', $_POST); $_GET = array_map('stripslashes_deep', $_GET); $_COOKIE = array_map('stripslashes_deep', $_COOKIE); $this->getRequest()->magic_quote(); }

---

Et d'ailleurs :
- je ne comprends pas comment le passage dans ce if peut modifier le contenu des addRequest de index.php
- quid de $_FILES, $_SERVER, etc.

Merci d'avance pour vos réponses.

Citation:

---

Envoyé par plr_fr

Bonjour,

Merci déjà pour vos réponses rapides.

---

Merci à vous pour ce débat technique, je vous ai fait un MP pour vous communiquez mon email ;)

Citation:

---

Envoyé par plr_fr

Concernant le problème de détection d'un projet symfony, je suis sur un PC sous Windows (désolé :( ) et j'utilise WampServer.

---

Ma question: vous avez lancez le builder, et créé des applications web, ils on du naturellement etre créé dans le repertoire data/genere du framework, non ?
Dans ce cas je ne comprends pas comment il peut voir des applications symfony ??
On pourrait chercher le repertoire "module" je ne pense pas qu'ils s'appelle ainsi sur les autres frameworks

Citation:

---

Envoyé par plr_fr

je ne saisis pas trop votre explication:oops:. Votre FAQ pourrait peut-être contenir un paragraphe sur ce sujet avec du code commenté.
Faut-il avoir un fichier xxx.ini spécifique à la dev et un autre à la prod ?

---

Je vais ajouter un paragraphe dans la FAQ en effet, mais pour vous répondre:

En dev, vous livrer votre application en indiquant que le fichier mode.ini.php et connexion.ini.php sont à l'exterieur du projet, ainsi vous versionnez l'application sans le contexte de connexion
en production, avec svn ou autre vous livrez la meme application, et comme les fichiers de "mode" et "connexion" sont à l'exterieur du repertoire du projet, vous pouvez avoir la meme applicatoin, avec des fichiers de configuration différentts selon que vous êtes en dev/test/prod ;)

Citation:

---

Envoyé par plr_fr

Dans votre FAQ vous indiquez "Et dans vos modules pensez à intercepter la valeur pour charger le bon fichier" pour $_SESSION['lang']
Cela ne pourrait-il pas être traité automatiquement , en lien avec site.ini[language]

---

Je me suis déjà posé la question, le problème c'est que ça impose d'avoir par défaut une gestion de session sur tous les projets, alors que certains projets web n'utilisent pas de session :)
Après, on pourrait dire: qu'activez la gestion multilangue active par défaut les sessions, mais il resterait un problème à gerer: les liens
Quand vous etes sur une page, si vous cliquez sur une langue différente, c'est un lien, mais un lien menant sur le meme module avec la variable de langue ? ou un lien vers un module specifiques pour choisir la langue puis une redirection ?
Plusieurs questions qu'il faut definir dans son application, je trouverais intrusif de le faire nativement dans le framework sans laisser la main au developpeur.

Mais je peux donner des exemples ou faire un tuto d'application mutli langue

Citation:

---

Envoyé par plr_fr

Concernant les fichiers de langue, je n'ai dans l'idée que des appels de chargement bien classiques et bourrins. Je pose ma question différemment :
Concernant par exemple les messages d'erreurs classiques sur un contrôle de formulaire,
- vaut-il mieux que ces messages soient chargés à chaque appel d'une page puisqu'ils sont dans le fichier global de traduction ou bien si et seulement si il y a une erreur dans un formulaire.
- comment gérer l'évolution de ces messages sur plusieurs projets s'ils sont dans un fichier spécifique à chaque appli.

---

Je comprends l'idée, on pourrait en effet fragmenter un peu le fichier de langue et charger à la volée la partie contenant les messages de formulaires.
Mais tout ceci ferait gagner un tout petit peu de temps, mais en ferai perdre également, car en php, il est plus gourmand de lire 2 petit fichiers, plutot qu'un grand: c'est l'acces au disque qui est consommateur de ressource, d'ou ma fusion de tous les messages en un seul ;)
note: on parle ici de micro secondes de gourmandises ;)

Citation:

---

Envoyé par plr_fr

La classe plugin_check accepte une valeur par défaut pour le paramètre $sErrorMsg des fonctions is...
Je n'ai pas trouvé la référence des traductions correspondantes.
Dans model_albums.php (tuto réseau social), vous indiquez un exemple pour isLowerOrEqualThan :
- Vous ne précisez pas que un exemple sans le paramètre message
- la fonction ne semble pas produire un message aussi riche que celui par défaut (pas de prise en compte de min et max)

---

Oui, le plugin_check par defaut n'est pas multilingue, il faudrait corriger ceci ou du moins en proposer un cousin gerant le multilingue (ce plugin etant parametrable dans site.ini)

Code:

---

1 2 3

check] class=plugin_check

---

Citation:

---

Envoyé par plr_fr

Serait-il judicieux de mettre en place un groupe de discussion juste pour les questions qui concernent le fonctionnement technique du framework et ainsi des questions comme ce qui suit :

---

Je vais vous communiquer mon email, mais je trouve interessant de partager sur le forum au moins un bilan de ces discussions technique c'est plus transparent pour les utilisateurs de voir les questions posés et les réponses apportées ;)

Citation:

---

Envoyé par plr_fr

Je décortique votre classe classe_root et je suis un peu perdu (Elle est à la fois instanciable et statique). Elle est instanciée dans index.php mais
- $oRoot->addConf alors que addConf est static
- $oRoot->run() : OK mais les commentaires précisent * @access public static

---

Erreur de commentaire en effet ;)

Citation:

---

Envoyé par plr_fr

Dans index.php vous faites :

Code:

---

1 2 3

$oRoot->addRequest($_GET); $oRoot->addRequest($_POST);

---

Mais dans classe_root on trouve :

Code:

---

1 2 3 4 5 6 7

//desactivation des magic quotes if (get_magic_quotes_gpc()) { $_POST = array_map('stripslashes_deep', $_POST); $_GET = array_map('stripslashes_deep', $_GET); $_COOKIE = array_map('stripslashes_deep', $_COOKIE); $this->getRequest()->magic_quote(); }

---

Et d'ailleurs :
- je ne comprends pas comment le passage dans ce if peut modifier le contenu des addRequest de index.php
- quid de $_FILES, $_SERVER, etc.

---

Les passages sur les variables d'environnents $_GET,$_POST... c'est pour mettre ces variables d'environnements "ok" (au cas où l'utilisateur les utiliserait directement)
Pour l'appel magic__quote de getRequest(): $oRoot->addConf() appel en interne _root::getRequest()->addConf(), on nettoie donc les tableaux précédement ajoutés ;)

Une nouvelle version est disponible corrigeant le commentaire, séparant le fichier site.ini en deux path.ini et site.ini en plus de corrections de deux bugs sur la gestion de cache (pages et autoload).

Bonjour,

Concernant le problème de détection d'un projet symfony, j'ai juste téléchargé le projet de réseau social, décompressé et créé le répertoire dans www (répertoire par défaut pour les projets sous WampServer).
------------------------------
Concernant la gestion dev/prod, je travaille "à l'ancienne" puisque je ne connais pas SVN et consort. Il est vrai que la plupart des explications cocnernant l'utilisation de ces outils est fournie pour des linuxiens ce que je ne suis pas non plus.
Cela n'empêche pas à mon avis de faire de l'assez bon travail (http://philippe.laruffie.fr, site qui est même assez responsive avec un micro-micro-framework php adapté à la publication de mes pages).
Il va falloir que je m'améliore sur l'utilisation de ces nouveaux outils mais le temps disponible est mon pire ennemi.

Pour moi, il n'y a pas que le mode et connexion qui peuvent être touchés, les autres aussi, parce que la config pour le log ou pour le mail pourrait être différente
Je serais plus dans l'idée d'avoir un index_dev.php, index_test.php et index.php
et
conf / dev / *.ini
conf / test / *.ini
conf / prod / *.ini

Ce qui permet de bien vider son appli des scories dev et test pour la prod et reste je pense compatible avec votre volonté de vouloir laisser votre fwk compatible avec les versions.

Votre idéee de fichier.ini.php est très maline...

???Autre idée??? : "compiler" les .ini et faire un include dans le __construct de classe_root.


------------------------------
Concernant les fichiers multi-lingues:

Juste pour vous taquiner, vous ne souhaitez qu'un seul fichier langue mais votre index.php contient l'appel de 3 .ini différents.
Je pense qu'il faudrait aussi prendre en compte la taille d'un bloc sur le disque. Si c'est un bloc de 512 octets et que le fichier en fait 513...

------------------------------
Concernant des plugins plus évolués ie comportant fichier langue et/ou ini et/ou autre choses, vous proposez le répertoire module mais ce répertoire me plaît bien pour les modules de l'application à développer.
Pour des plugins plus "techniques", pourrait-on disposer d'un sous-répertoire (level1 ou...) dans plugin pour ceux-ci (ou autre solution plus adéquate évidemment) ?
Le top du top serait de pouvoir aussi étendre votre outil de génération l'outil d'admin correspondant au plugin.

Citation:

---

Envoyé par plr_fr

Bonjour,
Concernant le problème de détection d'un projet symfony, j'ai juste téléchargé le projet de réseau social, décompressé et créé le répertoire dans www (répertoire par défaut pour les projets sous WampServer).

---

Si vous avez copié le code du projet social et indiqué dans le site.ini où était le framework, je ne comprends pas où dans le builder il vous a listé des fichiers symfony ?

Citation:

---

Envoyé par plr_fr

Concernant la gestion dev/prod, je travaille "à l'ancienne" puisque je ne connais pas SVN et consort. Il est vrai que la plupart des explications cocnernant l'utilisation de ces outils est fournie pour des linuxiens ce que je ne suis pas non plus.
Cela n'empêche pas à mon avis de faire de l'assez bon travail (http://philippe.laruffie.fr, site qui est même assez responsive avec un micro-micro-framework php adapté à la publication de mes pages).
Il va falloir que je m'améliore sur l'utilisation de ces nouveaux outils mais le temps disponible est mon pire ennemi.

---

Vous pouvez utiliser svn sur windows facilement avec notamment tortoise: http://tortoisesvn.net/downloads.html
Le site est sympa, mais j'ai eu beau redimensionné la fenetre je n'ai pas vu les effets "responsive" :(
Je vous invite à visiter http://getbootstrap.com/ : redimensionner votre navigateur en 700px de largeur par exemple et vous verrez le menu s'adapter pour laisser place à un icone "hamburger" ;)

Citation:

---

Pour moi, il n'y a pas que le mode et connexion qui peuvent être touchés, les autres aussi, parce que la config pour le log ou pour le mail pourrait être différente
Je serais plus dans l'idée d'avoir un index_dev.php, index_test.php et index.php
et
conf / dev / *.ini
conf / test / *.ini
conf / prod / *.ini

Ce qui permet de bien vider son appli des scories dev et test pour la prod et reste je pense compatible avec votre volonté de vouloir laisser votre fwk compatible avec les versions.

---

le probleme d'avoir un index_dev.php /_test.php et index.php c'est que l'on livrera en production ces 3 ficheirs avec leurs parametres de dev/test/prod et on risquera en production d'avoir une configuration dangereuse: affichage des messages d'erreurs, debug...
Je suis habitué à avoir des audits de sécurité sur mes applications, cette construction s'est faite par experience: une seule source svnisé, les fichiers de configurations à l'exterieur, et lorsque l'on livre en production, un simple svn update de la branche de produciton et voila: liant les fichiers de configurations N crans au dessus, l'application est automatiquement paramétré pour la production (pas d'erreur, pas de debug, pas de log gourmand...)

Citation:

---

??Autre idée??? : "compiler" les .ini et faire un include dans le __construct de classe_root.

---

Oui, comme expliqué par mail, je travaille sur un moyen de pouvoir activé un cache de ces 3-4 fichiers ini.

Citation:

---

Concernant les fichiers multi-lingues:

Juste pour vous taquiner, vous ne souhaitez qu'un seul fichier langue mais votre index.php contient l'appel de 3 .ini différents.
Je pense qu'il faudrait aussi prendre en compte la taille d'un bloc sur le disque. Si c'est un bloc de 512 octets et que le fichier en fait 513...

---

Je suis d'accord, mais comme expliqué plus haut, je travaille à une generation de cache des fichiers ini afin de n'inclure qu'un fichier de configuration.

Citation:

---

Concernant des plugins plus évolués ie comportant fichier langue et/ou ini et/ou autre choses, vous proposez le répertoire module mais ce répertoire me plaît bien pour les modules de l'application à développer.
Pour des plugins plus "techniques", pourrait-on disposer d'un sous-répertoire (level1 ou...) dans plugin pour ceux-ci (ou autre solution plus adéquate évidemment) ?
Le top du top serait de pouvoir aussi étendre votre outil de génération l'outil d'admin correspondant au plugin.

---

Soit un module, soit une classe "metier" ;)
Pour le plugin: si il nécessite une configuration => fichier ini différente ou non: comme expliqué plus haut l'idée c'est a terme de generer un cache agrégé de tous les fichiers (cache bien sur a exclure du projet svn :) )
Je n'ai pas saisi l'histoire d'etndre l'outil de generation : vous souhaitez ajouter de nouveaux modules de generation ?
C'est une bonne idée en effet de pouvoir proposer des modules de generation pour le builder.
Actuellement je ne peux que suggerer de passer par github ;)

bonjour,

Je suis encore tracassé par les modules :p

petite proposition : permettre d utiliser des sous dossiers dans le dossier module

exemple

site\module\guest\main.php
site\module\guest\view\default.php
site\module\admin\group\main.php
site\module\admin\group\view\a.php
site\module\admin\group\view\b.php
site\module\admin\group\view\c.php
site\module\admin\user\main.php
site\module\admin\user\view\a.php
site\module\admin\user\view\b.php
site\module\admin\user\view\c.php
site\module\guest\contact\main.php.php
site\module\guest\contact\view\a.php
site\module\guest\contact\view\b.php
etc etc


en préfixant on peut se passer de cela mais je trouve que pour les gros projets cela me semble mieux

a vous de voir

Interessant en effet
Actuellement on peut "juste" changer le répertoire contenant les modules, par défaut "modules/" dans le fichier conf/path.ini.php (ou site.ini.php selon la version)

On peut également modifier "à la volée" ce répertoire en jouant sur la méthode

Code:

---

_root::setConfigVar('path.module')

---

PS: merci pour la signature ;)

Si vous avez d'autres idées ?


Je vais voir pour externaliser l'autoload et ainsi donner la main au développeur pour éventuellement le surcharger ;)

et pourquoi pas l intégrer dans la vue ...? :p


site\module\guest\main.php
site\module\guest\view\default.php

========> $oView=new _view('guest::default');


site\module\admin\user\main.php
site\module\admin\user\view\a.php

========> $oView=new _view('admin/user::a'); (ou $oView=new _view('admin||user::a')



au niveau du site :
il y a peut etre des utilisateurs qui souhaitent déposer leurs petites astuces / trucs / plugin / bribe de code ...
du coup creer un espace en ce sens ...



enjoy

Deux choses pour votre idée:

Il faut
1. que l'on puisse appeler un module par exemple private_customer qui serait stocké dans module/private/customer (et non module/private_customer)
2. lorsqu'on appelle la vue _view('private_customer::list') qu'il aille chercher le fichier module/private/customer/view/list.php et non (module/private_customer/view/list.php)

Donc il y a deux endroits à faire évoluer: l'autoload qui chargera le fichier module au bon endroit + la classe view qui ira la chercher au bon endroit

Pour les propositions d'idées et axe d'amélioration, c'est ici, vous etes au bon endroit
Vous pouvez également faire des demandes sur le site dvp du projet: http://projets.developpez.com/projec...amework/issues

Vous allez etre ravi d'apprendre l'arrivée de cette fonctionnalité dans la dernière version ;)

http://mkframework.com/news.html

deja ?! ;)

merci beaucoup, je pourrais tester demain ...

J'y avais réfléchis après notre discussion, il ne me restais plus qu'à l'implémenter de la manière la moins intrusive pour éviter la régression. ;)

C'est la partie la plus difficile: garder la rétro compatibilité depuis 2009 ;)
C'est un des avantages qui differencie ce framework des autres :)

Bonjour a tous

Je viens de lire un peu le début de cette discussion visant une amélioration majeur de Framework et j'avoue ne pas avoir saisie tous les contours. je suis aussi en train de lire http://mkframework.com/news.html de peur de mal interpréter voici mes questions :

1. Quel est ce changement concernant le rangement des répertoires
2. Moi je suis a la version mkframework_v4_106_2_r265.zip qu'es qui change concrètement si je dois mettre en place la version mkframework_v4_106_2_r266.zip. En faite que dois je modifier et pourquoi ?

Merci de vos éclairages

Concretement: il y a une nouvelle fonctionnalité permettant de "ranger" ses modules dans des repertoires.

Mais comme d'habitude, je veille à garder une retrocompatibilité, donc vous pouvez utiliser les modules comme avant ;)
Vous pouvez en plus, les "ranger" dans des repertoires pour mieux organiser le répertoire module :)

C'est que du + ;)