Can we make an addon package out of this so we can work on this outside of the Kotti tree? I've been doing similar here: https://github.com/umeboshi2/kotti_jsonapi

My repo is kind of sloppy and I've just been using it to get things going, so I wouldn't suggest actually using it, but a similar add on package with rest views could be created that may be easier to work with.

On 20.10.2015 21:13, Joseph Rawson wrote:

Can we make an addon package out of this so we can work on this
outside of the Kotti tree? I've been doing similar here:
https://github.com/umeboshi2/kotti_jsonapi

My repo is kind of sloppy and I've just been using it to get things
going, so I wouldn't suggest actually using it, but a similar add on
package with rest views could be created that may be easier to work with.

—
Reply to this email directly or view it on GitHub
#452 (comment).

Hi!

I'm the author of that rest.py module.

Sure, we can work in your github package, I don't have any quarrels
about it. It's good to have someone pickup the momentum, as I've been
quite busy lately.

I've noticed your relational metadata add on, seems pretty cool, I'll
have to take a closer look. One thing to note, you missed the
test_rest.py test, you should add it to your repo, as it had pretty
complete test coverage for what was done so far in rest.py

Cheers

@cruxlog, @tiberiuichim: thanks a lot for starting this!

@umeboshi2: I totally agree, that this feature should live in an add on.

relational_metadata indeed seems pretty cool, but I'm not sure, whether we'd need all of the included information in the JSON objects. On the other hand: they do no harm…

The relational metadata section seemed to be the best place to stash data related to the node, while both keeping with the api spec, and also not messing with the MetaDataSchema, where some of this should go, but with better names, etc. It was the only place I could determine as being appropriate to place info for the current user without having to create another view. Much of what is currently in the relmeta object should probably be split into other views and otherwise rearranged. I have also been starting to split the relmeta object so that we can use get query parameters to get the additional data we need.

I could never get the rest view to respond as originally designed. I would always get an html response and the rest view was never called. I had to name the view 'json', so it could be called as '@@JSON' to actually work. The view is kind of messy now, and I need it to be somewhat messy long enough to finish a frontend that will do everything I need. At the point I have enough to work with, I'll have a much better idea of how things should be arranged, based on how the site is used. At the moment, there is way too much crammed into relmeta. I am querying the database for children to be placed in a contents view on each request, which is NOT GOOD, and I need to make a query for when a contents view needs to be displayed. However, I can get an app going quicker and have a better environment to decide on how to arrange things.

@cruxlog I will put the test file in the repo today. I am not very experienced in making and running tests, but I am willing to learn more about it. This is one of the things I am really needing to learn anyway.