Quelques considérations en vrac

[Broceliande]

Bonjour,
Je m'appelle éric et j'ai découvert prestashop parmi tant d'autres lorsqu'un de mes clients m'a demandé de lui choisir une solution de site marchand. Je suis développeur et familier de l'open source, étant membre de l'équipe officielle de développement de Mediaportal(avec le même nick d'ailleurs) , logiciel MediaCenter open source.
(sans pub mais pour info : http://www.team-mediaportal.com ) , merci aux modos de me dire si ce n'est pas politically correct de lier comme ça.
Voilà pour les présentations , même si c'est sommaire mais c'est mon premier post ici alors ....
J'ai donc découvert et adopté ce logiciel pour plein de raisons , que je ne vais pas développer , mais la première est que j'aime la façon dont il est développé , et son back office clair et performant ( moins de temps perdu avec mon client pour lui en expliquer les fonctionnalités et rouages ).
Malgré mon enthousiasme il n'en reste pas moins que certaines fonctions peuvent etre améliorées sans trop de difficultés , en tout cas pour ce qu'il me semble.
Comme je ne suis pas la pour des 'feature's requests' et que je n'ai pas beaucoup de temps de lire l'intégralité des posts ici , il y en a au moins deux dont je souhaite parler et que je me propose d'ajouter , si et seulement si cela n'est pas au programme d'un développeur de l'équipe officielle.
Dans tous les cas ce sont deux fonctionnalités que je me dois d'ajouter pour mon propre client , il va de soi donc qu'elles seront proposées ici avec plaisir.
Voici , pour l'intro , maintenant pour les fonctionnalités :
1) L'arborescence des catégories dans le frame de gauche manque cruellement d'un classement personnalisé. Pour cela l'ajout s'un champ 'sortorder' à la table 'category' , puis l'implémentation de ce champ dans les 'order by' et l'ajout de tout ça dans la config ne me semble pas un super challenge. J'attends votre avis.
2) Pour moi c'est un bug mais je n'ai pas encore regardé le code source alors... mais en tout cas , si l'ajout d'un produit bénéficie d'un super éditeur de texte, sa modification apres création elle ne semble pas en bénéficier, et c'est très dommage à mon sens. Par ailleurs il semble que les retours chariots ne soient pas pris en compte , mais encore une fois , c'est peut être un bug connu, même peut être résolu (mais là j'ai cherché et rien trouvé) ou juste une méconnaissance de ma part.
Voilà pour ce que j'aimerais pouvoir utiliser et donc , comme e le disais , ajouter , par souci de contribution et puisque dans tous les cas je dois le faire.
Mais je ne suis pas du genre à réinventer la roue , alors si les devs ou les modos savent que cela est déja en main , inutile que je perde mon temps la dessus. Si au contraire c'est une bonne chose je serais ravi de m'y atteler et soumettre mon code ici .
A tous , bien cordialement,
Broceliande.

[thouny35]

Tes 2 points sont connus
Des demain avec la RC4, tu devrais y voir des changements et donc avoir une possibilité de classement, et une correction de ton bug énoncé (si je me trompe pas ^^)
Mais cependant, ce problème a déjà été énoncé ;-)

[Broceliande]

Merci pour cette bonne nouvelle , de fait je trouverais un autre moyen de contribuer et ne perdrais pas mon temps à faire ce qui est en train de se faire.
D'un autre coté je suis ouvert à toute demande, si j'en vois une qui est à la fois de mon ressort et apporte un bienfait à mon/mes clients, alors vous pouvez etre certains que je m'y appliquerais.
N'hésitez donc pas, je ne promets pas la lune bien sûr , mais si jamais comme je le souhaite je peux apporter une pierre à l'édifice ce sera volontier.
Broceliande

[Bruno Leveque]

Bonjour,

1. Les catégories sont déjà "triables" comme dans le logiciel Open-source SPIP (spip.net), il suffit pour cela de mettre un numéro devant :

"1.Catégorie 1" puis "2.Catégorie 2"

Celui-ci sera automatiquement masqué partout où le nom de la catégorie apparaît.

2. Je ne sais plus si ce bug a déjà été signalé mais il ne s'agit pas d'un comportement "normal".
Nous allons mettre à jour TinyMCE prochaienement pour basculer sur la version 3.1

Merci pour ton aide

[Broceliande]

Bonjour bruno,

(J'en profite pour faire une petite appartée que seul toi comprendras (et je m'en excuse auprès de tous les autres) : Je suis parvenu à mes fins sans aucun problème. Le produit en question vaut sans équivoque le prix qu'il est vendu. Malheureusement une majeure partie de ce prix comportait un produit que j'étais en mesure de fournir , ce qui explique qu'il m'était plus facile de combler les quelques % manquants que de vendre à mon client ce qu'il avait l'idée d'avoir déja payé... je suis sur que tu le comprendras....)

