osCommerce France : Accueil Forum Portail osCommerce France Réponses aux questions Foire aux contributions

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> Mise en avant de ma propre convention de nommage et Recherche de la documentation développeur 2.3.x, Art de passer tout ses vieux sites OSCommerces 2.2 vers 2.3 au moins
SaphyraK
posté 2 Feb 2018, 17:42
Message #1


Ceinture jaune+ OSC
Icône de groupe

Groupe : Membres
Messages : 95
Inscrit : 6-November 12
Membre no 31715



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).

Citation
J'ai testé OSCommerce 2.4, eh bien, c'est vraiment pas mal, ça promet du lourd, mais son développement traîne un peu quand même, toutefois, il est plus stable qu'on ne le pense, mais la documentation est trop pauvre pour arriver à tout bien analyser en tant que développeur.


Bon.. Autant dire que pour l'instant, je suis un peu en mode "Recherche d'informations" et "Expériences".

J'aimerai donc qu'entres développeurs nous partagions notre connaissance.



UNE CONVENTION DE NOMMAGE POUR LES GOUVERNER TOUS !

J'ai réalisé ma propre convention de nommage que je trouve agréable à utiliser, bien que je sache très bien que la team OSCommerce a ses propres conventions de nommage
(bien que sympathique, celle de l'équipe OSCommerce, soyons honnêtes elle n'est pas super adaptée à toute les situations)..
J'essaie donc de mon côté d'adapter ma convention de nommage à bien plus de situation et de conserver quand même des habitudes et un format humain (mieux pour le repérage).

Évidemment, toute ma convention de nommage repose sur deux éléments essentiels: Anglais et Simplicité

Et un élément essentiel partagée par toutes: une classe UNIQUE de traduction qui ne repose plus du tout sur ces vieilles CONSTANTES poussiéreuses et très limitée tant en définition qu'en nommage et clarté.

Car..
De mon côté, déjà, j'ai développé un système de Traduction qui peut à la volée traduire des textes sans même avoir besoin des constantes, tout se fait via un objet unique derrière une classe sous un espace de nom unique (namespace), toutefois, on peut qualifier cette classe de traduction comme un Tool et non une Web Application, car même si ça respecte la convention de nommage, ça n'en utilise pas directement des blocs pré-décidés, ils sont dynamiquement trouvés par la classe de traduction.
(mais je vais y revenir)



DES APPLICATIONS WEB AVEC DES BLOCS LOGIQUES AU LIEU DE MODULES QUI INTERFÉRENT TROP AVEC LE CODE DU COEUR DE OSCOMMERCE:


Ces Web Applications (Applications Web en Français) sont construites à l'aide de Blocs logiques.
Les blocs logiques sont des sortes de pseudo-templates HTML utilisant évidemment PHP (extension .php)).
Ces blocs logiques peuvent êtres inclus avec un simple <?php include(...) ?> UNIQUE DANS UN FICHIER DU COEUR DE OSCOMMERCE A L'EMPLACEMENT DESIRE (exemple: ajouter un bloc dans le pied-de-page (footer)).

Ainsi, pour délier l'intégration d'un bloc et le décharger de l'exécution du coeur de OSCommerce, nul besoin d'effacer trente-six milles lignes par ci ou par là..
.. il suffira de supprimer la ligne de l'include du bloc logique de la-dite Web Application, et le site se verra retiré le chargement du bloc de cette Web Application de son exécution.

Notez que chaque Web Application a aussi un fichier unique (runner.php) qui contient la possibilité de désactiver TOUT LES BLOCS ou CERTAINS D'ENTRE-EUX sans en supprimer les includes, pratique pour les tests ou le debug.

Enfin, bref, dans ces blocs logiques, parlons de ce qui en est le contenu:

Citation
--- Du HTML (logique, mais sous forme la plus pure: PAS DE STYLES INTERNE, TOUT EST GERE PAR DES CLASSES CSS POUR LE THEMING))
--- Du PHP (dynamisme serveur, mais sous une forme très épurée: CODE DIRECT RARE (voir interdit), AU LIEU DE CA, usage de classes ou fonctions au maximum (définie ailleurs dans un fichier dédié à ça dans la Web Application) !
--- Du Javascript (dynamisme client, mais là encore sous une forme très épurée: CODE DIRECT RARE (mais pas interdit), AU LIEU DE CA, usage de classes ou fonctions au maximum (définie ailleurs dans un fichier dédié à ça dans la Web Application) !
--- autre language possibles, mais il y a de nombreuses interdictions, histoire de conserver une certaine homogénéité et de donner à chaque chose sa place qui lui est réservée.



Chacune de ces Web Application est gérée par cette convention de nommage que j'ai expliqué plus ou moins, je fournirai sur mon site Internet prochainement les détails de cette convention de nommage, libre à vous de l'utiliser ou non, je dois encore en formaliser certains aspects).)
Puis, je fournirai aussi un exemple de pseudo-web-application pour en montrer un peu la façon de s'en servir.



