abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: adding json rest handling to AbstractCollectionAdapter
Date Tue, 15 Apr 2008 17:00:20 GMT
Sorry for getting back to this so late. Comments below...

David Primmer wrote:
> I'm looking for a way to split off processing in the collection
> adapter into json input and output processing (without going through a
> translation into the FOM). The two areas I'm looking at are
> AbstractCollectionAdapter and AbstractEntityCollectionAdapter. The
> reality of my implementation is that the json objects in the request
> body are basically the same as the pojo's that are the storage
> interface, so why go through the abstraction of the FOM?

There are several ways to handle this.  In one of my implementations, 
I've created a custom ResponseContext that uses the JSON writer to 
serialize output directly from the source objects.  No FOM necessary.

> I'm trying to add json to backend java objects to the request/response
> processing pipeline of Abdera but do I need to change abdera to do it?
> I've noticed there are separate processing systems for media handling
> and xml handling. The various build* methods, like
> AbstractCollectionAdapter.buildCreateEntryResponse, that creates
> ResponseContext for the entry object and sets up the common
> http-oriented elements of the response. Seems re-usable for a generic
> json REST server. Seems like I could extend the
> AbstractCollectionAdapter.
> Is it true that to keep this simpler, I'd want to keep the Feed and
> Entry interfaces? So a json 'entry' or a json 'feed' could be used
> with stuff like getEntryFromRequest. But not use any of the RFC4287
> stuff in the Source class? getEntryFromRequest retrieves the Entry
> object from the request payload. It creates a parser object which
> could be replaced with a json parser.

There shouldn't be any need at all for implementing the Feed and Entry 
interfaces.  Just go directly from your application objects to JSON 
using a custom ResponseContext implementation.

> What about using some of the stuff in AbstractEntityCollectionAdapter?
> It seems very tied to XML. Would ProvidorHelper.isValidEntry need to
> be extended to support json also? Is this just a very slippery slope
> that is not worth getting on?

I think it would be easier to either extend AbstractCollectionAdapter or 
just implement CollectionAdapter directly. 
AbstractEntityCollectionAdapter seems a bit too specific for your case.

- James

> thanks!
> davep

View raw message