Log in
Forgot your password?
Silva Metadata Roadmap
A roadmap for future development of Silva Metadata.
Copyright (c) 2003 Infrae. All rights reserved.
See also LICENSE.txt
Meta:
Valid for: SilvaMetadata 0.7.x
Author: Martijn Faassen
Email: <[email protected]>
CVS: $Revision: 1.2 $
================
Metadata roadmap
================
In brief
========
Short term
* XML serialization cleanups.
* Installation/registration API cleanups.
* Support CMF and Silva at the same time.
Medium term
* Use Formulator improvements.
* User interface revision.
* Use Formulator XML serialization.
* SilvaMetadata responsibile for getting and setting data.
Long term
* Integration of different schema systems.
Short term
==========
XML serialization cleanups
--------------------------
XML serialization should be cleaned up. XML structure should be
grouped by set, this way the XML will be less cluttered as a default
namespace can be set per set. Since the schema contains sufficient
information it should not be necessary to add type information to the
export, though some Formulator improvement may be necessary here.
Installation/registration API cleanups
--------------------------------------
It is at the moment necessary to register with the metadata system
multiple times; during product startup meta types need to be
registered to work with the metadata system at all, and the set
initializations need to happen during installation time (in Silva in
install.py). It should be possible to make a particular type of object
useful with the metadata system and to define which sets are
associated with a single function call.
Additionally, the way the set associations are set up are at the
moment strongly influenced by the metadata user interface code and
need the construction of specially formatted strings. This is ugly and
needs to be fixed.
Support CMF and Silva at the same time
--------------------------------------
CMF and Silva cannot currently use the metadata system at the same
time, as this is hardcoded in Configuration.py in SilvaMetadata. Since
people may want to install CMF and Silva in the same Zope instance, it
is important that the code is adjusted so that this is possible.
Medium term
===========
Use Formulator improvements
---------------------------
Formulator (on a branch currently) has a bunch of improvements that
separate out the conversion and validation code. The metadata system
should need less hacks to use Formulator's validation code as a
result.
As an example of what should be fixed is the need to pass UTF-8
values into the metadata system as Formulator expects UTF-8 through
the web. Unicode strings directly should be sufficient.
User interface revision
-----------------------
The current user interface can be improved in a number of ways. One
direction we could take is a structuring that makes it more easy to
plug in other schema/form systems as well.
Use Formulator XML serialization
--------------------------------
SilvaMetadata uses an incompatible home-grown serialization of
Formulator forms. This is bad from a maintainance point of view.
Formulator's should be used and forms should be exported as a whole,
not mixed with the other information.
SilvaMetadata responsible for getting and setting data
------------------------------------------------------
It is desirable to have computed metadata fields. Currently Formulator
fields need a TALES override for their 'default' value to make this
work. Dependency on Formulator should go away and SilvaMetadata should
grow a facility to retrieve computed data from underlying objects.
TALES expressions should not be necessary either.
Formulator's responsibilities should be restricted to:
* conversion of entered REQUEST data.
* validation of data (from REQUEST or serialized).
* helping with (de)serialization of data to/from XML.
* help with rendering data to be viewed on a web page.
SilvaMetadata should be responsible for getting the data (either from
its own storage or computed) and setting (either to its own storage or
possibly side-effect setting as well).
Long term
=========
Integration of different schema systems
---------------------------------------
Through repeated refactorings, SilvaMetadata should grow to its
essential core and at the same time increase its flexibility. It should
allow for the plugging in of different schema/form systems, such as
Archetypes or Zope 3 Schema/Forms.
Of course these systems differ in their capabilities. Some take more
responsibilities than others. As an example, Formulator has a TTW UI,
while Archetypes also has facilities to take care of data storage. It
remains to be seen how well such diverse systems can be managed by
SilvaMetadata. Keeping such a thing in mind as a long term goal
however does move the system in the right direction even if the
goal is actually never reached.
See also LICENSE.txt
Meta:
Valid for: SilvaMetadata 0.7.x
Author: Martijn Faassen
Email: <[email protected]>
CVS: $Revision: 1.2 $
================
Metadata roadmap
================
In brief
========
Short term
* XML serialization cleanups.
* Installation/registration API cleanups.
* Support CMF and Silva at the same time.
Medium term
* Use Formulator improvements.
* User interface revision.
* Use Formulator XML serialization.
* SilvaMetadata responsibile for getting and setting data.
Long term
* Integration of different schema systems.
Short term
==========
XML serialization cleanups
--------------------------
XML serialization should be cleaned up. XML structure should be
grouped by set, this way the XML will be less cluttered as a default
namespace can be set per set. Since the schema contains sufficient
information it should not be necessary to add type information to the
export, though some Formulator improvement may be necessary here.
Installation/registration API cleanups
--------------------------------------
It is at the moment necessary to register with the metadata system
multiple times; during product startup meta types need to be
registered to work with the metadata system at all, and the set
initializations need to happen during installation time (in Silva in
install.py). It should be possible to make a particular type of object
useful with the metadata system and to define which sets are
associated with a single function call.
Additionally, the way the set associations are set up are at the
moment strongly influenced by the metadata user interface code and
need the construction of specially formatted strings. This is ugly and
needs to be fixed.
Support CMF and Silva at the same time
--------------------------------------
CMF and Silva cannot currently use the metadata system at the same
time, as this is hardcoded in Configuration.py in SilvaMetadata. Since
people may want to install CMF and Silva in the same Zope instance, it
is important that the code is adjusted so that this is possible.
Medium term
===========
Use Formulator improvements
---------------------------
Formulator (on a branch currently) has a bunch of improvements that
separate out the conversion and validation code. The metadata system
should need less hacks to use Formulator's validation code as a
result.
As an example of what should be fixed is the need to pass UTF-8
values into the metadata system as Formulator expects UTF-8 through
the web. Unicode strings directly should be sufficient.
User interface revision
-----------------------
The current user interface can be improved in a number of ways. One
direction we could take is a structuring that makes it more easy to
plug in other schema/form systems as well.
Use Formulator XML serialization
--------------------------------
SilvaMetadata uses an incompatible home-grown serialization of
Formulator forms. This is bad from a maintainance point of view.
Formulator's should be used and forms should be exported as a whole,
not mixed with the other information.
SilvaMetadata responsible for getting and setting data
------------------------------------------------------
It is desirable to have computed metadata fields. Currently Formulator
fields need a TALES override for their 'default' value to make this
work. Dependency on Formulator should go away and SilvaMetadata should
grow a facility to retrieve computed data from underlying objects.
TALES expressions should not be necessary either.
Formulator's responsibilities should be restricted to:
* conversion of entered REQUEST data.
* validation of data (from REQUEST or serialized).
* helping with (de)serialization of data to/from XML.
* help with rendering data to be viewed on a web page.
SilvaMetadata should be responsible for getting the data (either from
its own storage or computed) and setting (either to its own storage or
possibly side-effect setting as well).
Long term
=========
Integration of different schema systems
---------------------------------------
Through repeated refactorings, SilvaMetadata should grow to its
essential core and at the same time increase its flexibility. It should
allow for the plugging in of different schema/form systems, such as
Archetypes or Zope 3 Schema/Forms.
Of course these systems differ in their capabilities. Some take more
responsibilities than others. As an example, Formulator has a TTW UI,
while Archetypes also has facilities to take care of data storage. It
remains to be seen how well such diverse systems can be managed by
SilvaMetadata. Keeping such a thing in mind as a long term goal
however does move the system in the right direction even if the
goal is actually never reached.