You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/10/31 20:40:22 UTC
XML Parser availablity for Phoenix components.
OK, a Phoenix block requires XML parsing capability. Should it use the
SAX factory, the JAXP replacement for that or is there an IoC ideal that
we should aspire to?
For calls to configure() you don't get a choice, you use the parser that
phoenix is using, but for XML things completely contained inside the
hosted server component, what's right?
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Mircea Toma <mi...@home.com>.
Hi,
> For calls to configure() you don't get a choice, you use the parser that
> phoenix is using, but for XML things completely contained inside the
> hosted server component, what's right?
How about the XMLParser component donated by Cocoon team (check
org.apache.cocoon.components.parser.Parser)?
mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Paul Hammant <Pa...@yahoo.com>.
Actually thinking about this, should it be as follows ?
Service :
org.w3c.dom.DOMImplementation
(as is, no subclassing of component etc).
Block :
Some JDK1.2, 1.3, 1.4 aware solution that get's the class name
from config.xml.
JDK1.4 has build in DOMImplementationImpl etc.
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Paul Hammant <Pa...@yahoo.com>.
Mircea,
>>Of course. And configured as usual in assembly.xml?
>>
>
>Yes, if you create a ParserSelector block! Of course the block configuration
>will contain the parsers' configurations.
>Does it make sense ... or doesn't?!
>
OK, I'm going to create some cornerstone blocks today.
Service :
DOMDocumentFactory {
org.w3c.dom.Document createDOMDocument();
// plus other signatures.
}
Block :
XercesDOMBlock extends AbstractLoggable {
org.w3c.dom.Document createDOMDocument() {
return new org.apache.xerces.dom.DocumentImpl();
}
}
// and other blocks for other DOM parsers meeting the w3c API.
Thoughts? I could just do it and get comments after the first cut...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Mircea Toma <mi...@home.com>.
> Of course. And configured as usual in assembly.xml?
Yes, if you create a ParserSelector block! Of course the block configuration
will contain the parsers' configurations.
Does it make sense ... or doesn't?!
mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Paul Hammant <Pa...@yahoo.com>.
Mircea
>>In true IoC style, the block that needs it would implement an interface
>>like "XMLParsing" and have a method called "registerParser(..)" or
>>something.
>>
>
>Or you can have the XMLParser component registered with the CM. Not every
>block needs a Parser :)
>
Of course. And configured as usual in assembly.xml?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Mircea Toma <mi...@home.com>.
> You guys on about the same thing?
:))
> In true IoC style, the block that needs it would implement an interface
> like "XMLParsing" and have a method called "registerParser(..)" or
> something.
Or you can have the XMLParser component registered with the CM. Not every
block needs a Parser :)
mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XML Parser availablity for Phoenix components.
Posted by Paul Hammant <Pa...@yahoo.com>.
Neeme & Mircea,
You guys on about the same thing?
In true IoC style, the block that needs it would implement an interface
like "XMLParsing" and have a method called "registerParser(..)" or
something. I think the Cocoon component is just a replacement for SAX
in that it has previously had something statically set in it. Rememebr
that Phoenix is a multi app machine that might require several parsers
active in the same VM... Err, or have I got that wrong.
Regards,
- Paul
>I remember Berin mentioned the possibility for future package
>org.apache.avalon.excalibur.xml.parser, that would then contain the "ideal"
>IoC behavioral interface to XML parsing?
>That would allow us to plug in non-SAX- and non-JAXP-compatible parsers as
>well.
>
>>-----Original Message-----
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>Sent: Wednesday, October 31, 2001 11:40 AM
>>To: Avalon Development
>>Subject: XML Parser availablity for Phoenix components.
>>
>>
>>OK, a Phoenix block requires XML parsing capability. Should it use the
>>SAX factory, the JAXP replacement for that or is there an IoC ideal that
>>we should aspire to?
>>For calls to configure() you don't get a choice, you use the parser that
>>phoenix is using, but for XML things completely contained inside the
>>hosted server component, what's right?
>>
>>Regards,
>>
>>- Paul H
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: XML Parser availablity for Phoenix components.
Posted by giacomo <gi...@apache.org>.
On Wed, 31 Oct 2001, Neeme Praks wrote:
>
> I remember Berin mentioned the possibility for future package
> org.apache.avalon.excalibur.xml.parser, that would then contain the "ideal"
> IoC behavioral interface to XML parsing?
> That would allow us to plug in non-SAX- and non-JAXP-compatible parsers as
> well.
And they are ready to be ported from Cocoon.
Giacomo
>
> > -----Original Message-----
> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> > Sent: Wednesday, October 31, 2001 11:40 AM
> > To: Avalon Development
> > Subject: XML Parser availablity for Phoenix components.
> >
> >
> > OK, a Phoenix block requires XML parsing capability. Should it use the
> > SAX factory, the JAXP replacement for that or is there an IoC ideal that
> > we should aspire to?
> > For calls to configure() you don't get a choice, you use the parser that
> > phoenix is using, but for XML things completely contained inside the
> > hosted server component, what's right?
> >
> > Regards,
> >
> > - Paul H
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: XML Parser availablity for Phoenix components.
Posted by Neeme Praks <ne...@one.ee>.
I remember Berin mentioned the possibility for future package
org.apache.avalon.excalibur.xml.parser, that would then contain the "ideal"
IoC behavioral interface to XML parsing?
That would allow us to plug in non-SAX- and non-JAXP-compatible parsers as
well.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Wednesday, October 31, 2001 11:40 AM
> To: Avalon Development
> Subject: XML Parser availablity for Phoenix components.
>
>
> OK, a Phoenix block requires XML parsing capability. Should it use the
> SAX factory, the JAXP replacement for that or is there an IoC ideal that
> we should aspire to?
> For calls to configure() you don't get a choice, you use the parser that
> phoenix is using, but for XML things completely contained inside the
> hosted server component, what's right?
>
> Regards,
>
> - Paul H
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>