Support for nested composition

[gabrielmontagne]

Let's say we are on resource /dashboard/{idA}/{idB} (/dashboard/AA/YY) which composes /profile/{idB} which in turns composes /account/{idB}

When we navigate to /account/2343, we want address to know that the dashboard resource can handle it.

[mstade]

When we navigate [...]

What we mean by this needs clarification. Are we talking navigation via HTML controls? Using .navigate? All of the above?

Previously, we solved this by having resource definitions declare what other resources they composed, then interrogating the view currently attached to a node to see if that resource could deal with whatever URL was being navigated to. This probably had its limitations, but off hand I can't remember them. Do you?

[gabrielmontagne]

When we navigate [...]

What we mean by this needs clarification. Are we talking navigation via HTML controls? Using .navigate? All of the above?

When we go to the new URL, maybe even by clicking on a plain anchor <a href="/account/2343">marcus' thing</a>.

We do support one level composition... so address knows that if I'm in /dashboard/AA/YY and we click on <a href="profile/2324">/profile/2324</a> it should call dashboard resource with AA and 2324.

But it doesn't know that if I try to go to /accounts/2343 that because dashboard composes profile, it transitively composes account. Sorry for the poor naming!

But yeah, what you're saying is there, but it's not recursive.
I wonder if it can just be made recursive like that or if there are problems or situations in which we would be "stuck" on a resource we don't want.

[mstade]

I think we considered automatic composition of transitive resources in the previous work as well, but decided against it because it was magic. I'm pretty sure we did implement support for transitive resource composition though, just that the grandparent had to declare upfront what it was composing. If it didn't navigation was handled further up the chain with the only resource actively composing everything being the shell, and that really only happened because it hijacked clicks on anchors and used the history API.

[gabrielmontagne]

Yeah, the thing is that in 1995, when /dashboard/{a}/{b} was implemented profile implemented the accounts itself but later, in 2005, accounts/{b} became its own resource i don't want to go back to the dashboard svn repo (or CVS) to update the resource declaration only.

[mstade]

Fair point, and cool story bro. :o)

Any thoughts on how it would work? I have no good immediate thoughts, only really half baked terrible ones.