Re: Reusable Hydra components

Hi Tom,

I've been working on similar themes with the AngularJS client [1].

Here's some links to GitHub which highlight some of the things you
mentioned above.

I've used routing to have separate views for Forms, Collections and 'normal
views'. These seem to be the three main view types in a Hydra client
(judging by Marcus's implementation):
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L378-403

There are directives for each of the different views:

Form directive:
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1990-2044
Screenshot:
https://www.dropbox.com/s/xrhtguax980am52/du_dash_add_cell_contents_map_fields.png?dl=0
(note I'm using OSLC to populate drop down values)

Collection directive:
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1817-1836
Sreenshot:
https://www.dropbox.com/s/wh4xfi2dlq7sbgd/du_datatables_list.png?dl=0

Item directive:
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1732-1742

The directive 'duItem' represents a SupportedProperty (a 'pageItem' is a
wrapper around a SupportedProperty with a bit of extra information to make
it easier to display - I should improve the naming):
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1581-1629

The SupportedOperation directive is here:
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1653-1674

I've got a couple of extensions in my client, over and above the standard.
These don't stop it functioning like a normal Hydra client, but help the
client look and behave like a standard web app. CSS styling can be applied
to SupportedProperties, so the EntryPoint for my app looks like this (CSS
is applied to the SupportedOperations to make them look like buttons):

https://www.dropbox.com/s/lf1iqyycefbcp9x/du_home.png?dl=0

There is also an option to add custom routes. In my application there's a
couple of screens which really need a very tailored user experience which
involve a lot of javascript interaction (I make data visualisation
software). The easiest way I've found of including them is to have a
Provider which lets you insert new Routes into the Hydra client (by
specifying a SupportedClass/SupportedOperation combination):

https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L5-266

I've supported supplying drop down value choices through OSLC. I chose OSLC
from the current Hydra Shapes options because it was easy to understand and
implement (drop downs are visible in the Form screenshot above):
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L1931-1983
https://github.com/dataunity/dataunity-hydra-client/blob/master/js/dataunity-hydraclient-0.1.0.js#L2415-2435

I haven't done a very good job of sharing my work with the group yet (sorry
guys). The main issues are intense workload, and the fact that I can't Open
Source my Hydra API just yet (I need to improve some security options).
However I hope some of the screenshots above show that Hydra can be used to
create a familiar web experience for the user.

Thanks,

Kev

PS: there's more features to the AngularJS Hydra client, like allowing
parallel routes through an API, but I think I've already put too much info
into this email so I'll save it for future discussions.

[1] https://github.com/dataunity/dataunity-hydra-client

On 26 January 2015 at 09:21, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:

> Hi Cedric, Hi everyone
>
> I'm currently reiterating my ideas for consuming Hydra APIs. Most
> discussions here seem to revolve around building generic clients. However
> this is not how most web apps are built, nor will they be in the nearest
> future. There was also some discussion about implementing a client in
> AngularJs, though I don't think that we should depend on any such
> general-purpose framework.
>
> Lately I've been experimenting with web components, the upcoming HTML5 set
> of features and it seems to fit nice. Currently only Chrome and Opera
> support that natively but other modern browsers can be polyfilled
> successfully. Native support is just a matter of time anyway.
>
> And so there is that custom component called app-router [1]. It works by
> defining in a declarative way what UI should render when a particular route
> is matched.
>
> <app-router>
>   <!-- matches static route and template inlined -->
>    <app-route path="/example">
>     <template>
>     <p>Inline template FTW!</p>
>   </template>
>   </app-route>
>     <!-- matches a pattern like '/word/number' and template lazy-loaded -->
>     <app-route path="/^\/\w+\/\d+$/i" regex
> import="/pages/regex-page.html"></app-route>
> </app-router>
>
> I find this very clean. Unfortunately path-based routing is irrelevant for
> REST state transitions, where the returned model determines the UI state.
> I've looked around AngularJs and generally and surprisingly I've found
> little about building such browser apps. Thus I've successfully
> experimented with adapting the <app-router /> so that resource @type is
> used to choose the UI:
>
> <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>
>
> Currently I've adopted the flux pattern [2] implementation Reflux [3] to
> decouple the UI from the actual content navigation by using events. This
> way there can be multiple <ld-router />s on a page all independently
> reacting to model changes.
>
> As far as Hydra is concerned I envision similar reusable components for
> rendering links and operation forms based on the model and
> ApiDocumentation. For example a form-element could be as simple as
>
> <hydra-form operation="http://example.com/Api#SubmitIssue"></hydra-form>
>
> 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.
>
> @Cedric, have you actually started working on your AngularJs API? Or maybe
> you would be interested in my proposed approach?
>
> @All, what do you think about the above ideas?
>
> Thanks,
> Tom
>
> [1]: https://github.com/erikringsmuth/app-router
> [2]: https://github.com/facebook/flux
> [3]: https://github.com/spoike/refluxjs
>



-- 
www.dataunity.org
twitter: @data_unity