On Jul 9, 2011, at 3:59 AM, Markus KARG wrote:
>
> @Ref.condition -- Interesting idea, but the question is, whether there will be any other conditions besides "is null"? If not, we can omit that, since null will not get rendered by a JAXB marshaller anyways.
>
> This condition can be used even if there's no reference, e.g., in a Link header declaration. If we force developers to use URI variables, regardless of whether these are rendered inline or as link headers, then we should revisit this. A suitable default could be defined too.
>
> Markus> I didn't get the point. What shall a condition be good for if there is no reference? And what shall a Link header be good for if there is no reference? Both, <a href> and Link: are purely means of transport for references.
I overloaded the term "reference" too much. See the last example in the wiki, in which ItemRepresentation does not have a "next" and a "prev" and conditions are still use for rendering those links. In this case, you cannot check if "next" or "prev" are null since they are not there. Is that what you meant by "is null"?
>
>
> @Binding -- I would prefer not using String syntax here, too, due to the same reasons.
>
> You mean EL expressions? EL expressions are used in many other places in the EE world.
>
> Markus> Yes, but that doesn justify using a String based API in a place where a compile time check could be made instead. Java EE introduced it mainly for places where a compile time check is not possible, like in JSPs (as one can create the references dynamically at runtime there). We should not turn Java EE into a scripting environment, unless we have a good need for it. Scripting might be nice for projects where one needs to go live sooner than later. But our customers instead expect to get high speed and stability. The latter is better served using compiled syntax.
What is the alternative to EL expressions that you're proposing?
> @Link -- Actually this looks scary. If I want to make the JAXB marshaller render LINK headers instead of XML URLs, it should be sufficient to configure that in one line instead of that huge code block. Something like a boolean parameter set at the marshaller or like that. I do not think that it should be part of the representation class itself, but more a general rendering configuration.
>
> Yes, I tend to agree. You're suggestion is to always use URI (or Link ;) variables in the representation and declare the type of rendering desired externally. Correct?
>
> Markus> No, I am neither using URI or Link in the representation but the original referenced class. If we are referencing an Apple, the reference will be using class Apple. This is just natural for Java programmers. Our current application is using that (using JAXB adapters replacing Apple by URI and vice versa on the fly). Currently we always replace by URL at marshalling, but it would be rather simple for us to replace by virtually anything (like Link). For us, there is clear separation between the data model (JAXB class) and the transported document (rendered representation). The data model is an Apple always. But the transferred representation is either rendered using an "Link Header Renderer" or an "XML URI Renderer". Again, this works pretty simple with JAXB, but it might get complex for custom MessageBodyWriters. But, it is the most natural for Java, and so we should try to do that.
In the example that I showed, there's a model class and a representation class. @Ref and @Link apply to the latter. What you're suggesting is that the latter does not need to be defined, but should be inferred? I think that there are use cases in which the representation (i.e., view) is a subset of the model, and just working on the model directly may render more data than what is needed. Perhaps both styles should be supported ...
-- Santiago
>
> From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Mittwoch, 6. Juli 2011 21:09
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia Proposals
>
> Hi All,
>
> I've updated the wiki [1] to describe the type of declarative hyperlinking supported in Jersey using @Ref and @Link. Declarative hyperlinking in Jersey supports both links in representations and link headers.
>
> Hyperlinking is a first step, but HATEOAS is more than that. I've also added some links to related work towards the end of the page. Please feel free to include other links there.
>
> Guilherme: I came across [2]. Is this the latest on your research in this area?
>
> -- Santiago
>
> [1] http://java.net/projects/jax-rs-spec/pages/Hypermedia
> [2] https://github.com/caelum/restfulie-java/wiki/java_hypermedia
>
> On Jul 5, 2011, at 12:47 PM, Guilherme Silveira wrote:
>
>
>
> Cant we support link headers? Would already incentivate people doing rest... Even if limited to links.
>
> Cant we also incentivate response based links and forms as in
>
> Response.getLinksFor(myEntity)
>
> An http api withou hypermedia is, in the best case, an http api - not a rest one.
>
> Regards
>
> Guilherme Silveira
>
>
> 2011. 7. 5. 오후 12:40에 "Bill Burke" <bburke_at_redhat.com>님이 작성:
>
> Hypermedia is entity body driven, so, other than Link header support, I don't see what we can be done in regards to a specification. XML/JAXB is the only standardized media type JCP has dealt with and I'm very doubtful meaningful integration can be done with it considering JAXB's limitations.
>
>
> On 7/1/11 1:47 PM, Santiago Pericas-Geertsen wrote:
> >
> > Hello Experts,
> >
> > Even though we are stil...
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>