On Fri, 21 Sep 2001 22:54, Berin Loritsch wrote:
> > > 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").
>
> Ok.
>
> > > 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;
> > }
>
> Then if we go down that path, I would like to see something like this:
>
> getXMLName()
>
> class XMLName
> {
> String getLocalName();
> String getNamespace();
> String getQualifiedName();
> }
I think I still like Namespace class. The reason is simplicity. ie
getXMLName().getLocalName() == getName()
getXMLName().getNamespace() == getNamespace().getUri()
getXMLName().getQualifiedName() ==
getName() + ":" + getNamespace().getPrefix()
And because all the "namespace" information is in one object (namely
Namespace) that could be shared through-out configuration tree.
> This is true--but the applications that use industry standard
> configurations need to see the namespaces. That does mandate changes.
Could you give some examples. The question is are these inputs
"Configuration" or just plain input data. If they are the second then
wouldn't it be better to use JDom (or dom4j or whatever happens to be your
poison).
> > 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 ?
>
> So your saying if we divide B over C we would come up with the theta of A?
No idea what that means. The last time this conversation came up the only
case where it was determined that namespaces were needed for configuration
was when we contained configuration for a hierarchy of components in same
file.
ie It would be needed for a case like including block + mailet configuration
data in one file (like james does currently). The mailet config needs to be
in different namespace if we want to validate configuration easily. However
we later concluded that it was not possible to validate the mailet
configuration (that was contained in the block configuration) until the block
had been initialized. Because the blocks configuration is validated before
the block is initialized we could not validate the mailet at the same time
(and hence why we needed Namespaces so we could validate that separately).
However we then concluded that the mailet configuration data should not be
included in blocks configuration but in another file and the same for any
hierarchy of components. Thus the need for Namespace for *configuration* data
evaporated.
I think that was how it went ;) - It should all be in mailing list archives
somewhere though.
> WSDL declares information for how to contact a specific SOAP target. As
> such it requires you to embed Schema information as well as other
> information that must be namespaced. Working directly with SAX is
> inconvenient, and DOM is expensive. Both of them do not offer type-safe
> accessors. Hense all the benefits of our Configuration object.
This doesn't sound like configuration data per-se and I may be inclined to
use another solution .. not sure. Could you give an example?
--
Cheers,
Pete
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