Merci de ta réponse c'est une chose que je ne savais pas.
C'est aussi à la fois assez ironique car j'aurais pu m'en rendre compte très vite dans la mesure ou je savais qu'en ajoutant un numéro devant , j'obtiendrais forcément l'ordre souhaité grace au classement alpha.
Mais comme cela ne me semblait pas satisfaisant je n'ai même pas testé.... :s
Cela étant dit je dois avouer que je ne trouve pas cette solution , bien que 100% fonctionnelle , très élégante.
Je ne me pose pas en juge d'un travail que je trouve excellent et dont je bénéficie aujourd'hui , mais ce genre de champ 'sortorder' ou quelque soit la manière dont tu le nommes me semble indispensable dans une table qui se veux 'triable' à souhait. Utiliser les numéros et ne pas les parser lors de l'affichage ressemble bien plus à une bidouille, et je m'en explique :
- dans un classement alpha , 111 s'intercalera entre 11 et 12 , ça n'est qu'un exemple mais ce seul exemple démontre la non efficacité de cette méthode. Y avez vous pensé et pallié ? Probablement oui (je n'ai pas testé comme je l'ai dit) , mais dans ce cas il s'agirait encore d'une 'bidouille' visant à traiter un cas particulier alors que sans aucune modif de code un simple 'ORDER BY sortorder' suffirait.
J'essaie de contribuer et non de critiquer , en tout cas ceux qui me connaissent sur le net sauraient que c'est le cas, je l'assure.
Au passage , coutumier des développements d'applications type frontend sur pc ( je dev en c# généralement) , l'absence de clés primaires dans de nombreuses table devient très vite un immense obstacle, car il faut coder en dur toute insertion ou update dans la table , avec des 'where' qui ne sont pas toujours évidents.
Je souhaitais par ex coder une petite appli permettant la création/gestion des catégories depuis un pc , chose à quoi j'ai renoncé faute de clés primaires et en regard du travail supplémentaire que cela apporte.
Pourtant cette app aurait été bien pratique pour mon client qui n'a pas une connexion internet très stable ni très réactive.
Ce qui m'aurait pris moins de 2 h et serait entré dans mon budget est passé à la trappe pour ces raisons. Bien sûr je pouvais ajouter des clés sur toutes les tables concernées , mais alors quid des maj ? Bien sûr l'interface http est particulièrement ergonomique , mais doit elle être la seule possible?
Bon rien n'est à prendre au 1er degré parce que je n'ai pas une vision globale du log suffisante à ce jour, et tel un newbie je peux avoir l'air de parler sans arguments, sans savoir... Il fallait néanmoins que j'aborde le sujet , dans le souci encore une fois de construir et non de dénier.
Pour le pb du mini éditeur , certes ce n'est pas un comportement normal , si on se réfère par ex au module editoriel qui lui affiche l'editeur même lors d'une modif. Mais son upgrade , bien que bienvenue , ne devrait pas résoudre le bug ? si ? parce qu'à mon sens il doit manquer une inclusion quelque part et une maj de l'outil n'en affichera pas plus ? Toujours au conditionnel car ce sont bel et bien des questions et pas des affirmations , je peux me tromper faute d'avoir vraiment plongé au coeur de l'appli assez longtemps.
Je m'y efforce cependant et suis toujours pret à donner un coup de main si le besoin s'en faisait sentir.
Merci à tous pour votre travail , votre cordialité , bref , pour tout .
Broce

[Julien Breux]

Tout d'abord, pourquoi ne pas simplement entabler la liste des catégories et appliquer un natsort ?
Cela évite de forcer le "ORDER BY sortorder" dans un premier temps

Ensuite, la version de Prestashop est à la RC3 (au moment ou je parle), il nous reste encore un peu de chemin avant la version un et toutes les idées sont bonnes à prendre.

Quant à la gestion dans la bdd, il est vrai qu'il va falloir mettre en place un schéma, chose sur laquelle je travail en particulier le soir sur mon temps libre... (mais cela implique une grosse implication )

Et moi, je te demanderai juste au passage si tu peux rendre plus lisible en passant des lignes (juste pour mes p'tits yeux )

Passe une bonne soirée

[Broceliande]

Salut julien , et désolé pour tes yeux , je vais tacher de faire mieux.

J'avoue ne pas comprendre très bien cette approche avec natsort.

Cette clause 'ORDER BY' existe bel et bien si je ne m'abuse dans les scripts de prestashop, puisque l'on peutconfigurer ceci dans le back office .

D'autre part un natsort n'est jamais qu'une restriction d'un classement personnalisé dans la mesure ou il faudra d'une manière ou une autre jongler avec les noms de catégories pour obtenir le résultat souhaité , ce qui n'est pas le cas avec un champ dédié. Cela ne prend pas vraiment une place considérable dans la bdd , vu qu'un champ int 8 suffit au classement de quelques 99 999 999 de catégories , ou produits si on applique cela aux produits également.

Il se peut que je n'ai pas tout compris de ton post , mais de ce que je connais d'un natsort , c'est ni plus ni moins un classement alpha un peu particulier, pas un classement entièrement perso , ce qu'un champ supplémentaire peut apporter le plus simplement du monde.

Bon je veux pas non plus créer un polémique, de mon côté il ne s'agissait que d'une suggestion .

Broceliande

[Julien Breux]

Il n'y a aucun problème, c'est en en parlant que nous construisons

Et tu as raison, je n'avais pas suivi l'intégralité de ta démarche.

Mes excuses

[Broceliande]

Aucun souci pour moi , je n'ai peut être pas été très clair dès le départ , puis comme tu le soulignais mes lignes à rallonge... hein ....
Pour finir juste j'ai tendance à préférer le cas général aux cas particuliers, en terme de dev bien sur. Autrement dit , pour moi le cas particulier n'est qu'une façon de démontrer qu'une routine ne fonctionne pas comme on le voudrait. Mais si cette routine ou fonction , peu importe, permet de traiter l'intégralité des souhaits à moindres frais , alors pour moi c'est gagné.
Ce genre de babiole comme un champ 'sort' permet à n'importe quel utilisateur de choisir pil poil l'ordre d'affichage , sans restriction. A voir...
+++
Eric