Thanks for the feedback. After 1.0 finally goes out I want to revisit the server code as I
think we managed to over complicate things after our last major refactoring. - james
------Original Message------
From: Neale Upstone
To: user@abdera.apache.org
ReplyTo: user@abdera.apache.org
Subject: MediaCollectionAdapter shouldn't extend CollectionAdapter (methinks)
Sent: May 19, 2009 5:14 AM
Hi James and others,
I'm currently designing an application for which I've chosen APP as the
protocol and I'm looking to use Abdera for the server nuts and bolts.
The scenario that I have is that I want to provide independent
CollectionAdapters for entries and media, and use the RouteManager to
select between them.
For example, my RouteManager will be configured as:
routeManager = new RouteManager()
.addRoute("feed", ":collection", TargetType.TYPE_COLLECTION,
entriesAdapter )
.addRoute("entries", ":collection/:entry",
TargetType.TYPE_ENTRY, entriesAdapter)
.addRoute("media", ":collection/:entry/:version/",
TargetType.TYPE_MEDIA, mediaAdapter);
I have two challenges with the current (almost-1.0) release:
1) I don't see why I should need to implement the non-media methods on
my mediaAdapter. I believe that CollectionAdapter and
MediaCollectionAdapter should not be in the heirarchy that they are. I
suggest that MediaCollectionAdapter should just represent the
responsibilities of dealing with media.
Note: It already looks like this is assumed to be the case in the code,
e.g.:
public abstract class AbstractCollectionAdapter implements
CollectionAdapter, MediaCollectionAdapter, ...
2) The ManagedProvider class (and hence BasicProvider) assumes that
there is only one CollectionAdapter, and therefore leaves us having to
cook our own Managed-style implementation for my scenario.
Simply put, both of the above cause complexity in not allowing
separation of concerns. I'd much rather see a simple out of the box
configuration where a BasicProvider can be supplemented with a
MediaCollectionAdapter.
I think a good measure for the community would be that we should be able
to mix and match different CollectionAdapter and MediaCollectionAdapter
implementations. e.g. we may want to store entries in a database, and
media to disk.
Cheers,
Neale
--
Neale Upstone
neale@nealeupstone.com
Sent from my Verizon Wireless BlackBerry