UNE CLASSE DE TRADUCTION SOUS FORME DE CONTEXTE AU LIEU DE CONSTANTES TROP PEU PERSONNALISABLE:

De plus chacune de ces Web Applications peuvent accéder à l'interface de Contextes de Traductions (en appelant le bon espace de nom, j'ai décidé d'utiliser le nom de mon entreprise pour ça, mais je réfléchirai si un meilleur nom est pas plus conseillé).
L'idée derrière ça pour avoir travaillé récemment et longtemps sous Symfony (pour ceux qui connaissent)..
.. c'est de faire hériter à ces Web Applications toute la simplicité logique de Symfony (bien entendu sans avoir besoin de Symfony, on ne parle pas d'un site entier mais de modules sous formes de Web Applications là, donc Symfony est largement pas le bienvenu).
En ce qui concerne:
- les routes.

Les routes sous Symfony (tout comme OSCommerce 2.4 se sert aussi), c'est une façon simple de cibler un fichier en lui établissant un chemin prédéfini à l'exécution, évidemment, ce chemin ne peut pas changer pendant l'exécution, (on parle du chemin base là).

Le système de l'interface de contextes de traductions TranslationsContextsInterface() est alors pensé pour se servir de la LOGIQUE des routes.
En effet, chaque blocs logiques est une route pour l'interface de contextes de traductions.
Et cette interface va immédiatement et automatiquement pouvoir dynamiquement sans autres interventions de votre part (autre que de préparer au préalable la route et les traductions du contexte) traduire en temps record chacun des textes de votre Web Application à travers n'importe quel bloc logique.

Le système de cette interface de Traduction tel que pensé repose sur 3 éléments essentiels (déjà développés et fonctionnels):


1) On déclare une instance de l'objet de Contexte de Traductions TranslationsContextsInterface() dans une variable afin de pouvoir accéder à ces méthodes n'importe où.
On peut évidemment créér autant d'instance que désiré selon le besoin de chacune de nos Web Applications: pas de conflits possibles et aucuns impacts sur les ressources visibles (j'ai fais des benchmarks)
(NOTE: bon, faut pas abuser non plus, à partir de 200,000 objets ça commençait à charger en 10 secondes au lieu de 0.1s) happy.gif

2) On inclue alors 1 seule ligne UNIQUE, (pas des constantes) pour chaque texte qu'on souhaite traduire dans le fichier de bloc logique désiré
(Exemple de ce à quoi ça représente actuellement, mais l'idée est encore de simplifier plus en rendant certains paramètres optionnels comme __FILE__ (l'argument 3 et 4 est déjà optionnel):
<?php echo $TradObject->public_M_getTranslationsContexts(__FILE__, ':titre-principal', true, array('strip_tags' => false, 'htmlentities' => false)); ?>
)

3) L'objet va donc appeler la méthode du contexte de traduction qui va automatiquement trouver à quel bloc (grâce à __FILE__) (et ça fonctionne déjà) appartient la traduction !
Ainsi: fini les conflits, de plus c'est hyper rapide, on peut changer de traduction même en pleine exécution, même avoir différentes traductions adaptées à différents profils et en changer n'importe quand même pendant l'exécution de la page, c'est modulaire, et c'est extensible par un item dans un tableau, chacun des tableaux par ailleurs est clairement identifié par le chemin de son bloc, impossible donc de se tromper quand on édite une traduction dans un des fichiers de traductions.. (Avec les CONSTANTES, on avait un souci de: fixation et de conflits possibles ou même... un souci que je n'aimais pas vraiment, mais logique aux constantes: un énorme manque de clarté dans l'organisation de modules avec des centaines de lignes de traductions).



UNE STRUCTURE UNIVERSELLE POUR LES WEB APPLICATIONS:

Chaque Web Application va aussi avoir une structure identique d'une Web Application à l'autre, donc universelle.
D'une part due au fait de la convention de nommage..
Mais aussi d'une autre part, due au fait que même les fichiers, emplacements et noms de classes CSS ou attributs HTML sont soumis à cette même convention de nommage.

