wow

• [^]Re: wow

  Posté par Stéphane P. () le 25/05/2007 à 10:44. (lien). Évalué à 3.

  C'est effectivement une approche plus "lourde" que de taper un document dans un traitement de texte, SCENARI n'a pas la prétention de s'y substituer pour tous les types d'usage.
  
  Le positionnement de ces outils est expliqué sur cette page, ils ciblent effectivement plus les professionnels :
  http://scenari-platform.org/projects/scenari/fr/pres/co/posi(...)
  
  Par exemple : une SSII qui voudrait fournir une application de saisie du document de type X a l'entreprise Y, Y ayant aussi besoin de l'imprimer et de mettre les mêmes informations sur son site web.
  
  Mais il reste le niveau "auteur de document" qui est accessible au grand publique. La seul particularité que j'ai oublié de mentionner dans la news est le mode de rédaction du type WYSIWYM : l'auteur doit chercher a donner un sens et une structure au texte, et non a le mettre en forme.
  http://fr.wikipedia.org/wiki/What_you_see_is_what_you_mean
  
  C'est pour cela que nous commençons par bien mettre en avant SCENARIdiscovery que je recommande à essayer avant tous les autres programmes.

  • [^]Re: wow

    Posté par Cyprien Le Pannérer (Jabber id, page perso, ) le 25/05/2007 à 11:42. (lien). Évalué à 1.

    J'ai pas encore eu le temps de tester mais après une rapide lecture du site ça me semble assez proche de xmlmind xml editor[1] comme concept.
    Si c'est le cas ça offre les mêmes possiblités.
    
    [1]http://www.xmlmind.com/xmleditor/

