xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Vasilik" <eric...@bea.com>
Subject RE: Design Questions
Date Wed, 03 Dec 2003 19:09:40 GMT
We originally had something like the following:

    class XmlLoader
    {
        static XmlObject parse ( File f ) { ... }
    }

The, to get a MyDocument, you would do:

    MyDocument myDoc = (MyDocument) XmlLoader.parse( ... );

If the XML to be parsed was not of the correct type (i.e. it did not have the correct document
element which made it a MyDocument), XmlLoader.parse would still parse this XML, but it would
not create a MyDocument, and the cast above would fail and a ClassCastException would be thrown.
 However, with the current design:

    interface MyDocument implements XmlObject ...
    {
        static final class Factory
        {
            static MyDocument parse ( File f ) { ... }
        }
    }

One would say:

    MyDocument myDoc = MyDocument.Factory.parse( ... );

First, this is easier to read because there is no cast.  Also, because we generate a specific
function to create MyDocuments, if the incoming XML does not conform to the MyDocument schema,
instead of getting a CLassCastException, we can perform a test and throw a nicer exception
describing what was found and what was expected.

The reason we make a nested static class is because interfaces cannot have non virtual methods.

Also, because we interfaces and not a hierarchy of classes, an object hierarchy approach will
not work.

Hope this makes sense!

- Eric

-----Original Message-----
From: jas [mailto:jsleeman@lig.net]
Sent: Wednesday, December 03, 2003 7:27 AM
To: xmlbeans-dev@xml.apache.org
Subject: Re: Design Questions


Ok, I did some searching in the archive and didn't see an answer to a
question I had on v1.  I've been looking at this software for the past 2
weeks for particular patterns used.  One question I have is - why was the
approach of using an internal final static factory inside of each xml type
interface used?  It certainly is clever but I am wondering why there was
not a typical object hierarchy strategy used?  I didn't think one could
override final members but I wrote test code mimicking this approach and
proved it to myself.  I assume because it is done inside of an interface
that it is not a problem.

Thanks,
jas




>> I am doing pattern research on xmlbeans and I was wondering if this is
>> the
>> most appropriate place to post my questions in regards to why certain
>> approaches were used.
>
> yep :)
>
> just FYI: the mailing list archive's pretty thin on v1 - since v2 is in
> the process of development and v1 was created outside apache - but IIRC
> there's some stuff on the wiki and on the website.
>
> - robert
>
>
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/


Mime
View raw message