pathToKey exposed, collectSkelData in json renderer

[sveneberth]

To get the current breadcrumb path in the Vi we need the method pathToKey.
I declared them as exposed and made some adaptions for proper usage in multiple renderers.
This PR is related to PR #26

[phorward]

It's OK!

[tsteinruecken]

No, it's not okay :(.

• The new "collectSkelData" function in json render is already there (renderSkelValues, it just has to be renamed & get support for lists)
• The result gets processed twice: self.render.collectSkelData in https://github.com/viur-framework/server/pull/141/files#diff-b5b4235f59599a1773872de5c166ca84R185 - and then again by self.render.view in https://github.com/viur-framework/server/pull/141/files#diff-b5b4235f59599a1773872de5c166ca84R187
• We pass a list to render.view while we should call render.list instead

[phorward]

Hello all,

OK after a more detailed review and inspection of @tsteinruecken's objections, I have the following annotations on this issue:

1. @tsteinruecken is right with all points
2. The implementation of pathToKey in the tree module is not straightforward - what if I want to get the path to a leaf? That is not possible in this implementation, so only paths to nodes can be obtained.
3. The hierarchy module also provides a similar function on this, which behaves entirely differently and is also exposed only internally. It would be better to have a general revision on both functions and prototype concepts before this is merged.

My proposal would be to reject this pull request for now and find out a better solution in ViUR 3.0.
Nevertheless I've recently pushed a version that should fix above issues and works, but in my opinion and especially regarding to point 3 I think its still incomplete. The path in the Vi can also be obtained by building a pathToKey function on client-side, which would not be a problem with run-time lacking (did this in other projects as well).

[phorward]

please see my previous comment.

[tsteinruecken]

Okay for me; ive moved it to 3.0