Jump to content

Recommended Posts

Le dispatcher

 

Le dispatcher est une des principales nouveautés techniques de la version 1.5, plutôt que de passer par X fichiers à la racine du site pour lancer les pages (product.php, category.php, order.php, etc.) un point d'appel central est utilisé : index.php.

 

Les URI seront donc désormais de la forme index.php?controller=category, index.php?controller=product, etc.

 

il y a de nombreux avantages à ce système :

  • Il est plus simple d'ajouter un controller.
  • Permet d'utiliser des routes configurables, c'est à dire que vous pourrez désormais personnaliser vos URL simplifiées (très bonne chose pour le SEO).
  • Un seul point d'entré dans le programme, ce qui améliore la fiabilité et la possibilité de faire des pré traitements sur les entrées.

  • Like 2
Link to comment
Share on other sites

  • Permet d'utiliser des routes configurables, c'est à dire que vous pourrez désormais personnaliser vos URL simplifiées (très bonne chose pour le SEO).

Bonjour,

 

bien entendu, quelque soit la nouvelle url choisie, toutes les anciennes url créées par les différentes version précédentes de Prestashop seront automatiquement reprise à chaque modification ?

 

Car vous avez déjà changé la forum des url réécrites en passant à la 1.4, ce qui fera un second changeemnt pour tous les anciens utilisateurs.

Link to comment
Share on other sites

Bonjour :)

 

@Drelin : oui la création de commandes dans le BO est bien prévue pour la 1.5.

 

@Olea : actuellement ça a été fait de façon assez simple, c'est à dire qu'il y a un nouveau controller appelé "module" et qui permet d'appeler automatiquement des méthodes de la classe du module, afin d'éviter d'avoir les fichiers externes du genre modules/cheque/payment.php

Link to comment
Share on other sites

