You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/11/15 13:45:48 UTC
[Proposal]: Extending Parser Interface
Hi,
what do you think of extending the
org.apache.excalibur.xml.sax.Parser interface by
adding a parse() method:
void parse( InputSource in,
ContentHandler contentHandler,
LexicalHandler lexicalHandler,
Parameters parameters )
throws SAXException, IOException;
With this method you can influence the parsing, e.g.
turn on/off validation for this parse cycle etc.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal]: Extending Parser Interface
Posted by Mircea Toma <mi...@apache.org>.
On Thursday 21 November 2002 07:39, Carsten Ziegeler wrote:
> > Is it the application that needs all these parsers or one
> > component/service?
>
> Actually both :) - There are areas of your application where you
> know that you for example should not validate - or even better,
> it's configurable by the user. Imagine a desktop application,
> like an XML editor where you can say validate or not for
> applying a stylesheet (something like this). Internally you
> use avalon and the parser component and have to get a component
> with the correct behaviour.
Actually, validation is a different concern so a Validator service would be
required here. ;)
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal]: Extending Parser Interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Mircea Toma wrote:
>
> > Mircea Toma wrote:
> > >
> > > I wouldn't do that. By passing parameters to configure a
> > > Component you break
> > > SoC pattern. I would just have different parsers configured with
> different
> > > parameters and select them using the CS or CM.
> > >
> > Hmm, I agree partially with you here. Now, I think configuring
> a component
> > will all different configuration sets is not the right approach:
> > You end up having a "validating parser", a "non-validation parser",
> > a "validation and xyz parser", a "validation and not xyz parser" etc.
> > And your application really needs all those four.
>
> Is it the application that needs all these parsers or one
> component/service?
>
Actually both :) - There are areas of your application where you
know that you for example should not validate - or even better,
it's configurable by the user. Imagine a desktop application,
like an XML editor where you can say validate or not for
applying a stylesheet (something like this). Internally you
use avalon and the parser component and have to get a component
with the correct behaviour.
> >
> > So, in the end you need for each component that you can use in
> > different situations a ComponentSelector.
> >
>
>
> Phoenix has this ability of providing different component
> implementations to
> different components without using a selector. I guess this would
> solve your
> problem conceptually but if you have to use ECM than I agree using a
> selector for parsers is not very nice.
>
Yes, that's right - As a better solution than selectors will be in
the next implementations anyway, this problem will also disappear.
Thanks
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal]: Extending Parser Interface
Posted by Mircea Toma <mi...@apache.org>.
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 17, 2002 11:49 PM
Subject: RE: [Proposal]: Extending Parser Interface
> Mircea Toma wrote:
> >
> > I wouldn't do that. By passing parameters to configure a
> > Component you break
> > SoC pattern. I would just have different parsers configured with
different
> > parameters and select them using the CS or CM.
> >
> Hmm, I agree partially with you here. Now, I think configuring a component
> will all different configuration sets is not the right approach:
> You end up having a "validating parser", a "non-validation parser",
> a "validation and xyz parser", a "validation and not xyz parser" etc.
> And your application really needs all those four.
Is it the application that needs all these parsers or one component/service?
>
> So, in the end you need for each component that you can use in
> different situations a ComponentSelector.
>
Phoenix has this ability of providing different component implementations to
different components without using a selector. I guess this would solve your
problem conceptually but if you have to use ECM than I agree using a
selector for parsers is not very nice.
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal]: Extending Parser Interface
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Mircea Toma wrote:
>
> I wouldn't do that. By passing parameters to configure a
> Component you break
> SoC pattern. I would just have different parsers configured with different
> parameters and select them using the CS or CM.
>
Hmm, I agree partially with you here. Now, I think configuring a component
will all different configuration sets is not the right approach:
You end up having a "validating parser", a "non-validation parser",
a "validation and xyz parser", a "validation and not xyz parser" etc.
And your application really needs all those four.
So, in the end you need for each component that you can use in
different situations a ComponentSelector.
Hmm, I have to think about this.
Thanks for your reply,
Carsten
> >
> > what do you think of extending the
> > org.apache.excalibur.xml.sax.Parser interface by
> > adding a parse() method:
> >
> > void parse( InputSource in,
> > ContentHandler contentHandler,
> > LexicalHandler lexicalHandler,
> > Parameters parameters )
> > throws SAXException, IOException;
> >
> > With this method you can influence the parsing, e.g.
> > turn on/off validation for this parse cycle etc.
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal]: Extending Parser Interface
Posted by Mircea Toma <mi...@apache.org>.
Hi Carsten,
I wouldn't do that. By passing parameters to configure a Component you break
SoC pattern. I would just have different parsers configured with different
parameters and select them using the CS or CM.
Mircea
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Friday, November 15, 2002 5:45 AM
Subject: [Proposal]: Extending Parser Interface
> Hi,
>
> what do you think of extending the
> org.apache.excalibur.xml.sax.Parser interface by
> adding a parse() method:
>
> void parse( InputSource in,
> ContentHandler contentHandler,
> LexicalHandler lexicalHandler,
> Parameters parameters )
> throws SAXException, IOException;
>
> With this method you can influence the parsing, e.g.
> turn on/off validation for this parse cycle etc.
>
> Carsten
>
> --
> 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>