• [+] [^]Re: wow

  Posté par Antoine () le 25/05/2007 à 11:23. (lien). Évalué à -3.

  c'est assez revolutionnaire non ?
  
  Mouahaha. A lire la description ça fait penser surtout à une solution qui serait à la recherche du problème à résoudre.
  
  Attention aux beaux morceaux de pipeau : « SCENARI se positionne comme un SGCE, Système de Gestion de Chaînes Editoriales. C'est une démarche novatrice qui allie une approche structurée telle que nous la connaissons dans les bases de données à la manipulation de contenus documentaires multimédia. »
  
  Les jolis chiffres trop ronds pour être vrais : « L'arrivée de SCENARIbuilder en 2006 nous a permis de diviser par 10 les temps de réalisation d'une chaîne éditoriale ».
  
  Et finalement une belle régression : « En un « clic souris » le contenu produit par l'auteur est transformé en site web respectueux des standards HTML qui peut ensuite être transféré par FTP sur un serveur web. » A l'ère des systèmes de gestion de contenu et autres sites Web dynamiques, on nous ressort un bidule de génération offline de contenus statiques...

  • [^]Re: wow

    Posté par √λιi () le 25/05/2007 à 11:49. (lien). Évalué à 3.

    C'est sur c'est tellement plus malin de mettre en oeuvre un site dynamique avec du CGI/FCGI/mod_machin quand on met a jour le contenu une fois par semaine (ou moins) au lieu de délivrer du contenu statique.
    
    Cet usage est sans doutes approprié pour 90% des sites web d'entreprise (hors support), les 10% restants étant soit trop gros soit trop hype.
    
    /me a la recherche d'un soft que création de pages web structurées, avec menus/onglets, basé sur des templates, _statique_ et souple (et qui pourrait bien avoir trouvé sa solution)

    • [+] [^]Re: wow

      Posté par Antoine () le 31/05/2007 à 10:58. (lien). Évalué à -1.

      C'est sur c'est tellement plus malin de mettre en oeuvre un site dynamique avec du CGI/FCGI/mod_machin quand on met a jour le contenu une fois par semaine (ou moins) au lieu de délivrer du contenu statique.
      
      Si on écarte les questions de performance, c'est en effet certainement plus malin.
      Ta remarque revient à dire "je mets à jour mon code une fois tous les trois semaines, je n'ai pas besoin de Subversion/CVS/Bazaar/que sais-je, il suffit d'uploader les modifs à la main". A moyen terme on se rend vite compte que c'est une erreur.

      • [^]Re: wow

        Posté par TeXitoi (Jabber id, page perso, ) le 31/05/2007 à 12:06. (lien). Évalué à 2.

        Non, c'est pas parce que le site est statique que c'est intégrallement géré à la main : dans notre cas, SENARI gère tout automatiquement et génère hors ligne les pages statiques, ce qui est bien différent de ce que tu dis.

  • [^]Re: wow

    Posté par Stéphane P. () le 25/05/2007 à 12:21. (lien). Évalué à 7.

    Mouahaha. A lire la description ça fait penser surtout à une solution qui serait à la recherche du problème à résoudre.
    Il ne faut évidement pas chercher a tout remplacer par des chaînes éditoriales. Mais pour certaines tâches de production de document, et de vrais utilisateurs derrière :
    http://scenari-platform.org/projects/scenari/fr/showroom/co/
    
    Les jolis chiffres trop ronds pour être vrais : « L'arrivée de SCENARIbuilder en 2006 nous a permis de diviser par 10 les temps de réalisation d'une chaîne éditoriale ».
    Attention, on ne dis pas ici que les utilisateurs de la chaîne éditoriale vont passer 10 fois moi de temps a écrire leur documents, mais que nous avons vraiment gagné cet ordre de grandeur en temps de conception d'une nouvelle chaîne pour un nouveau type de document. En ce qui concerne les temps de travail des personnes sur le projet, il est difficile de faire mieux qu'un ordre de grandeur, il n'aurait pas été une preuve de bonne fois de dire "nous avons gagner 1027.42% en temps de conception de nos chaînes éditoriales".
    
    A l'ère des systèmes de gestion de contenu et autres sites Web dynamiques, on nous ressort un bidule de génération offline de contenus statiques...
    Je ne sais pas trop quoi dire, je ne voit pas en quoi le fait qu'une technologie soit "dans l'ère du temps" signifie que toutes les autres approches sont mauvaises. De plus, une chaîne éditoriale n'est pas forcément locale, mais le stockage des données, la génération, et le déploiement peuvent aussi être pris en charge par un SCENARIserver.
    
    Cela n'offre pas bien sur les mêmes possibilités qu'un système "coté serveur" : l'objectif est de produire des documents, pas de faire un forum ou un lecteur mail. Dans ce cas, la production de HTML statique n'est pas forcément une abomination, a mon humble avis, a partir du moment ou le stockage du contenu est totalement indépendant de ce format, pour pouvoir se garder une ouverture vers les autres.
    
    Pour finir, je trouve dommage ce jugement si rapide d'une nouvelle technologie. Je vous invite a approfondir votre jugement ou tout simplement, a ignorer ce projet s'il ne correspond pas a ce que vous voulez faire.

    • [^]Re: wow

      Posté par Antoine () le 31/05/2007 à 10:55. (lien). Évalué à 0.

      Cela n'offre pas bien sur les mêmes possibilités qu'un système "coté serveur" : l'objectif est de produire des documents, pas de faire un forum ou un lecteur mail.
      
      Les sites Web dynamiques, ça ne se limite pas à des forums ou à des lecteurs mail. Cela permet justement de "produire des documents"... sans avoir à passer par une chaîne de production offline.
      Tu as dû entendre parler de Wikipédia.
      
      Pour finir, je trouve dommage ce jugement si rapide d'une nouvelle technologie
      
      Non, le problème c'est qu'on ne sait toujours pas ce que cette "technologie" (terme prétentieux et inadapté) a de "nouveau".
      Les systèmes de génération offline de contenus statiques, ça existe depuis belle lurette, que ce soit à base de scripts faits maison ou diverses usines plus ou moins génériques.

      • [^]Re: mediawiki (et SPIP) en complément de Scenari

        Posté par PascalBoulerie () le 20/06/2007 à 13:30. (lien). Évalué à 1.

        Pour répondre à la suggestion d'Antoine du 31/05/2007 à 12 h 55 :
        
        D'où tout simplement l'utilité d'un site mediawiki, en complément d'un contenu Scenari. :-)
        
        Mes collègues ont même en parallèle établi un site SPIP pour gérer une autre partie du contenu de leur site, le tout sera appelé à cohabiter en bonne entente. :-)
        
        Chaque outil ayant ses avantages et ses inconvénients.
        
        PS Après tout, ce n'est que le début de la révolution du web 2.0...

Intégration

