[Agora-generale] RE : Raccourcis <docxxx|...>

Mar 27 Juin 17:20:12 CEST 2006

Régie Technique Agora a écrit :
> Le 27/06/06, *Stephane LAURENT* <sl at adequates.com 
> <mailto:sl at adequates.com>> a écrit :
>
>     j'ai demandé pourquoi certains
>     choisissaient Agora plutot que Spip quand le besoins fonctionnels du
>     projet etaient couverts par Spip et des contribs.
>     On ne pose pas ce genre de question sur cette liste, voyons !
>
>
> Si, c'est même une très bonne question.
Jacques, enfin, c'est un troll, il ne faut pas repondre !
> Pour être précis, afin de doccumenter précisément AGORA, nous avons 
> besoin de savoir quels sont ses usages.
>
>     * quelles sont les fonctionnalités d'AGORA effectivement utilisées
>       en production et comment (en particulier pour celles qui
>       manquent de documentation)
>     * quelles sont les fonctionnalités d'AGORA qui ont un équivalent
>       fonctionnel dans SPIP
>     * ...
>
Les temps changent alors ...
Je te souhaite des reponses de meilleure qualité que celles que j'avais 
eu à l'époque (tu pars mal, tu poses ta question au milieu d'un troll 
... comme moi).
> De plus, Cédric (un des mousquetaires de SPIP) a ouvert un espace sur 
> la zone de SPIP : 
> http://zone.spip.org/trac/spip-zone/browser/_plugins_/_agora_ pour les 
> plugins visant à permettre l'iso-fonctionnalité de SPIP avec AGORA.
> Cet espace est officieux. Mais son existence est officielle (de faite 
> puisque l'URL n'est pas protégée).
>
> Rien n'interdit à ceux qui le désirent de venir déposer des 
> contributions sur cet espace. Et toi, Stéphane, tu en as les 
> compétences ;-)
sans doute, mais "pour quoi faire ?"
Je prefere agir plutot que de perdre du temps en blabla et discussions 
stériles, sachant que les decisions autour de ce projet ne sont ni 
fonctionnelles ni techniques.
Attention, je ne dis pas qu'Agora est un mauvais produit.
Si, sur un projet, il m'apparaissait comme le produit le plus proche du 
besoin de mon client, je n'hesiterai pas à l'utiliser et à y contribuer.
Mais dans les choix de produit, je prend en compte le coup d'integration 
et de possession (maintenance) et le cas ne s'est jamais produit.
Pour un projet à petit cycle de vie ou repondant uniquement à un besoin 
metier specifique, l'approche fork peut etre la meilleure solution (pour 
le client).
D'ailleurs, j'avais dit sur cette liste qu'avec le quart du budget 
d'agora, on pouvait largement maintenir une version modifiée de Spip si 
on prenait en compte les problematiques de maintenance dès la conception.
J'etais encore loin du compte :
Je maintiens seul et sur mes temps libres une version modifiée de 
Spip1.8.3 et j'ai bon espoir de pouvoir porter l'ensemble des 
fonctionnalité sur la 1.9 avec un minimum de modifications.
Si le resultat est concluant, je ne doute pas que les points d'entrée 
manquant ne tarderont pas à apparaitre dans les version suivantes et que 
le fork disparaitra naturellement au profit d'une "distribution".
Mais maintenir quelques modifs ne me derange pas. En plus, ca oblige de 
suivre les ameliorations et corrections de bug.
>
> Il y a en particulier comme différence fonctionnelles :
>
>     * une gestion des droits plus fine (en particulier, rédacteurs
>       restreints)
>
Géré par mon "fork" : admin / redacteur / visiteurs peuvent se voir 
attribuer des droits sur les rubriques
J'ai egalement ajouté 2 parametres à l'utilisateur :
un parametre precise si, dans l'espace privé, l'utilisateur voit 
uniquement ses articles, les articles proposés dans "ses" rubriques, ou 
si il reste sur le comportement "normal" de Spip
un autre parametre permet d'affecter le droit de modification d'un 
article publié

