Merci pour ce topo détaillé, ouf, spip tient la route vis à vis de Ez de ce que je comprends.
Je retiens néanmoins de tout ca quelques bonnes idées notamment les notifications et le workflow. Je crois que c'est en gestation chez spip aussi.
Pour la gestion d'objets génériques avec champs à piocher soit-meme, on a un debut de ca dans spip avec le plugin de cerdic, forms & tables, je suis d'accord pour dire que ca a de l'avenir d'une manière ou d'une autre.
Pour le e-commerce, on aurait tout pour le faire dans spip, sauf la volonté, c'est vrai que ce n'est pas passionnant-passionnant.
BoOz a écrit :
Mike LECOMTE a écrit :
Ez permet pour le moment de faire plus de choses que spip
Quoi par exemple ?
BoOz
Bonjour BoOz,
Tout d'abord Osana au plus des cieux pour ton plugin newsletter , il est top.
Ensuite, bon revenons à nos moutons, ez publish : je vais essayer de te détailler tout ça de mémoire, en essayant de te brosser un parallèle par rapport à ce que j'ai pu voir en spip et en Ez, les "vraies" différences à mon sens sont en verte dans le mail
- Multi site : ez et spip (depuis la 192) le font, pour la parite public, ez le propose aussi pour la partie admin, ez utilise des sites access auxquels sont associés des desgin distincts, des règles de configuration distinctes peuvent etre édicter en fonction des sites access
- Moteur de recherche : les deux en ont un et marchent bien
- Création de squelettes, les 2 ont
- surcharge de templates : les 2 ont, spip par des rubriques=2 par exemple, ez gère un fichier contenant un ensemble de règle d'override (c'est le terme utilisé). Pour ez, meme pour afficher un titre d'article, ça appelle un squelette, pour une image, ça appelle un squelette, ya des tonnes de squelettes et c'est dur de se retrouver dans tout ça. La gestion des overrides de ez permet de jouer sur l'affichage par exemple de tous les titres de tous les articles situés à aprtir de la sous rubrique 12, en résumé d'imbriquer plusieurs rèqles de surcharge.
Est ce vraiement utile ? ça dépend des fois
- Syntaxe des Boucles : les boucles spip sont cool, rien à dire. En Ez il faut appeler une fonction (fetch) qui va en fonction de tes arguments retourner un tableau, généralement un tableau de noeuds, ensute il faut le parcourir , et pour chaque noeud afficher les attributs de l'objet associé à ce noeud.
En spip on fait #TITRE, en ez ça serait {$node.object.data_map.titre.content}
Bon, déjà comme tu le vois, la syntaxe ez est un peu longue, et elle est encore plus quand la partie content d'un attribut te ramène aussi un objet, donc on obtient des trucs à rallonge du genre :
{$node.object.data_map.titre.content.data_map.mon_autre_objet.mon_attribut.content.output.output_xml}
- Création de vignettes d'images : Ez permet de définir des règles de création d'images , par exemple small, moyenne, grande, etc... Spip gère ses vignettes en fonction de la config du spip , et apès dans les squelettes on peut gérer en faisant des réduire image sans pbm.
- Mots clés : génial sous spip, pas testé sou EZ
Inclusion de squelettes : les 2 ont un mécanisme
Cache : les 2 gèrent un cache de manière fine
Utilisation des fonctions php propres à php : Spip utilisation direct |strip_tags, ez déclaration obligatoire dans un fichier ini de configuration
Utilisation des fonctions php réalisée par soit même : Spip déclaration dans mes fonctions, ez réalisation d'un module pour un nouvel opérateur de template
- Gestion des versions : spip sur les articles, ez sur tout objet existant. (utile ? pas utile ? ça dépend des cas.)
- upload de gros fichiers : spip par ecrire upload ou tmp upload en 192, ez utilise webdav (pas encore testé, et je ne sais pas si spip permet webdav
- Développement complémentaire : possible sur les 2 par plugin pour spip, par package et module pour ez. Mais vachement plus compliqué sur Ez je trouve, plein de petites règlesà connaitre, et qui ne sont expliquées nulle part. c'est ça le gros pbm d'ez, c'est souvent le manque d'informations pour faire telle ou telle chose.
Mulitemplacement d'un élément : Spip le gère par ses raccourcis et ses modèles (j'ai pas encore testé les modèles mais si j'ai bien compris c'est ce que ça fait), ez comm e il gère des noeuds et dse objets, un objet peut avoir plusieurs emplacements, ce qui signifie juste qu'il est associé à plusieurs noms
- Ez publish de base permet de faire quelque que pour le faire en spip faudrait de base partir sur un plug in , càd le fait de pouvoir créer sa propre structure de donnée,
en ce sens que de base, spip propose par exemple article avec un titre , un chapeau, un champ texte pour le texte, etc...
Dans ez, tu as des classes qui sont prédéfinies, et tu peux les étendre ou en créer de nouvelles, càd que tu as des datatypes de base, style ligne de texte, liste numérique, bloc de texte, case à cocher, etc, et en piochant donc dasn ces types de bases, tu crées une nouvelel classe comme tu l'entends, un nouveau canevas collant au plus près de la structure des informations qu'on veut afficher, en résumé tu configures la structure de ton contenu, chaque datataype pouvant etre obligatoire ou non, indéxé ou non dans le moteur de recherche, ayant ses règles de validation (date, plus de 15 carac.
- Ez publish peut gérer autant de niveaux de niveaux de workflows qu'on veut, spip me semble til ne gère que visiteur - rédacteur - admin restreint - admin me semble til , je ne sais pas si il existe un plugin qui permette dinfluer sur ça. maintenant c'est vrai tu me diras qui a besoin de 15 niveaux de workflows de validation d'un article ? et bien les administrations et les grands comptes.
- Gestion d'une corbeille pour les éléments supprimés
- Gestion d'une bibliothèque des éléments uploadés (pratiques pour les images), j'ai toutefois vu que spip 1.9.2 gérait maintenant un truc document des rubriques
- Gestion fine des groups, users et des droits : en gros c'est comme le plugin accès restreint, mais tu peux restreindre aussi les actions que les users/groups peuvent effectuer en content read create download de telle ou telle objet, classe, noeud
- E commerce intégré de base au CMS
- Gestion d'évènements liés au workflow, style par exemple que si un user de groupe rédacteur-05 publie un article ça envoye une notification au groupe décideur 03, et ça vide le cache du site de 3 niveaux audessus de l'article
Maintenant, comme je le disais, bien qu'il fasse plus de choses, je préfère de loin Spip parce que je le trouve plus logique, et moins prise de tête pour le développement, pour la communauté spip aussi.
Je trouve que Spip évolue aussi plus rapidement que Ez publish, je vois ça en terme par exemple pour la réalisation d'opération "basique" : sortir ou importer un flux rss de ez publish, c'est la croix et la bannière, le module newsletter de ez pareil, il y a plus de plugins spip que de plugs in ez, et ils sont plus utiles.
Créer ses prorpes trucs sous spip est plus facile et prend moins de temps que sous Ez.
Tu as autant de doc d'un coté comme de l'autre, mais que vaut de la doc sans exemple concret , comme c'est souvent le cas sur le site de ez ?
Comme ez publish est "dur" d'apprentissage, ya pa beaucoup de personnes qui savent en faire, qui l'utilisent, ou qui partagent leurs connaissances? ça implique que la communauté est moins importante, moisn réactive, etc, ce quie fait que moins de personnes en font, c'es tun cerlce vic
ça se voit en regardant le nombre de sociétés et de personnes qui font du spip, et le nombre de société et de personnes qui font du Ez (Kaliop, heliopsys, Smile, ingénieurs & consultants, sqli je sais pas et puis, c'est tout je pense...).
Ca se voit aussi en termpe de bouquins, il n'y a que 2 bouqins (en anglais) qui existent sur ce CMS, j'en ai acheté un et il n'explique que la base, et il ne détaille pas des masses les fonctionnalités avancées de ez publish, sa vraie valeur ajoutée.
Je n'ai pas fini de faire le tour ni de Spip ni de Ez, toutefois , à chaque que je travaille sous ez, je me dis mais pourquoi c'est pas aussi intuitif que sur Spip ?
En espérant avoir répondu à tes questions, cordialement.
Mike
J'ai appris les choses progressivement avec l'aide des listes SPIP.