Hi,
This sounds familiar - was it you or Fede who said we would never need
Namespace info last time ? ;)
On Fri, 21 Sep 2001 04:00, Berin Loritsch wrote:
> The delimna is that we need to provide a solution that is:
> * Easy to use
> * Provides minimal impact on the current API
> * Satisfies a need
> * Easily extendable
works for me.
> The Configuration object's use can be further helped by the
> following additional information: Namespace and Qualified name.
> The Configuration object specifies the method getLocation().
> It's use is not well documented, so it can be purposed to record
> the namespace.
*cough* - I use it in a lot of my proggies to specify where an error occured
as do some of the exception reporting in core Avalon. It allows us to give
meaningful error messages (ie "Missing attribute foo at myconfig.xml:20").
> The name of the component would be bound to
> the local name in the XML. The last remaining issue is the
> prefix or qName. Because the prefix is not as important as
> the local name or the namespace, a new accessor method can be
> provided called "getExtendedName()". It would work like this:
If we were to go down this path I would possibly prefer something like
getNamespace()
class Namespace
{
String prefix;
String uri;
}
> This does not interfere with the current API, and only provides
> one additional method. What it does allow is the ability to use
> industry standards for configuration (WSDL, WSDD, etc.) and to
> take advantage of dynamic validation of our configuration schemas.
> XML parsers can read the configuration information and validate
> the file based on the various schemas, throwing exceptions when
> the configuration is invalid.
They can still do that at the moment without any support from Configuration
object. So Schema/DTD is good but doesn't madate changes in Configuration
object.
The argument goes that all configuration for a single object will always be
in one namespace. Thus it is up to the container to do validation et al. The
reason I wanted Namespace recorded in Configuration was when we had
hierarchial Configurations. ie Component A contains B which contains C. If
config for A also contains config for B (and then C) then we would namespace
separation.
However as it stands that was identified as a bad pattern because you could
never fully validate C (or B) without initializing A. And considering
initialization of A comes after validation of As configuration we had a
problem.
So what do you think of that ?
> Each persistence mechanism must follow its own rules. However, it is
> conceivable to convert your persisted data into XML which is then able
> to be handled in the expected manner. This reduces the amount of learning
> curve, hides the details of the persistence mechanism, and allows you
> to focus on the task at hand.
Thats what I was planning on doing (when I got around to it). ie DB/LDAP/XML
to SAX, SAX to Configuration object (and vice versa).
> It also allows for new tools to be developed. Tools are used to augment
> the development process, the configuration process, or the deployment
> process. Tools are not used directly in the run-time system--so they
> should not be part of any of our existing projects.
Agreed. As a sidenote has anyone looked at Merlot (opensource XML editor). It
looked good last time I looked at it however it only allowed structure
specified through a DTD (not XSchema). I was wondering if there is any
alternatives out there?
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
