Bonjour à tous et à toutes.
Comment allez-vous?
Déjà, Bonne année 2018, tout mes voeux de réussites !
ENSUITE:
Étant Français, je tente d'abord ici pour trouver de possibles pistes entres développeurs sur l'ensemble des différences (points par points) de OSCommerce MS 2.2 à OSCommerce 2.3.x.
Même si j'ai évidemment analysé le code des deux en version vierge pour comparer, je vois que beaucoup de choses changent, comme la gestion de templates sous OSCommerce 2.3.x qu'il n'y a pas sous OSCommerce MS 2.2 !
(toutefois.. si je ne trouve rien avec vous je devrai m'orienter vers le forum Anglais afin d'y trouver le plus d'informations possibles, mais je me dis qu'entres Français on peut mieux s'entraider!).
POURQUOI CETTE NÉCESSITÉ DE SAVOIR CELA ?
Durant les derniers jours je travaille à la préparation compliquée de tout pleins de vieux sites (modifié jusqu'à leurs entrailles) OSCommerce MS 2.2 ... vers 2.3.x (et être prêt pour l'éventuelle version 2.4 de OSCommerce qui semble prometteuse avec ses hooks, ses espaces de noms et ses fonctionnalités orientées Objets).
Bonjour,
Mon impression à chaud :
Bons points :
+ système de traduction à priori universel
+ coup de jeune à l'interface
Mauvais points :
- Il faudra revoir les addons existants pour les rendre compatibles, ce qui ne sera pas à la portée de tout le monde
- Vu que cela va s'éloigner de la ligne directrice de l'équipe mère d'OsCommerce, cela risque de devenir un fork qui va suivre son propre chemin
Sur le forum US, il y a une version 2.3.4.1 qui n'est autre qu'une version 2.3.4 responsive avec Bootstrap, ce qui permet d'avoir d'office le site adapté à tous les écrans et une compatibilité avec les versions récentes de Php. Cette version, non officielle mais supportée par la communauté OsCommerce, s'est appelée Gold et Edge. Elle bénéficie du système de Hooks ainsi que certains addons gratuits ou payants.
OsCommerce officiel de son côté va passer en version 2.3.5 : code rigide comme la version 2.3 puis 2.4 mais supportant Php7.
Après, la route suivie par l'OsCommerce officiel, c'est le passage à la version 2.6 qui sera une version responsive. J'ai peur que cette version prenne un peu de temps à sortir car il est envisagé qu'elle serve de transition entre la version 2.5 et la 2.6 ET aussi entre la version non officielle 2.3.4.1 vers la 2.6.
Je suis dans la même démarche que toi : faire passer la version MS2.2 hyper bidouillée vers la version 2.3.4.1 responsive. Mon site a des fonctionnalités qui n'existent pas ou différemment en addons. Malgré mes efforts de limiter au maximum les modifs du core code, je suis parfois obligé de le faire, ne serait-ce pour garder les fonctionnalités qui sont propres à mon activité.
Du coup, le passage vers une future version officielle d'OsCommerce va être encore assez hard.
En conclusion, si ton système de traduction devient natif dans une version officielle d'OsCommerce, alors je crois qu'il aura le succès qu'il mérite. S'il ne l'est pas, cela va ajouter de la complexité à la maintenance du code lors d'ajout d'addons.
Hello Bonbec,
Déjà merci de ta réponse!
Le système de traduction, tel qu'il a été pensé ne surchargera JAMAIS le code des modules qui ne s'en servent pas.
En réalité, il ne fonctionnera que via une Web Application
Ce qui signifie que
a) si le module n'a pas été porté vers une Web Application, alors, il fonctionnera exactement comme OSCommerce le désirait à l'époque.
b) si le module a été porté vers une Web Application, alors, il fonctionnera exactement comme OSCommerce le désirait à l'époque mais en implémentant toutes les couches et logiques des Web Application.
Justement, là, tel que pensé, les 3 mécanismes:
-- Convention de Nommage
-- Classe de Traduction sous forme de Web Application
-- Logique des Web Applications et leur blocs logiques de contenu
N'impacteront pas le coeur de OSCommerce autre que l'inclusion d'un fichier et de blocs
(ce qui est aussi possible de faire depuis une Web Application avec des hooks compatibles avec OSCommerce, via le fichier runner.php (nom non définitif)).
J'ai encore besoin de faire des tests.
Je ne peux rien montrer de plus pour l'instant (bien qu'il y a énormément plus à montrer car déjà développé).
Je ne sais pas du tout si les gens du monde entier, un tant soit peu développeurs décideront de porter leur modules sous la forme d'une Web Applications ou encore même de créér une toute nouvelle Web Application.
Mais, une chose est sûre, la création d'un fork OSCommerce ne serait pas le bienvenu, les Web Applications sont à elles seules une sorte de Framework.
Tout en conservant OSCommerce tel quel.
Cela n'ajoute pas seulement une touche de simplicité à développer de nouvelles fonctionnalités dans un site OSCommerce, ça se sert aussi de TOUT ce que le site a à proposer: classes tierces, fonctions tierces
Et évidemment ça ne provoque pas de conflits dans le sens où la convention de nommage empêche ça.
Mieux encore: le mécanisme d'affichage des blocs est lui-même aussi une Web Application !
En gros: chaque Web Application se partagera 2 Web Applications
1) La Web Application qui contient toute la fonctionnalité de Traduction
2) La Web Application qui contient toute la fonctionnalité d'affichage des blocs logiques
J'ai en tête une "3ème Web Application" qui contiendrait une alternative PDO à ce que OSCommerce propose pour gérer ses bases de données.
Mais, sur ce sujet, je dois beaucoup y réfléchir (pour l'instant je termine de tout formaliser et de parfaire ça)
Au passage:
J'ai testé sur un PrestaShop 1.6 et 1.7 la Web Application de traduction, et bien j'ai eu besoin de créér dans runner.php des hooks pour gérer les appels à la classe de traduction (un wrapper)..
Mais très clairement, ça fonctionne plutôt pas mal.
En revanche, la Web Application des blocs logiques n'y fonctionne pas bien, et c'est logique, car il faut effectuer un render des blocs logique au préalable dans un hook, sauf que dans PrestaShop:
1.6, il y a déjà un moteur de Template, nommé Smarty. De ce fait, il faut juste créér un Plugin Smarty pour afficher les blocs logiques directement dans les .tpl, toutefois, on sort de l'essence de Smarty.
1.7, il y a déjà un moteur de Template, nommé Twig. De ce fait, il faut juste créér un Plugin Twig pour afficher les blocs logiques directement dans les .html.twig, toutefois, on sort de l'essence de Twig.
Par ailleurs, le PHP direct est interdit dans les fichiers .tpl comme .html.twig.
Donc... La Web Application d'affichage des blocs logiques est alors malvenue pour la logique de Smarty et de Twig.
La solution?
Il y a des solutions qu'il faudra mettre en oeuvre (pas le développeur de sa Web Application) mais plutôt moi dans ma Web Application des blocs logiques:
1) Indiquer que SI le moteur de Template détecté est Smarty, la Web Application des blocs logiques va retourner un avertissement et stopper son exécution (juste d'elle)
---- L'avertissement sera simple: On ne peut pas utiliser de fichiers bloc-logique.php dans Smarty, il faut donc renommer tout les blocs logiques de la Web Application en .tpl
2) Indiquer que SI le moteur de Template détecté est Twig, la Web Application des blocs logiques va retourner un avertissement et stopper son exécution (juste d'elle)
---- L'avertissement sera simple: On ne peut pas utiliser de fichiers bloc-logique.php dans Twig, il faut donc renommer tout les blocs logiques de la Web Application en .html.twig
3) Dans les deux cas, on va aussi prévoir (cette fois dans la Web Application du développeur) des tags Smarty ou Twig pour inclures les autres blocs logiques.
4) Le développeur sera mis au courant par la Web Application des blocs logiques qu'il devra aussi faire des hooks afin d'accrocher ses propres blocs logiques.
---- Ces hooks devront évidemment êtres écrits dans runner.php.
5) Le développeur devra aussi en toute logique (mais il en sera prévenu) créér un hook dans runner.php dans le but évident de faire un mini-wrapper à la Web Application de traduction.
---- Rien de plus simple: dans le hook, il fait appel à la classe de Traduction et fini!
6) N'oublions pas aussi que Smarty ou Twig utilisent quand même PHP (car ils reposent dessus) mais sous forme de Plugin (ou de filtre).
Il suffit donc de filtrer les traductions via un Plugin Smarty ou Twig et on est bon.
NOTE: dans le cadre d'un projet commercial, j'ai créé un plugin Smarty, et dans le cadre d'un projet personnel j'ai aussi créé un plugin Twig
La finalité est la même: On a accès à PHP comme on veut !
La différence est juste au niveau des fichiers de templates, ils doivent faire appel à des PLUGIN Smarty ou Twig pour exécuter un procédé PHP, et en aucuns cas du PHP directement (ce sera refusé).
Voilà pour les précisions.
Je peux voir que tu parais intéressé, ça fait plaisir!
Dès que j'ai du nouveau, je reviendrai t'en parler.
En attendant rien ne t'empêche de poser des questions ou de soumettre de possibles envies dans les Web Applications!
Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)