RE: Re[2]: Moving XMLC to ObjectWeb's SF

Hi Richard,

Barracuda includes its own copy of the XMLC io package
(org.enhydra.barracuda.core.util.dom.io). We did this waaaaay back because
Barracuda needed to extend the default rendering mechanism very slightly -
basically, we need the ability to flag a node as "not visible" and have the
renderer skip it. If you check out the latest Barracuda from cvs
(http://barracudamvc.org/Barracuda/docs/cvs.html), and search the above
package for "//csc" you will see everything that we touched there; even
though there are only a couple of classes that actually got modified, I
think we had to port the whole package because of variable protection
issues.

> One of these workarounds could be to use XMLC API rather than
> Xerces to access the document...Of course, this would tie
> Barracuda to XMLC

That would be bad. At this point, the only implementation specific classes
that I see used in Barracuda are those in org.apache.* (see attached doc).
Most of these are simply references to the parser. The only significant ones
that I see are in the IO package:

\src\org\enhydra\barracuda\core\util\dom\io\DOMParser.java:81:      class
XercesParser extends org.apache.xerces.parsers.DOMParser {

\src\org\enhydra\barracuda\core\util\dom\io\DOMParser.java:252:
? documentClassName :
org.apache.xerces.parsers.DOMParser.DEFAULT_DOCUMENT_CLASS_NAME;

\src\org\enhydra\barracuda\core\util\dom\io\XMLEntityResolver.java:33:
import org.apache.xerces.readers.XCatalog;

\src\org\enhydra\barracuda\core\util\dom\io\XMLEntityResolver.java:49:   *
@see org.apache.xerces.readers.XCatalog

As mentioned above, this package could be eliminated entirely from
Barracuda, provided the changes described above (node visibility) could be
rolled back into XMLC.

Christian
----------------------------------------------
Christian Cryder [christianc@xxxxxxxxxxxxxx]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: xmlc-admin@xxxxxxxxxxx [mailto:xmlc-admin@xxxxxxxxxxx]On Behalf Of
> Richard Kunze
> Sent: Tuesday, January 28, 2003 2:55 AM
> To: xmlc@xxxxxxxxxxx
> Subject: Re: Re[2]: Xmlc: Moving XMLC to ObjectWeb's SF
>
>
> Hi Jake,
>
> On Monday 27 January 2003 19:14, Jacob Kjome wrote:
> > Hello Richard,
> >
> > Barracuda includes some classes that were meant to, eventually, be
> > moved to the XMLC package.  This hasn't really happened yet.
>
> Hmmm. Which packages, and what do they do?
>
> > We access Xerces implementation packages for much the same
> reason as XMLC
> > does; because it needs more access to the DOM than the interfaces
> > provide.  Of course, there may be ways to workaround this.
>
> One of these workarounds could be to use XMLC API rather than
> Xerces to access
> the document - I guess the information needed is much the same in
> both cases
> (extended structure and metadata). Of course, this would tie Barracuda to
> XMLC, but I think that's no worse than being tied to a specific Xerces
> implementation.
>
> > The way we should move forward is to figure out what packages use
> > Xerces implementation classes directly, then figure out which of those
> > really *need* to access those package rather than the standard
> > interfaces.  Whatever is left over should probably either be moved to
> > XMLC, or we should figure out if there are already classes in XMLC
> > that provide the needed functionality.
> >
> > Barracuda definitely shouldn't need direct access to XML or DOM
> > implementation classes.
>
> Agreed.
>
> Best regards,
>
> Richard
>
> --
> Richard Kunze
>
> [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
> http://www.tivano.de, kunze@xxxxxxxxx
>
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc

org.apache.txt
Description: Text document