zegor a écrit 3 commentaires

  • [^] # Re: avis apres test de jboss

    Posté par  . En réponse à la dépêche PHP 5 futur concurrent de J2EE et .Net ?. Évalué à 1.

    Quand à python, (j'ai lu ca dans un post plus haut) je n'en parle meme pas. Il ne joue pas dans la meme catégorie. Je suppose que l'auteur voulais parler de Zope & Co. Pour moi c'est inutilisable a grande echelle (sans parler des performances et de la difficulter d'integrer des Products généralement lié à des libs externes incompilables plus du fait que les products sont pour la majorité inutilisable d'une version de Zope a l'autre).

    Dans quelle catégorie places-tu Python ?
    Personnellement, après avoit fait pas mal de Perl et de PHP, je trouve ce langage vraiment excellent. Perl est très expressif mais peu maintenable et PHP est lent (2 à 3 fois plus lent que Perl et Python d'après mes benchs) et trop laxiste. Python est aussi facile à apprendre que PHP, aussi rapide que Perl, lisible et surtout polyvalent, permettant l'écriture de simples scripts à de grosses appli comme Zope.
    Dire que Zope est inutilisable, c'est vraiment méconnaître le produit, qui est utilisé par exemple dans des ministères ou des grosses entreprises comme le CEA, le CNRS, la Nasa, VIACOM à de grandes échelles.
    Pour moi, Python est le meilleur compromis entre rigueur et productivité et je pense qu'il sera de plus en plus utilisé en entreprise dans les prochaines années.
  • [^] # Re: Plone 2.0 dans les bacs

    Posté par  . En réponse à la dépêche Plone 2.0 dans les bacs. Évalué à 1.

    Bonjour à tous,

    Je viens de regarder Xoops.
    En effet, par rapport à phpNuke et compagnie, il est bien mieux codé. Il utilise des templates smarty et des classes.
    Pas mal de modules, mais je trouve qu'il y a un peu trop de hacks, ce qui prouverait que le système n'est pas aussi modulaire que ça.
    De plus, il manque apparemment l'authentification LDAP et un moteur de workflow, ce qui est très génant pour un CMS.
    Xoops est clairement plus orienté portail que CMS, contrairement à SPIP ou Typo 3.

    SPIP a le mérite d'être simple, rapide et permet un grande liberté de présentation. Par contre, il est codé à l'ancienne (php3, code monolitihique, pas de classe, code php et html mélangé) et n'est donc pas du tout modulaire.
    SPIP est donc une bonne solution si il répond à 95% de vos besoins. Sinon, bonjour la bidouille !

    Typo3 offre une interface de backoffice très complète et très pro. Mais elle est très (trop) touffue ! Plein de petites icônes de partout désorientent l'utilisateur lambda : surcharge cognitive assurée !
    Côté code, Typo 3 n'est pas vraiement objet. Plein d'appels statiques à des méthodes de classes qui sont plutôt des containers qu'autre chose.
    Typo3 utilise son langage à lui, le typoscript, possède son propre langage de template. Un peu trop fermé à mon goût.

    J'ai regardé aussi Xaraya, qui va bientôt sortir en version 1.0. C'est un vrai framework, très modulaire et extensible. Mais d'après un collègue, il rame dur. Xaraya semble pousse PHP dans ses derniers retranchements. Un produit à suivre.

    Et j'en ai regardé pleins d'autres, en PHP ou Java... Aucun n'arrive au niveau de Plone ou de CPS, en terme de maturité, d'ergonomie, de modularité. Aucun ne sont allés aussi loin dans la vision objet et la réutilisabilité des composants.

    Pour moi, Plone et CPS sont les CMS libres les plus adaptés pour des besoins d'entreprises et peuvent concurrencer par mal de solutions propriétaires J2EE. Les solutions PHP sont encore trop éparpillées du fait de l'absence d'un véritable framework standard.
  • [^] # Re: Plone 2.0 dans les bacs

    Posté par  . En réponse à la dépêche Plone 2.0 dans les bacs. Évalué à 1.

    J'utilise Zope depuis plus de 2 ans à mon travail et je n'ai jamais eu le moindre plantage ni perte de donnée.
    Je trouve Zope au contraire être une solution très fiable. Et comme la base est transactionnelle, il est toujours possible de revenir en arrière.
    Par contre, j'ai eu plus de problèmes avec MySQL ou des serveurs J2EE qui partaient en vrille de façon aléatoire...