Ticket #277 (closed Enhancement: fixed)
add an abstract JSON provider
Reported by: | dgf | Owned by: | |
---|---|---|---|
Priority: | Minor | Milestone: | |
Component: | DeepaMehta Standard Distribution | Version: | 4.0.11 |
Keywords: | Cc: | ||
Complexity: | 1 | Area: | Application Framework / API |
Module: | deepamehta-webservice |
Description
the actual implementation of a provider looks very technical and should be abstracted.
a class like the following would be charming:
package de.deepamehta.plugins.example.provider; import javax.ws.rs.ext.Provider; import org.codehaus.jettison.json.JSONObject; import de.deepamehta.plugins.example.AbstractProvider; import de.deepamehta.plugins.example.Example; @Provider public class ExampleProvider extends AbstractProvider<Example> { public ExampleProvider() { super(Example.class); } @Override protected JSONObject getJsonData(Example example) { return example.toJSON(); } }
Attachments
Change History
Changed 13 years ago by dgf
- Attachment AbstractProvider.java added
comment:1 Changed 13 years ago by jri
The Webservice module already provides generic JSON providers for writing (JSONEnabledProvider and JSONEnabledCollectionProvider). These are available to all modules automatically. Your domain object just needs to implement de.deepamehta.core.JSONEnabled. This makes it ready to be send over the wire.
comment:2 Changed 13 years ago by dgf
In the example plugin project i want to show a simple implementation of specific provider.
I couldn't find a usage of the JSONEnabled interface, but some similar implementations. All provider that enhance the core classes should swallow an abstraction:
- AssociationProvider
- AssociationTypeProvider
- CommandResultProvider
- DirectivesProvider
- StringSetProvider
- TopicTypeProvider
comment:3 Changed 13 years ago by dgf
i just looked down from web service module, now i found the general usage at DeepaMehtaObject
comment:4 Changed 13 years ago by jri
Yes, the JSONEnabled feature is not yet exploited by all provider implementations. JSONEnabled was introduced later. TopicProvider? as an example is already adapted: it is just a reader. AssociationProvider? on the other hand is not yet adapted: it is still a reader and a writer, in which the writer part is obsolete.
There is no need for proprietary message body writer providers as long as the object implements JSONEnabled. Every object that is about to be send over the wire is supposed to do so.
(A generic reader provider of course is a different story and does not yet exist).
I will cleanup the provider implementations soon.
In fact all the Core objects are JSONEnabled. Derived from the very top of the hierarchies:
de.deepamehta.core.DeepaMehtaObject?
de.deepamehta.core.model.DeepaMehtaObjectModel?
For an external module example which makes use of JSONEnabled see Geomaps.
Its model classes (Geomap, GeomapTopic?) are JSONEnabled. (GeomapTopic? derives JSONEnabled from TopicModel?.) So, Geomaps doesn't need to provide any custom providers to be send over the wire. A Geomap consist of GeomapTopics? and is returned by the getGeomap() service call (= resource method). See GeomapsService? and GeomapsPlugin?.
So, for your example plugin project there should be no need to provide a writer provider. Just implement JSONEnabled.
comment:6 Changed 13 years ago by dgf
The plugin dev guide should not show such internal stuff, it uses the attached reader suggestion now.
comment:7 Changed 13 years ago by jri
Sorry, misunderstanding.
The diagram was not meant for the dev guide, just for your pleasure :)
comment:8 Changed 12 years ago by jri
- Status changed from new to closed
- Resolution set to fixed
The Webservice module now offers a generic MessageBodyReader? Provider for JSON reprensented entities (#277).
This means the application developer must no longer implement a custom provider class when she wants to deserialze an arbitrary JSON represented application object contained in the message body. She only must ensure the application object's class has a public constructor that takes a JSONObject as argument.
In other words: in your (REST) resource methods you can use an arbitrary class as the type of the entity parameter as long as the entity is represented in JSON and the class has a public JSON constructor. You are no longer required to implement a provider class.
Furthermore: the webservice's provider classes are generalized by exploting the fact that most DM core application objects implements the JSONEnabled interface. 6 provider classes are stripped from the webservice module (#278).
BREAKING CHANGES
- relatedTopicsToJson() deleted
See ticket 277.
See ticket 278.
Changeset: ea5ca8535f796a5ec083b68ef49fdae570470ded
a strate forwoard implementation approach