> >>> @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.
> >> Think about conditions that control generation & attachment of links
> >> based on e.g. user security roles, state of the
> >> resource etc.
> > I do not see that his is part of the HATEOS topic, but simply the job
> of the application layer. Hence, we have no need to provide special
> support for that under the umbrella of Hypermedia support.
> If controlling the link attachment based on the request content and/or
> resource state is not part of the HATEOAS topic,
> then what is?
You misunderstood me. Generel control of business workflow is not part of HATEOAS but is part of the general topic of application logic. So I do not see a special need to support that under the HATEOAS umbrelly. If the business workflow says "that link exists only under this or that condition" that is a business rule. HATEOAS is not about business rules. It is how to render the results of that rules. So a simple "if (x)" completely fulfiles this. There is only one single thing that our HATEOAS support must provide: if the link is null (since the business rule decided to set it null due to any arbitraty condition programmed in plain Java) THEN it must omit that in the resulting XML (as null is the default in JAXB already).
We do not provide support for business rules. We provide support for Hypermedia. These are two different levels and we should not mix them.
> >>> If there are more conditions, I
> >>> would be more happy with a Java API than a String based syntax. In
> >> our application we solved this by the general
> >>> invention of a "Constraint" interface (which is not HATEOAS
> >> dependend, but more general like java.lang or java.util
> >>> things are). This would not only run faster, but also allows to
> >> syntax-check for typos (which always is hard to find).
> >> Personally, I find EL as a language for conditions practical.
> > Personally, I hate string based languages, as they are hell to debug.
> I understand that, but this is about short expressions meant to return
> true/false. It's not about writing complex
> scripts. In that context the EL seems instant, effective and practical,
> compared to forcing a user to non-anonymously
> implement an interface and then bind the implementation class to the
> annotation. Too little bang for the buck, if you
> ask me[1].
This is a question of the view: @Resource provided string based APIs and was replaced by @Inject with the "benefit" of no more strings but compiler-checkable references. This is the exact same topic. We should not do a step back and now again propose string based APIs.
>
> Marek
>
> [1] Surely, once the closures find their way to Java, we should
> consider updating the API to support them.
> Alternatively, we could consider supporting both (EL & Interface)
> approaches right now.
My suggestion would be: Do not provide String based APIs, but just use Java based APIs until Closures are here.