You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2006/10/28 01:01:30 UTC
Abdera configuration
The current Abdera configuration model is designed around the notion of
being able to configure alternative default implementations in a way
that is transparent to consuming applications. However, since we only
have one implementation of the interfaces as it's just as easy just to
do Parser parser = new MyOtherParser(), I'm strongly leaning towards
backing this stuff out and simplifying the configuration model. Using
alternative Parser implementations would no longer require a
configuration step. Implementations would just new up the alternative
Parser.
Thoughts?
- James
Re: Abdera configuration
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/30/06, James M Snell <ja...@gmail.com> wrote:
> What I imagine is a discovery model generally similar to JAXP. It's not
> a big change over what we currently have.
>
> Parser parser = abdera.getParser();
As long as there is a way to get ahold of the default parser without
hardcoding its class name into the code then having to be explicit
about the class name when using alternate parsers seems fine with me.
I really don't think alternate parsers is going to be a common use
case anyway.
-garrett
Re: Abdera configuration
Posted by James M Snell <ja...@gmail.com>.
What I imagine is a discovery model generally similar to JAXP. It's not
a big change over what we currently have.
Parser parser = abdera.getParser();
- James
Garrett Rooney wrote:
> On 10/27/06, James M Snell <ja...@gmail.com> wrote:
>> The current Abdera configuration model is designed around the notion of
>> being able to configure alternative default implementations in a way
>> that is transparent to consuming applications. However, since we only
>> have one implementation of the interfaces as it's just as easy just to
>> do Parser parser = new MyOtherParser(), I'm strongly leaning towards
>> backing this stuff out and simplifying the configuration model. Using
>> alternative Parser implementations would no longer require a
>> configuration step. Implementations would just new up the alternative
>> Parser.
>
> If we went this way would there still be the concept of a default
> parser back end, or would we be having people hardcode
> org.apache.abdera.parser.stax.* into their code since that's our only
> current implementation?
>
> -garrett
>
Re: Abdera configuration
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/27/06, James M Snell <ja...@gmail.com> wrote:
> The current Abdera configuration model is designed around the notion of
> being able to configure alternative default implementations in a way
> that is transparent to consuming applications. However, since we only
> have one implementation of the interfaces as it's just as easy just to
> do Parser parser = new MyOtherParser(), I'm strongly leaning towards
> backing this stuff out and simplifying the configuration model. Using
> alternative Parser implementations would no longer require a
> configuration step. Implementations would just new up the alternative
> Parser.
If we went this way would there still be the concept of a default
parser back end, or would we be having people hardcode
org.apache.abdera.parser.stax.* into their code since that's our only
current implementation?
-garrett