On 07/16/2011 08:32 PM, Markus KARG wrote:
>> On 07/07/2011 06:59 PM, 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.
>>
>>
>> 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?
>
>>> 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].
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.