WatchGroups: allow to attach/detach/move them

[tbosch]

In the router we will have the use case to hide views from the user, and in that case, they should not be digested. However, when the view is shown again, it should be digested again.

Something like WatchGroup.suspend / WatchGroup.resume.

[tbosch]

Actually, we need the following for templating:

RootWatchGroup:

• newGroup(context):WatchGroup - will just create but not attach the group

WatchGroup:

• addGroup(group:WatchGroup) - add a group to a parent group so that it gets digested
• remove() - remove the group from its parent. Should allow the group to be added somewhere else afterwards.

[tbosch]

@EisenbergEffect How far are you with your refactorings of the WatchGroups, caused by adding the observation strategy? For templating I really need this feature. Could you collaborate with @caitp to implement this?

[EisenbergEffect]

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch notifications@github.comwrote:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the observation
strategy? For templating I really need this feature. Could you collaborate
with @caitp https://github.com/caitp to implement this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780371
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

[EisenbergEffect]

We might need to also add something like "destroy" which removes a group
and also releases all internals resources.

On Wed, May 21, 2014 at 12:26 PM, Rob Eisenberg <rob@bluespireconsulting.com

wrote:

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch notifications@github.comwrote:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the observation
strategy? For templating I really need this feature. Could you collaborate
with @caitp https://github.com/caitp to implement this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780371
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

[tbosch]

Ok, great. If you have questions how to work with those linked lists,
@caitp knows :-)

On Wed, May 21, 2014 at 9:26 AM, Rob Eisenberg notifications@github.comwrote:

I've made good progress on the re-factoring. I think I can probably get
this done by tomorrow if that works for you.

On Wed, May 21, 2014 at 12:25 PM, Tobias Bosch notifications@github.comwrote:

@EisenbergEffect https://github.com/EisenbergEffect How far are you
with your refactorings of the WatchGroups, caused by adding the
observation
strategy? For templating I really need this feature. Could you
collaborate
with @caitp https://github.com/caitp to implement this?

—
Reply to this email directly or view it on GitHub<
https://github.com/angular/watchtower.js/issues/32#issuecomment-43780371>
.

Rob Eisenberg,
President - Blue Spire
www.durandaljs.com

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/32#issuecomment-43780583
.

[EisenbergEffect]

@tbosch I need some more info on this. What should happen if newGroup() is called without a context? Currently, it gets the context from it's parent, but since we are creating them detached, that is no longer appropriate. What about the getter cache? What about the expression cache? All these things come from the parent, affect the internal behavior and you can't actually use the group without them. Need some more guidance before being able to proceed.

[tbosch]

We had a hangout to clarify the issues...