Thursday 24 July 2003 1:19:14 am
For eZ publish 3.2 we are currently working with the new class import/export system. For the basis of this we are starting the work on a package system which could be used for handling any kind of contributions or site exports. For 3.2 we will only have time for the class (with templates) export.
A short overview of the package system.
Central to the system is the package definition which is an XML format defining what the package contains, who made etc, what is required for it to work etc.. It's loosely based on the RPM and PEAR package formats.
The package definition will be placed in an archive file of some sort. We will probably use tar.gz or zip files (maybe both). A document of the package format will be added at a later time. Here's some of my ideas on how the package system should work (in the future).
1.
Create a package module which will store all package data in db tables.
For instance you will start a new project/package, create a new release and add entries to the release.
Possible entries are just about anything the eZ publish system has available. For instance you could pick classes for export, nodes/objects with children, datatypes, workflowevents, modules, design and plain files. You could manage documentation for the package using eZ publish objects and export it to a general xml format which is included in the package. Since all data is in the DB you can go back to the project, improve you templates or add new entries to the class and then create a new release and export the package again.
2.
Allow people on ez.no to start projects. They could request a custom eZ publish installation in which they can do development, create new datatypes, new modules etc. all from the web browser (or with webdav, soap).
When they are making a release they would export the package file and send a soap request (automatically) to ez.no for upload to contributions. I think this would boost development of eZ publish parts and it would also make it easier for many people to work together on a project.
3. Detect packages in contribution upload. If it is detected a more advanced page is shown with all relevant information from the package. This avoids the need to repeat changelogs and descriptions which are already in the package.
4.
Allow the package system to work with svn, it could for instance fetch the difference between two revisions and include the diff in the package. This would make it a lot easier to create security and important bugfixes.
5. Download new packages from ez.no. This can be addons made by eZ system or contributed packages by the community. Any comments?
--
Amos
Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq
|