Protokoll BCXMSNG Treffen 2004-03-29

• Anwesend: Chregu Stocker (bitflux), Matthias Stürmer, Emanuel Indermühle (beide foresite), Reto Gassmann (netzwirt.ch), Michael Rolli (Uni BE), Nicola Fankhauser (mediagonal)
• Entschuldigt: Andreas Halter, Sandro Zic, Hannes Gassert (mediagonal)

Probleme mit bitflux

• basiert auf 4 jahre altem code
• output ist gut, input scheisse
• popoon ist gut, aber z.bsp für formulare mühsam

  Neues CMS

• popoon mit einer pipeline, dadurch standardisierte XML transformation
• alles ist plugin

  Aufbau

• collection (verzeichnisse)
• plugins
• resources (xml statischer content)
• config.xml (pro collection, vererbt, zur konfiguration von plugins)

Datenquellen

• mehrere quellen (db, http, file etc.)

Authorisierung & Authentifikation

• zentraler Usermanager kontrolliert, ob der momentane user recht hat, die gewünschte aktion durchzuführen

Strategie

• Framework für content publishing
• Library für plugins oder auch für fremde anwendungen, welche das framework nicht brauchen
• ein GUI creator könnte plugins schnell zu ansehlichen frontends verhelfen (könnte HTML Form Elements von foresite)
• Gasssis GUI form creator könnte als formular editor die formulare aller plugins (front* und backend) editieren (action handlers spezifizieren pro element etc.)

Weiteres Vorgehen

• Foresite: herauseisen und zur verfügung stellen von klassen für html form elements, database structure, list filter
• Mediagonal: plugin-API spezifizieren, beispielsplugins implementieren, klassen von foresite brauchen
• Bitflux: subversion-users für alle, prototyp implementieren
• Alle: im projekt-wiki absolut nötige grunddienste auflisten (authorisierung, authentifizierung, plugin-architektur, storage etc.), auf bitflux-de mailinglist abonnieren