abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Primmer" <david.prim...@gmail.com>
Subject Re: Refactoring AbstractProvider to make it open for extension
Date Fri, 04 Jul 2008 21:07:52 GMT
On Fri, Jul 4, 2008 at 1:51 PM, Sergio Bossa <sergio.bossa@gmail.com> wrote:
> On Fri, Jul 4, 2008 at 8:53 PM, David Primmer <david.primmer@gmail.com> wrote:
>> I'm not sure what things you want to do with the request processing
>> that force you to replace the 'if' statements that you mention.
>> [CUT]
> AbstractProvider uses "if" statements in order to decide what to do
> depending on the TargetType: this prevents you to extend provider
> features for supporting new target types, i.e. Open Search documents.
> I know you can support OpenSearch (or whatever else) with filters,
> resolvers, and alike, but I think it would be wrong: if it's the
> provider job to decide what to do depending on the TargetType, you
> shouldn't give this same responsibility to other classes.

Ah, I see what you mean. I guess I just never thought of this as a new
TargetType, but rather a new adapter. For example, I recently wanted
to add Json processing and avoid using the FOM, so I thought a
JSONCollection TargetType might work. But then I realized that I could
just re-use collection TargeType and make a JSON CollectionAdapter.
Having more easily extensible TargetType system would make abdera more
general purpose. I suppose it's useful for doing things that aren't
exactly resource oriented, like processing a call for a service doc.
Shindig could extend TargetType to include processing our Discovery
Doc which is a more dynamic Service Doc.


> Obviously IMHO.
> Cheers,
> Sergio B.
> --
> Sergio Bossa
> Software Passionate, Java Technologies Specialist and Open Source Enthusiast.
> Blog : http://sbtourist.blogspot.com
> Sourcesense - making sense of Open Source : http://www.sourcesense.com
> Pro-netics s.p.a. : http://www.pronetics.it

View raw message