Merci Raphael (j'aime beaucoup le forum qui indique que tu es un Prestashop Apprentice :wacko: )

 

Autre question : je publie plusieurs modules sur les addons.

- Certains gèrent des données relatives à chaque client, style un maximum d'encours de commande autorisé (oleapaydiff), ou un compte prépayé (Prepayment)

- d'autres définissent des règles relatives aux produits, genre les cadeaux de mon GiftOnOrder

 

Du coup, ces modules ont différentes façon de devenir multi-boutique en 1.5. Par exemple :

- le solde d'encours est différents suivant les boutiques ou global à un groupe de boutique, voir configurable selon l'envie du marchand

- idem pour le compte prépayé, actif ou non suivant les boutique, avec un solde partagé ou spécifique à chaque boutique

- quand aux cadeaux les règles peuvent être différentes suivant les boutiques ou les groupes de boutique (sur l'un 2 produits achetés => 1 cadeau, sur l'autre, ce sera 3 produits)

 

Sera-t-il possible d'avoir un document destiné aux développeurs expliquant l'implémentation de ce multi-boutique ?

 

Si le versionnement de cette 1.5 se passe mieux que la 1.4, dès la RC, en tant que développeurs, on devrait pouvoir travailler à l'adaptation de nos modules pour vous remonter les problèmes à corriger avant les finales.

Mais si on passe notre temps en reverse-ingeneering, on n'y arrivera pas sur une fonction aussi complexe.

 

Merci

Link to comment
Share on other sites

Bonsoir,

 

@olea : actuellement il n'y a pas encore de vrai document je ne l'ai pas encore rédigé (vu que je me suis occupé de développer le multi boutique), mais c'est prévu. Initialement je voulais le sortir en même temps que la RC, mais effectivement il serait interessant que les développeurs de la communauté l'ait en avance, donc je m'occuperai de le rédiger quand j'aurai du temps dans les semaines qui viennent, une fois que j'aurai stabiliser le code à ce niveau là car je ne suis pas satisfait de certaines choses. Pour que vos modules utilisent le potentiel du multi boutique, il faudra le gérer dans le code, tout dépend après ce qu'ils font. S'ils se contentent d'utiliser des méthodes de PrestaShop ça sera déjà géré, autrement il faudra ajouter des jointures dans certaines requêtes, ce qui se fera assez facilement via des méthodes dédiées pour. Si vos modules utilisent des tables à part, il faudra peut être créer des tables d'association entre les données des tables en question et les boutiques.

 

@manouille : je n'ai pas compris les demandes concernant les RCS et les TVA, ou l'histoire des franchises. Cependant pour les droits il sera effectivement possible de restreindre les accès des employés seulement à certaines boutiques, cette fonction est actuellement en cours de développement.

 

Cordialement

Link to comment
Share on other sites

Le dispatcher

 

Le dispatcher est une des principales nouveautés techniques de la version 1.5, plutôt que de passer par X fichiers à la racine du site pour lancer les pages (product.php, category.php, order.php, etc.) un point d'appel central est utilisé : index.php.

 

Les URI seront donc désormais de la forme index.php?controller=category, index.php?controller=product, etc.

 

il y a de nombreux avantages à ce système :

  • Il est plus simple d'ajouter un controller.
  • Permet d'utiliser des routes configurables, c'est à dire que vous pourrez désormais personnaliser vos URL simplifiées (très bonne chose pour le SEO).
  • Un seul point d'entré dans le programme, ce qui améliore la fiabilité et la possibilité de faire des pré traitements sur les entrées.

 

Génial. Est ce que ca veut dire qu'on va enfin pouvoir déplacer le code dans un autre dossier à l'abri des requetes HTTP?

Par exemple avoir ceci:

 

/www/ → contient index.php et assets (JS, CSS, IMG)

/prestashop_core/ contient les class, la config les controllers…

 

Avec www comme dossier racine du site web.

 

Quelque chose dans ce gout là?

Link to comment
Share on other sites

 

Génial. Est ce que ca veut dire qu'on va enfin pouvoir déplacer le code dans un autre dossier à l'abri des requetes HTTP?

Par exemple avoir ceci:

 

/www/ → contient index.php et assets (JS, CSS, IMG)

/prestashop_core/ contient les class, la config les controllers…

 

Avec www comme dossier racine du site web.

 

Quelque chose dans ce gout là?

 

C'est mon rêve secret ! Mais ce ne sera pas pour la 1.5, et il y a peu de chance que ça soit pour la version d'après (rétrocompatibilité, quand tu nous tiens...).

 

Il manque un dossier template (à l'intérieur du dossier du thème) avant de pouvoir séparer les fichiers .tpl des médias. Reste ensuite le problème des modules, car c'est tout de même bien pratique que tout soit regroupé au même endroit.

 

A part ça, je t'invite (et t'encourage !) à faire des tests et noter les modifications qu'il faudrait pour pouvoir faire ce que tu dis, pour ensuite faire rentrer ça dans une roadmap prochaine ^^

Link to comment
Share on other sites

 

C'est mon rêve secret ! Mais ce ne sera pas pour la 1.5, et il y a peu de chance que ça soit pour la version d'après (rétrocompatibilité, quand tu nous tiens...).

 

Il manque un dossier template (à l'intérieur du dossier du thème) avant de pouvoir séparer les fichiers .tpl des médias. Reste ensuite le problème des modules, car c'est tout de même bien pratique que tout soit regroupé au même endroit.

 

A part ça, je t'invite (et t'encourage !) à faire des tests et noter les modifications qu'il faudrait pour pouvoir faire ce que tu dis, pour ensuite faire rentrer ça dans une roadmap prochaine ^^

 

Je n'ai pas testé mais on devrait pouvoir changer le nom du dossier "modules" facilement, vu que l'on a déjà (dans defines.inc.php) :

define('_MODULE_DIR_',		 __PS_BASE_URI__.'modules/');

 

et pour les fichiers .tpl on devrait les mettre dans un dossier "tpl",pareil on a déjà :

 

define('_THEME_DIR_',	  _THEMES_DIR_._THEME_NAME_.'/');

suffit de définir _THEME_TPL_ :

 

define('_THEME_TPL_',	  _THEMES_DIR_._THEME_NAME_.'mon_dossier_tpl/');

Ça éviterais que n'importe qui puisse voir les fichiers tpl, certains utilisent encore {php} qui est potentiellement une source de faille de sécurité.

Link to comment
Share on other sites

Bonsoir coeos.pro,

c'est effectivement techniquement possible de le faire, mais cela nécessitera d'autres changement, et surtout de très nombreux tests car il subsiste d'irréductibles morceaux de code en dur, sans parler de la rétrocompatibilité des modules. Cette modification serait trop risquée pour la version 1.5, mais pourquoi pas pour la 1.6. Cela dit on lancera quand même le sujet auprès des autres développeurs de la solution pour voir ce qu'ils en pensent techniquement :)

 

Cordialement

Link to comment
Share on other sites

  • 2 weeks later...

 

Alors on aura peut être l'espoir de voir un jour ton module de super devis ! ;)

 

Et comment ! J'attends la bêta de la 1.5 avec impatience car pour l'instant c'est du full-instable.

Malheureusement il m'était inutile de le développer pour la 1.4 car pas de multi-boutique !

Du coup, j'avais une application de gestion des devis annexe plugué en WS.

Link to comment
Share on other sites

  • 10 months later...

Bonjour,

 

Concernant le dispatcher et les modules, j'ai une question technique...

 

Si par exemple, j'ai un module "Annuaire" et que j'ai défini deux routes: une "annuaire" pour le controller "all" et une "annuaire-details" pour le controller "details", je n'ai pas de soucis pour y accéder ni rien.

 

Ainsi, par exemple "/annuaire-details?commercant=3851" m'affiche bien le controller "details" et l'id est récupéré.

 

Mais, et c'est là que je ne sais pas trop, est-ce que ce genre d'URL n'est pas pris en compte par Google ? Ne faudrait-il pas (et là je sens l'affaire venir) une route pour chaque ID présent ?

 

Ou une autre manière de procéder ? :)

 

Edit: Il semblerait que cela fonctionne niveau SEO. A voir :)

Edited by J. Danse (see edit history)
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...