codeparty/derby — pull request #326 by cjblomqvist (2013-08-10 22:26:40+00:00)
Title: Recursive context lookups

A mere suggestion (since I lack a full understanding of the grand plan for Derby 0.6):
I believe it would be nice to be able to send in data into a context that is not the top-level context, which will be data specific to that sub-level (child contexts) context. This will prevent the following scenario from going south (and might also be a neat feature):

Assume you are doing a change upon a specific item. This will/should trigger an update in the view. However, for some reason, the underlying data model is not in sync with this change, but you still need it to happen with the old data (because otherwise you cannot trust that a set of "setDiff" -changes will end up at the specific state you want to end up at). In other words, with this change you cannot trust the underlying data source (e.g. Racer's data model). However, with the change that were originally triggered, you sent along the data you want it to to change to. If you can pass along this data as (sub-) context-specific data, this will solve the issue.

The test should highlight how this scenario should (can) work. I've looked briefly of what'll be needed to fix this and basically the following needs to be fixed (I think):

1) One needs to be able to set context-specific data rather than having the same data at all contexts (child contexts)
2) .get() needs to look at it's specific context first, then, if it doesn't find anything, traverse up for any parent context that may contain this data (and pass along it's sub-context-specific segments appended to the segments one is trying to get).
3) This also means that the segments sent into context should only be the context-specific segments. E.g. if you have a child-context that starts at _colors, then ['green', 'name'] should be the segments sent in, not ['_colors', 'green', 'name'].
4) This means resolve at expressions (e.g. PathExpression.resolve) should not resolve all the way, but rather just send in the end parts of the expression.

It might screw some stuff up, like scenarios where you want to get the full path (like resolve works now). Basically (if I'm not mistaken) some traversing of aliases and such will be handled by the contexts rather than traversed by each expression. However, this might be more desirable (otherwise I have a hard time seeing how this functionality can be implemented without a lot of hacking).

There's a similar issue with Derby 0.5, where I've highlighted scenarios where this causes issues today: https://github.com/codeparty/derby/issues/324