Hi, sorry for late response, quite busy days...
On 28.1.2006 11:45, Oliver Heger wrote:
Yes. There should be versioned shemas on some public server. I guess
API should not change several times a year.
Borut Bolčina wrote:
I understand now. I suppose each configuration class can have a well
defined set of accessor methods (settings) that can be included in
configuration.xml. If so, then making a schema is a no-brainer.
That's correct, but we need to keep in mind that new accessor methods
may be added in a new release. Then the schema has to be updated.
I think it can be done, but yes, it is ugly.
When agreed upon, you can send me sample example files and I will make
an XML Schema (xsd).
Okay, the skeleton of a configuration definition file looks like the
<!-- Definition of configuration sources that override properties -->
<!-- Definition of configuration sources that are combined -->
Both the <override> and <additional> elements are optional. It is
possible that configuration sources are defined outside these elements
(i.e. as direct children of the root node), then they are treated as if
they were placed inside an <override> section. (This is perhaps a bit
ugly, but I fear we will have to keep this because of backwards
I'll look it up.
A definition of a configuration source at the moment simply consists of
one of the tags mentioned in the howto about ConfigurationFactory
It can have attributes that correspond to the setter methods defined in
the configuration class represented by this tag (the information, which
class is used by which tag can also be found in the howto document,
section "The configuration definition file"). I think it will be
necessary to look up the JavaDocs for these classes to find out the set
of attributes needed by a tag.
Those objects can be accounted for by *any* element in schema language,
but this means some sections of the configuration file will not be
validated. Since the majority of them will be simple, a shema will
cover most user needs. In case some complex objects initialization will
become more common, their validation can be added into the schema later.
Currently only primitive values can be set this way. I would like to
enhance this to also support arbitrary objects. This will be required
for things like reloading strategies or expression engines. My idea
about how such a complex declaration could look like is to define these
object settings as sub elements of the tag for the configuration source,
The sub elements' names would correspond to the names of the setter
methods in the configuration class. In theory this game could be
continued if the object defined in the sub element has itself complex
settings, which in turn could be defined in sub (sub) elements. I guess,
here it becomes complex, but such a format would really be convenient to
setup your configurations.
For starters yes.
What do you think? Is this all information you need for a schema?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org