Re: Relationship between filter properties and hydra:supportedProperty (was Re: Filters as views (ISSUE-45))

Hi Tom, Maxim

Regarding Maxim's ideas, I've got few mor concerns.

The comparator itself may be not very precise - I think Tom already throw 
few more examples, i.e. for strings it can be "equals", but it may also be 
"startsWith", "endsWith", "matches", etc. W may end up with quite a 
dictionary here.

>Generally I see that most people associate views with collections.
>After all there are still templated links though views can also express a 
>hierarchy of resources.
>Consider a resource, which is essentially a long text document (an article 
>etc).
>Say I wanted to define a view, which generates an automated summary and 
>takes maximum length parameter:
>...
>What sense do the other properties of mapping make?
>Neither property nor comparator seems right in such context.
>I feel like we are pushing the design of template mappings for views (and 
>by extension templated links) in a very specialized direction without fully 
>analyzing a bigger picture.
I believe few more situations like this could be imagined. I.e. sorting 
doesn't require a comparator (but it needs a mapping though).

As for multiple mapping - we're entering a swampy turf here - how client is 
supposed to concatenate these multiple properties? While indeed it might be 
useful (as I'm also seeking for a way of telling the client how to build 
i.e. a display name from various properties), but this poses quite a 
challange on it's own.

Best

Karol 

Received on Sunday, 14 February 2016 21:02:19 UTC