Ainsi, fini, à se tordre les cheveux pour "comprendre le module d'un autre", relatif au fait que les variables ont des noms qui n'évoquent pas leur réelle portée/type/impact...
Le fait de comprendre les modules (dans notre cas cela sera des Web Applications) des autres est non seulement surtout nécessaire en cas de nécessité de le modifier...
... pour l'adapter dans deux cas: (site incompatible), (version incompatible)..
... mais aussi un dernier cas qu'on oublie un peu trop souvent: (module abandonné par son auteur et où la sécurité commence à devenir critique!)



POUR CONCLURE:

Voilà pourquoi je propose ce genre de convention de nommage.
Je compte l'utiliser pour tout ce que je fais au sein de mon entreprise.
Je serai ravi de partager avec vous cette toute nouvelle convention de nommage que j'ai élaboré dans le respect de l'être humain.

L'usage de l'Anglais dans la convention de nommage est essentielle pour permettre son internationalisation et exportation dans le monde des développeurs.

Ahem, actuellement j'y emploie aussi des commentaires à titre personnel et Français, ceux-ci seront évidemment évincés lors de la release publique.

Je ne compte pas imposer ma vision à l'équipe de OSCommerce, ils sont tétus, mais, cela, peut éventuellement aider à perfectionner notre façon de concevoir des modules mais sous une forme évoluée de Web Application.

L'idée je le répète: Simplicité, Anglais, Modularité !


Le premier de mes anciens modules à subir cette nouvelle convention sera la reprise de mon ancien module SoColissimo PAGES SO Iframe VERSION
https://apps.oscommerce.com/GR1sj&socol...e-simplicite-v5

Je veux lui ajouter tout les bugfix qu'on m'a gentillement reporté ces derniers mois. (il fonctionne mal pour certaines personnes sur OSCommerce 2.3)
Je veux aussi et surtout lui ajouter les nouvelles fonctionnalités de SoColissimo tels que décrit dans leur documentation officielle, comme par exemple: prix différents selon relais.
L'idée est aussi de lui permettre une transition plus douce vers OSCommerce 2.4 (quand cette version d'OSCommerce sortira).


Mais aussi différents modules que je voulais introduire les années précédentes sur le site de contribution OSCommerces.

Parmis eux, déjà développé par mes soins mais pas sous ma nouvelle convention, je dirai un peu sous la convention MS 2.2 (autant dire: Ouille-Ouille-Ouille):

-- Exportation GLS avec Google Maps
-- Gestion de Double Affichage de prix (HT/TTC) intelligente
-- Gestion de catalogue PDF (génération de catalogue PDF avec options à la carte)
-- Nouvelle version complètement revue de zéro de l'Export Universelle avec gestion de l'internationalisation
-- Gestion d'une traduction automatique de la boutique (via BING) (note: la classe de Traduction n'impacte que les Web Applications tel que développée actuellement (et dans ma convention de nommage)).

ET pas mal d'autres.



Merci de m'avoir lu.
J'attends vos remarques et retours!

Aidez-moi à m'aider à vous aider smile.gif

Ce message a été modifié par SaphyraK - 2 Feb 2018, 20:31.


--------------------
We get Everything, we are developpers, we are masters of the universe !
(just kidding.. **sigh**, just developpers...)
Go to the top of the page
 
Bonbec
posté 3 Feb 2018, 13:57
Message #2


Ceinture marron OSC
Icône de groupe

Groupe : Modérateurs
Messages : 1375
Inscrit : 30-May 06
Lieu : Vichy (03)
Membre no 10583



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.




--------------------
Config 1 en live : Osc 2.2 très fortement modifié ... UTF-8 et Php 5.4.
Contribs installées : down_for_maintenance_v 2.3 | Estimated Shipping v1.5 | imprint_1_3_5 | low_stock_report_v2.04 | visible_countries_1.2b | Products Tabs | shoppingCart_cleanup_v1.01.0 | + trop de bidouilles persos pas très OsCommerce (erreurs de jeunesse)
Config 2 en local avec UwAmp : Osc 2.3.4 BS
Go to the top of the page
 
SaphyraK
posté 3 Feb 2018, 15:13
Message #3


Ceinture jaune+ OSC
Icône de groupe

Groupe : Membres
Messages : 95
Inscrit : 6-November 12
Membre no 31715



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!


--------------------
We get Everything, we are developpers, we are masters of the universe !
(just kidding.. **sigh**, just developpers...)
Go to the top of the page
 

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

 



RSS Version bas débit Nous sommes le : 25th February 2018 - 18:26
Ce site est déclaré auprès de la commision Nationale
de l'Informatique et des Libertés (déclaration n°: 1043896)