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
