Dhanji,
> If there is a header that is decided dynamically (based on
> some computation) you cant specify it with static metadata. I
> would much prefer the Representation<T> wrapper to forcing
> adding the metadata to the returned entity.
Yes you can. If you annotate your getModificationDate() method with the
@LastModifiedDate annotation, then your method can return a data that
changes dynamically. Same for other metadata.
> I certainly would
> like to have the flexibility to use arbitrary domain objects
> (that may be written by other developers) as my content
> payload and register serializers for them. This is not
> uncommon in large projects.
This is a useful case. I need to think more about how (de-)serialization of
representation POJOs should be supported. But, if you control your resource
POJO, then you can add annotated "serialization" method like:
@Resource
public MyResource {
Foo foo; // the representation domain object to reuse
@Representation("application/foo-xml")
public Document toXML() {
// logic to generate a DOM document
// from the current "foo" instance.
}
@Representation("application/foo-json")
public JSONObject toJSON() {
// logic to generate a JSON object
// from the current "foo" instance.
}
}
> I dont suggest getting rid of the entity-level annotations. I
> agree they are a useful addition and generally like the idea.
> I feel however, that the broader use case calls for external
> (registered) serializers as you call them, for reasons
> mentioned above, and is a good alternative.
> You could capture this with a static binding too:
>
> @Externalizer(MyPojo.class, MyPojoExternalizer.class)
> @URITemplate(...)
> public class RestfulService {
> //..
> }
Isn't the solution proposed above even simpler?
> @Method
> public void post(
> @Input InputStream in,
> @Context("serverInfo.address") String serverAddress,
> @Context("serverInfo.userAgent") String userAgent){
> ...
> }
>
> We would just need to standardize the list of property names.
>
>
> I'd go a step further and make them typesafe enums.
Agreed, that sounds useful.
> > Personally, I don't see the need of either the
> > Representation class or the Entity interface
> > in our JSR API.
> I agree viz. Entity<T>, however as stated above, I believe an
> optional Representation<T> artifact would be an elegant and
> flexible solution to dynamic metadata, especially in cases
> where I cant/dont want to annotate entity classes.
Do you still this so after considering the solution above?
Best regards,
Jerome