La version de developpement (deja en prod sur un site ...) ajoute 
egalement un champ "etat" à auteurs_rubriques.
Cette approche me permet de mettre en place un systeme complet de droits 
au niveau de la rubrique.
Sur mon site, il y a 7 niveaux de droits possible sur une rubrique et 
des formulaires publics permettent de gerer un workflow de demande de 
droits (en plus de la gestion dans /ecrire).
Je peux donc deleguer à un visiteur (n'ayant pas acces à /ecrire) la 
gestion des demandes droits ou la validation des contenus

>     * une gestion du workflow avec plus de niveaux
>
Mon approche, lorsque le fonctionnement devient du "metier" est de faire 
les outils pour pouvoir developper ou parametrer simplement.
Pour les utilisateur ayant très peu de droit, je prefere interdire les 
accès à / ecrire et utiliser des formulaires publics

>     * le versionning d'article (en plus de l'historique)
>
pas fait mais, il faudrait ajouter un champ aux versions.
Pour la gestion de versions concurentes, discuté avec Fil sur spip-dev : 
la bonne approche est le clone temporaire qui est simple à mettre en 
place et repond à une grande partie des besoins (mais ne permet pas de 
gerer durablement des branches)
>
>    *
>
>
>     * le multirubriquage
>
Redondant avec la gestion des mots clés les mots clés et dangereux vis à 
vis de la gestion des droits
>
>     * les mots clefs arborescents
>
faisable de differentes manieres avec mots_partout (3 niveaux / n 
niveaux / rhizome ...)
>
>     * la personnalisation de la navigation pour les visiteurs
>
La on parle de squelettes ... et de formulaires
>
>     * DXS
>
La syndication riche marche bien, je prefere cette approche
>
>     * ...
>
J'ajouterai pour mon fork :
    - spipcarto
    - spip_form
    - spip_liste avec mettre par mot clé
    - mots partout
    - formulaires publics avec support des champs extras
    - remplacement des documents dans /ecrire
    - un jeu complet de formulaires pour reproduire naviguer, article et 
article edit
    - une gestion de profil avec mots clés auteurs et champs extras
    - une gestion de profil etendus (n'importe quelle table avec 
id_auteur en clé)
    - une gestion de feuille de style dynamique permettant de changer 
typos couleurs et images de fond par mots clés et documents sur les 
rubriques
    - une gestion de securité et squelettes par mots clés
    - quelques corrections et modifs mineures...
    - A venir egalement le support multidomaine/multilangue pour mapper 
les langues et les domaines sur des secteurs
    - ... j'ai du en oublier encore (spikini entre autre)

J'ai deja expliqué ici que pour moi, Spip etait un framework de 
developpement avant tout.
Un projet comme Agora ne devrait etre qu'une "distribution" : cad un 
ensemble de plugin / contribs (toolkit) / squelettes cohérent et 
préparametré pour faire du "demarrage rapide" de projet.
Je travaille en J2EE avec un generateur de code permettant de construire 
une application "vide de code metier" en quelques heures.
Spip, c'est la meme chose pour construire un application (plutot orienté 
CMS mais avec eventuellement du contenu plus structuré) exploitant un 
cache et avec une bonne gestion des utilisateurs

Je te rappelle que je maintiens mon fork, en plus de spipcarto qui en 
est un autre, seul sur mes temps libre...
Pourquoi voudrais tu que je perde mon temps avec Agora ?
Je me suis agité tant que j'ai pu quand il etait encore temps, avec les 
resultats qu'on connait ...

Je pense que, quand tu auras fait le tour des versions dans la nature et 
des usages qui en sont fait, si tu y arrives ..., il serait "amusant" de 
remettre en face de fonctionnalité les budgets utilisés pour les 
differents deploiement.
En attendant, un projet qui demarre aujourd'hui sur Agora, sauf s'il 
utilise TOUTES les specificités, coutera forcement moins cher sur Spip 
1.9, quitte à developper un ou 2 plugins pour les fonctionnalités 
manquantes.
Mais bon, ca sert à rien de le dire ici, j'ai deja essayé.

Donc, pour te repondre : non, je ne vais pas investir du temps sur 
Agora, sauf si j'ai un projet sur ce produit.
Je n'ai rien contre ce produit, meme si je persiste à penser que c'est 
un lamentable gachi, mais j'ai mieux à faire, c'est tout.

@++