W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

RE: Reusable Hydra components

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 27 Jan 2015 22:53:39 +0100
To: <public-hydra@w3.org>
Message-ID: <01ab01d03a7b$b65449b0$22fcdd10$@gmx.net>
On 27 Jan 2015 at 12:21, Tomasz Pluskiewicz wrote:
> January 27 2015 12:42 AM, "Markus Lanthaler" wrote:
>>> On Monday, January 26, 2015 10:21 AM, Tomasz Pluskiewicz wrote:
>>>> <ld-router>
>>>> <ld-route type="http://schema.org/Person">
>>>> <template>
>>>> <!-- view inline -->
>>>> </template>
>>>> </ld-route>
>>>> <ld-route type="http://schema.org/Book" import="/pages/Book"></ld-route>
>>>> <!-- no [type] attribute could mean a fallback route -->
>>>> <ld-route import="..."></ld-route>
>>>> </ld-router>
>> Yep. This is how you would typically do it in Linked Data Land :-) I
>> wonder if something like "ld-renderer" wouldn't be a better name!? 
> Yes, I don't like the term routing anyway in this context. Renderer is a bit better but not
> ideal IMO. The required word is for a component that decides what view to render based
> on an input. I guess that "render" is a logical idea but I think that "choose" is the predicate
> here. Maybe ld-view-selector? Descriptive...

Another term that comes to my mind is "presenter". "View controller" might also work but is probably a bit confusing in this context.

>>>> Of course one could iterate a processed model and output the <hydra-
>>>> form/>s programmatically for each documented operation but I see great
>>>> value in such declarative way of building the UI from self-contained
>>>> blocks. After all most apps don't expose generic show-all-in-whatever-
>>>> order UIs but rather have carefully crafted design to enhance
>>>> usability.
>> So you are saying that, let's say CommentAction forms would only be
>> shown for issues but not for blog post even though the Web API tells
>> you it supports them for both?
> No, but I'd like to have the option. The problem is that a UI design may position various
> operations available for a resource in different places on the page. In such case simply
> rendering them next to each other could be not perfect.

Oh I see. Perhaps you should also explore the option to make that configuration simply more (linked) data. Basically you would define a simple vocabulary being able to express those things, merge it with the data you get from the API you are interacting with and consume it the same way as that data.

Markus Lanthaler
Received on Tuesday, 27 January 2015 21:54:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 January 2015 21:54:10 UTC