Cromlech

Pourquoi

  • qui on est
  • nos besoins
    • scalabilité
    • maitrise de tous les composants pour ne payer que ce qu'on utilise maitrise des dépendances
    • maitrise des composants pour choisir vraiment et explicitement son architecture
    • vrai stack wsgi pour utiliser middleware, context manager etc... (utilisation quelque soit le serveur)
    • chaque projet assemble ses éléments dans son code de manière simple
    • framework orienté développeur, pas intégrateur, plus toolkit

existant

  • limites de grok

    • lutte contre zope
    • complexité de la "magie" grok
  • dolmen

    • un boostrapper de projets grok
    • basé sur l'inclusion du zcml de paquets fournissants des composants bien bornés
    • dolmen.xxx utilisable sans dolmen, standalone (ex dolmen.layout, dolmen.blob, dolmen.content, etc...)
    • .app paquets d'intégrations
    • .menhir de démo
    • pas de succés communautaire, mais des projets réalisés
  • comparaison pyramid

  • virer zope

    • mélange description implémentation, limite utilisation
      • zope.browser
    • zope.publisher partout et ammenant tout le ztk
    • zope.publisher fait trop, est monolithique est trop complexe il mélange publication, gestion session, authentification, gestion des io (// pyramide)
    • pb scalabilité thread de session ZODB utilisé pour le traitement de la requête, donc limitté en nombre et ouverture permanente de la zodb
    • limiter le nombre de package emporté
    • building over a pile of crap
  • garder la ZCA et autres

Ce qu'on a fait

Création des classes de bases : cromlech.io, cromlech.browser qui donne la clé de lecture de l'application web cromlech (requete, réponse) puis les composants en interaction publisher, vue, etc.… et coté modèle cromlech.container et dolmen.content (pas de spécification du modèle en lui même car ce sont les objets python). Les éléments de base ne pré-suppose pas l'utilisation de la ZCA (pas de context/request ou appel direct de vue dans une appli wsgi).

Tous les éléments de traitement http sont capable de renvoyer une réponse (donc la encore utilisation isolée possible) et compatibilté wsgi.

Le publisher est limité à son rôle.

Le prix a payé pour lacher zope.publisher notament, mais pas uniquement, a été cher, pas mal de fork d'un trentaine de package (viewlet, location, …) on a forké zope aussi car la plupart des implémentation héritait de Persistent par exemple dans zope.container ou dolmen.content.

Utilisation aisée et découplée de Chaméléon 2, fanstatic, beaker

Portage de la plupart des paquets de dolmen

Premiers retours d'expérience projets