Chris Anderson wrote:
On Tue, Mar 17, 2009 at 4:07 PM, Daniel Friesen <[email protected]> wrote:
Chris Anderson wrote:
...
Taking this approach would probably require that you store the full
path(s) to the widget on the widget document itself. This isn't so bad
but does complicate changing only a parent node say, halfway up the
tree, as you have to touch all it's subnodes.
Not really possible. There is no full path to the widget in the document.
Quite simply because widgets don't belong to a document (I have limited it
so that widgets can't cross sites) but a widget can belong to multiple
parent widgets and as a result can belong to multiple pages.
The ability to put the same Widgets on multiple pages is essential to the
app we're building so it can't really be worked around.
This is possible, as long as you are willing to eat up a fair amount
of disk space caching *all possible* paths to the jit. I guess I'm
essentially talking about running your "walk" function and then
memoizing the results of it [an array of paths] on the jit document
itself. This should be possible as long as the graph of nested jits is
acyclic.
The queries from such a view would be pretty clean. For a given root
page-id you'd be able to pull in all and only the jits on that page
(sorted according to their nesting order) in a single request.
Counter-proposal, I have an idea for document references in CouchDB.
It's completely backwards compatible, usable in a number of cases, and
should theoretically perform quite well.
I've drafted up a big explanation, think it would be a good idea to put
it on the Wiki and ping the dev list?
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
