Bitflux CMS Next Generation
See also PlansIdeas for a little bit more stuctured overview
- popoon is still the underlying framework
- An URL based content scheme as the basic idea. This allows to use HTTP and WebDAV methods only for accessing almost the whole content. In the ideal world, you could manage your content only using WebDAV. Unfortunately WinXP has broken WebDAV support and you can't set and get random properties with most WebDAV clients, so it still needs a a fully functional admin-webinterface.
- From the WebDAV point of view, everything is either a folder or a file. We basically give up the idea of "Sections/Documents/Objects/Subobjects". Sections and Documents become folders, the rest files (some objects will be folders, too, as for example the media object). One "porting" task will then be, to build the old CMS structure to the new one to make upgrading a relatively painless task.
- Content is saved as files, metadata saved as WebDAV properties. We only have a very light DB-layer for the properties (as implemented in the HTTP_WebDAV_Server_Filesystem task). This still allows fast searching and "linking", but should be more flexible. DB-based content can of course still be maintained and used and saving as files is just the default.
- subversion is used for history/"workflow"/preview stuff. as the main content is stored via a webdav interface, talking with subversion shouldn't be a big deal (it does even versioning on properties)
- Plugins. Today's BXCMS doesn't have plugin support. You had to make popoon components, which was not ideal in every case. With BXCMS-NG, this should be much easier. just drop a plugin.xml in a directory and if it's correct, everything else works automatically. down to the admin interface. The plugin has to follow a special class-interface, of course. This mechanism would maybe also be used for DB-based content.
- Everything I/O related is using streams . this allows to use them also in other places than just the cms. I already wrote a tidy-xhtml and openoffice.org stream class.
- Userauthentication is done with http-auth. We need that for webdav clients anyway, so why not use it everywhere (we still can use other mechanisms later, if we want)
- Content is usually edited with BXE or epoz. form based editing is only used for DB based stuff like adresses et al.
- Workflow/usermanagement: Nothing decided yet here, but as it is basically a filesystem at the end, at least usermanagement should be easy to implement
- caching. implemented by default to make it fast
- PHP5? not sure yet. everything in mind above is also possible with php4... maybe just to it for both right now (this would need a xml-compa-layer for one or the other, but not a big task imho)
- OO as much as it makes sense
- ZZOSS Installer for easy installation
- A technique should be applied so the usual customer specific customiziations (show/hide fields, tables, options etc.) are stored in a external file or in a db entry. When a new version with extended functionality of the cms is released it should be possible to install it quickly on all customer systems and no nasty walk-through the code should be necessary to implement new features in a older customer installation. (Thats what I'm spending my time now with the foresite CMS....) MatthiasStuermer
- Are there any plans to integrate LDAP Authentification? Not that I would have any idea how this works...
MatthiasStuermer
Add Comment