RE: Enquiry

On Monday, October 27, 2014 6:55 PM, Matthew Slater wrote:
>> I'm more than happy to help with this, so feel free to post
>> questions and share your progress on the mailing list.
> 
> Thanks! Maybe we should take this thread off-list then.

Let's keep the discussion here for the time being.


> On 27 October 2014 15:08, Markus Lanthaler wrote:
>> Have you looked at
>> 
>>   http://decoupledcms.org/links.html
> 
> Ah I see.
> My current skills are only php/Drupal
> There's a gap between that and what these tools are doing.

OK


>> > Drupal's services module exposes entities and fields with Drupal's own
>> > structure which is wierd for 3rdparty app developers. e.g.
>> >
>> > $entity->field_name[language_code][delta] = array(value => whatever,
>> > $format => whatever)
>> >
>> > where the keys of the array are specific to the field type. I think
>> > this is the same in Drupal 8 because drupal has no notion of a
>> > 'flattened' entity or standard way of representing data in different
>> > fields before rendering.
>> >
>> > So I want to output flat arrays assuming the language is given and the
>> > field has a cardinality of 1.
>> 
>> Wouldn't it be quite straightforward to write a serializer that does
>> that?
> 
> In that case I've probably already written it inside Drupal hooks. I
> could separate it into another module if it would help. Drupal 7 which
> we are using has no concept of a 'serializer', though Drupal 8 does.

OK, that's probably an implementation detail we can ignore in this discussion here I guess.


>> > Your response didn't mention Hydra as a possible solution at all.
>> 
>> The first step is to serialize the data as JSON-LD. Hydra can then be
>> used to describe the operations that the various resources support.
> 
> ok so maybe we can come back to that.

Have you had any success with this in the meantime?


>> > I'm ready to write my own REST interface - its not that hard but I'm
>> > still hoping for some tools or at least standards I can work to. I
>> > wouldn't implement what I've seen of Hydra because it was too complex
>> > for me to understand. However if tools already exist, that wouldn't
>> > matter.
>> 
>> I'm still trying to understand what exactly you need/want to build.
>> Hydra is just a vocabulary which allows you to describe your service
>> interface in a machine-readable manner. Nothing more, nothing less.
>> The first step is to get the data out, as soon as you've accomplished
>> that, we can describe to a client how to interact with it.
> 
> Global Ecovillage Network has a database in drupal 7 with several
> content types and many fields, which are liable to change. We need the
> data to be accessible to view and edit and search via a REST
> interface. It is easy enough to export flat object in JSON, but
> building apps to edit dynamic content types will be a headache, so I
> understood Hydra provided a standard way to expose the data structures
> in a REST interface.
> 
> Is that clearer?

Yeah. I think Hydra should be a good fit. Kev Kirkland (CC'ed) is working on a AngularJS console. Maybe your goals overlap enough so that a collaboration would make sense!?


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 6 November 2014 21:14:21 UTC