• [^]Re: Intégration

  Posté par Stéphane P. () le 25/05/2007 à 12:47. (lien). Évalué à 1.

  Si vous souhaitez écrire un éditeur de courrier totalement générique, SCENARI n'est pas fait pour vous.
  
  Si vous souhaitez écrire un éditeur basé sur certaines structures de "lettres types", dans un cas d'usage précis, SCENARI pourrait répondre a cette partie de la problématique, mais pas du tout aux autres problèmes d'accès, de workflow, ou de gestion de base de donnée, et ne permet pas de créer des éditeurs embarqués dans d'autres applications.
  
  La seule fonctionnalité actuellement développée est la gestion de scripts de déploiements : une fois votre génération effectuée, vous pouvez (au moins en SCENARIserveur) démarrer votre script ant, qui vous laisse la main pour transmettre à d'éventuels programmes tiers les sources XML et les documents publiés. Mais cela deviens un peu compliqué à réaliser, tout comme apprendre a créer son propre modèle documentaire, à cause pour l'instant du manque de documentation sur SCENARIbuilder, et du fait que cela ne ressemble pas a grand chose d'autre au niveau "développement".

Basé sur Gecko

Interessant

• [^]Re: Interessant

  Posté par Stéphane P. () le 25/05/2007 à 13:12. (lien). Évalué à 2.

  Scenari fonctionne selon une architecture cleint/serveur
  D'un point de vu utilisateur, c'est au choix. SCENARIdiscovery est l'exemple d'une application unique. Meme si les générations s'obtiennent par ouverture d'un firefox sur des adresses en http://127.0.0.1, SCENARI ne dois pas être utilisé comme un serveur web autrement que pour avoir un apperçu.
  
  est-ce qu'il s'appuie sur une base de donnée?
  Non, tout le contenu est produit en XML.
  
  une interface web est prevue?
  A priori non. Au moment ou les développements ont commencé, le web2, l'ajax et les exemples de suites bureautique google n'était pas encore très médiatisés, il y aurait beaucoup a changer.
  
  Après, la seule chose qui m'empeche d'en parler à ma DSI, c'est c'est la dependance à openoffice...
  Et oui :( On voit ça trop souvant.
  - Si le problème est que OpenOffice s'ouvre : on pourrait le cacher, et générer directement un PDF en arrière plan, on le fait pour la publication web du CV qui comme vous l'avez peut être remarqué fait un lien vers la version PDF générée en même temps.
  - Si le problème est qu'il faut l'installer : en mode "client / serveur", le serveur prend en charge la génération (pas terrible de lancer un openoffice writter en xvfb sur un serveur mais on a rien trouvé de mieux).
  - Concernant les autres formats, les développeurs réfléchissent aux alternatives envisageable, cherchant quelque chose qui donnerait plus de possibilités pour la mise en page (prudemment, car cela prend beaucoup de temps).

  • [^]Re: base de données XML ?

    Posté par PascalBoulerie () le 20/06/2007 à 13:40. (lien). Évalué à 1.

    Une idée : et en s'interfaçant avec un logiciel de base de données traitant des données au format XML ?

Bravo !

Pas mal

• [^]Re: Pas mal

  Posté par Maxime GARCIA (page perso, ) le 25/05/2007 à 17:27. (lien). Évalué à 1.

  Le projet est bien trop jeune, il y a une absence totale de documentation pour SCENARIbuild qui permet de faire les modélisations.
  
  Du coup, impossible de créer quelque chose de spécifique, même très simple.
  
  Il n'y a que les formations à 1500¤ la semaine.
  
  Je passe donc mon chemin. On verra plus tard quand la documentation sera créée.

  --
  Un clavier azerty en vaut deux.

  • [^]Re: Pas mal

    Posté par Stéphane P. () le 25/05/2007 à 18:45. (lien). Évalué à 2.

    C'est effectivement une critique très recevable, un développeur a répondu à cette question récemment :
    http://scenari-platform.org/forum/viewtopic.php?p=1543#1543
    
    Le projet en lui même n'est pas si jeune, les travaux on commencés en 1999. Mais l'outil SCENARIbuilder n'existe que depuis 2 ans et pour l'instant, le nombre de personnes qui conçoivent des modèles est assez réduit.
    
    L'utilisation plutôt orienté vers les professionnels fonctionne plutôt souvent sur le mode partenariat / formation / suivi. D'autant plus que l'idée d'avoir plein de personne intéressé par la méthode plutôt que les résultats est pour une fois une bonne surprise, on est plus habitué à l'inverse. J'imagine qu'il y a 10 ans, on imaginait mal mysql (ou postgresql, pas de jaloux :) ) se retrouver à la porté du premier geek venu.
    
    Mais comme on cherche à en faire profiter plus de monde ce manque de documentation est effectivement dans nos préoccupations premières. J'espère que nous serons y répondre d'ici quelques mois (il y a vraiment beaucoup de nouveaux concepts à expliquer pour faire quelque chose de bien).

• [^]Re: Pas mal

  Posté par Stéphane P. () le 25/05/2007 à 18:04. (lien). Évalué à 1.

  Dans cette version, les outils SCENARI reposent sur openoffice pour l'édition et la publication des tableaux. Donc en fonction du modèle il est possible d'autoriser ou non l'insertion de ces tableaux. A la génération, rien a signaler lors de la publication OpenOffice, mais dans la publication web, ils sont transformés en images.
  
  Nous sommes conscient de ce type de limite, c'est une des évolutions envisagés : développer un composant natif SCENARI pour avoir une gestion plus propre et plus légère des tableaux.
  http://scenari-platform.org/projects/scenari/fr/commu/co/tab(...)
  
  Aussi, avez-vous eu connaissance d'un déploiement de SCENARIserver sur Debian. Il y a t'il un paquet ?
  Non, nous n'avons pas pour l'instant fait de packets pour chaque distribution. J'ai déjà installé un SCENARIserver sous Ubuntu et suse, ce n'est pas le moyen le plus simple de commencer. A noter que si vous souhaitez une vrai édition collaborative, vous avez peut être intérêt a partager les contenus avec subversion, nous n'avons rien du coté des historiques ou des résolutions de conflits. Dans nos cas d'usage spécifiques, les auteurs travaillait sur des documents différents ou des parties différentes d'un même document constitués de plusieurs fichiers.
  (notez aussi que nous ne sommes pas encore parfait a ce niveau : http://scenari-platform.org/projects/scenari/fr/commu/co/sub(...) )
  
  Vous dîtes que vous n'êtes pas arrivé à générer du PDF autrement que par OOo ?
  C'est pour l'instant un choix technique. Je ne suis pas expert du domaine mais voici des éléments de réponse :
  - le framework SCENARI a été développé pour permettre la transformation des fichiers de contenu XML en fichiers OpenDocument Text a l'aide des librairies d'openoffice.
  - a partir d'openoffice, l'auteur génère le PDF en 1 clic, ou on automatise ce passage .odt -> .pdf avec openoffice exécuté de manière transparante en arrière plan.
  - on pourrait avoir plein de bonnes idées du style SCENARI -> latex -> pdf mais la partie SCENARI -> latex prendrait beaucoup de temps a développer, car il faudrait rétablir toutes nos fonctionnalités sans régression (stylage, table des matières, index, glossaire, intégration des images).

  • [^]Re: Pas mal

    Posté par Maxime GARCIA (page perso, ) le 25/05/2007 à 19:53. (lien). Évalué à 2.

    Merci pour vos deux réponses.
    
    Pour les tableaux, la conversion en image pour l'export web est une voie de simplicité dans le développement, mais bon, on peut pas tout avoir tout de suite. Il y a toujours des priorités. Ce sera une très bonne chose quand ils seront rendus en vrai tableaux.
    
    Pour la documentation, votre approche est plus que louable, le projet ayant l'air très solide, il ne manque plus qu'elle pour décoller à "plus large échelle". Je l'attends donc avec impatience.
    
    Le côté "ça m'embête d'installer depuis des sources une appli sur mon serveur de production debian" m'a aussi fait pensé à SVN ou subversion pour gérer le côté collaboratif du travail manquant dans SCENARIchain. Un peu lourd à l'utilisation (certes moins que rédiger tout artisanalement) mais simple à mettre en place. Il faut donc en avoir vraiment besoin (surtout de la concurence de version avec historique), pour moi c'est pas vraiment nécessaire.
    
    Pour le pdf, j'ai pu voir un projet montant d'ERP (TinyERP)utilisant le RML.
    voir ici : http://tinyerp.org/wiki/index.php/TechnicalDocumentation/Rep(...)
    Il est écrit en python, la conversion en RML nécessite une édition OOo, mais le flux de départ est bien du XML. Cette approche est très similaire à celle de SCENARI (à ce que j'ai pu voir pdt l'heure que j'ai passé dessus...) où il est nécessaire d'apporter un XSL.
    Je vous donne cela à titre indicatif, peut-être cela suscitera quelques idées de part chez vous.
    (Le recours à latex étant quelque peu brutal je l'avoue, et la volonté de garder un odt qui est éditable est plutôt compréhensible)
    
    Merci encore de votre attention.

    --
    Un clavier azerty en vaut deux.

Et vis à vis de DocBook ?

• [^]Re: Et vis à vis de DocBook ?

  Posté par Stéphane P. () le 31/05/2007 à 11:59. (lien). Évalué à 3.

  Forcément, cela a un avantage majeur si on a un besoin bien spécifique (moins complexe ou plus précis que DocBook) qui reviens très très souvent. Auquel cas il est rentable d'investir dans la définition d'une structure.
  Vous avez bien fait cette distinction et c'est l'élément principal de la réponse : SCENARI ne cherche pas a couvrir tous les besoins avec un même modèle, mais propose d'identifier des types de documents, et de concevoir le modèle correspondant. Pour moi c'est ce qui distingue une chaîne éditoriale d'un "compilateur de texte" (sans aucune connotation péjorative ou manque de respect pour les programmes de cette catégorie)
  
  Je ne suis pas un expert LaTeX ou DocBook mais je vais essayer de faire ce mini comparatif :
  - SCENARI se base sur des modèles de documents qui définissent les information a saisir et la manière dont elles sont publiés. LaTeX permet d'avoir a peu près la même souplesse qu'un traitement de texte, et DocBook si j'ai bien compris est un peu entre 2 et propose "sa propre DTD générique qui couvre tous les besoins".
  - Créer un modèle SCENARI prend du temps et demande de se plonger dedans : avec docbook, la DTD est déjà prête et j'imagine que le travail de rendu est déjà "préparé".
  - Une fois le modèle créé, l'auteur doit le respecter, et est guidé dans l'éditeur personnalisé pour le modèle. Cet éditeur peux être redifusé en "standalone", et convient aux débutants de l'informatique.
  - Tout est prévu pour que le créateur du modèle et celui qui l'utilise soit 2 personnes différentes : le niveau modélisateur (SCENARIbuilder) reste "poilu", mais celui de l'auteur (SCENARIdiscovery, ou les modèles dans SCENARIchain) est simple, et l'auteur n'a pas la main sur le rendu. (chacun fait un travail différent dans l'esprit du "travail a la chaîne", que l'on retrouve sur le schéma de cette page : http://scenari-platform.org/projects/scenari/fr/pres/co/logi(...) )
  - SCENARI permet d'intégrer des éléments multi-media dans les modèles et des exercices (cf modèle webradio et iris).
  
  
  Si la structure de vos documents est complètement imprévisible et différente d'un jours a l'autre, dans ce cas SCENARI n'est pas la meilleur réponse. Il n'est pas fait pour être "équivalent à un traitement de texte en plus propre".
  
  Il n'est pas prévu de créer un "modèle équivalent DocBook", et j'ai du mal a voir comment serait conçu le rendu si on le transposait dans le système SCENARI (le modélisateur ne sais pas à l'avance ce que l'auteur veux car trop générique, et l'auteur ne peux pas le changer lui même).
  
  Les modèles les plus "larges" que l'on ait actuellement doivent être ShowOrg et Report , les modèles de présentation d'une entreprise et d'écritures de rapport, qui pourrait tout de même être utilisés tel quel et détourné dans d'autres types de contenus qui parlent de n'importe quoi. C'est possible, mais ce n'est pas notre objectif de développer cette voie, il y a déjà plein de programmes mieux que SCENARI pour faire ça.

C'est beau !

• [^]Re: C'est beau !

  Posté par Loïc Alejandro (page perso, ) le 15/06/2007 à 12:00. (lien). Évalué à 1.

  Bonjour, je suis le designer de scenari-platform.
  Merci pour le compliment.

essai (ne pas publier)