ivh-treeview-expanded-attribute not honored when using ivhTreeviewMgr.expand() about angular-ivh-treeview HOT 5 CLOSED

Sorry, not sure I'm following you. Would you mind creating an example using our template jsbin/plunkr/etc.? I added some tests to verify this is behaving as intended:

• https://github.com/iVantage/angular-ivh-treeview/blob/master/test/spec/directives/ivh-treeview.js#L97-L105
• https://github.com/iVantage/angular-ivh-treeview/blob/master/test/spec/directives/ivh-treeview.js#L97-L105

Keep in mind that if you are using ivhTreeviewMgr in your own code you must tell the manager which property it should use for expanding/collapsing (as in the last example).

from angular-ivh-treeview.

I did notice the optional overriding opts parameter. I guess I assumed using ivh-treeview-expanded-attribute as a directive attribute would behave the same way as setting expandedAttribute in the ivhTreeviewOptionsProvider--completely overriding the default behavior of that option and not require always passing in the override through the opts parameter.

The issue I see is that it doesn't make sense to have an ivh-treeview-expanded-attribute directive attribute if it does not use it at all times (like it does when setting expandedAttribute in the ivhTreeviewOptionsProvider).

from angular-ivh-treeview.

Specifying a new default option with ivhTreeviewOptionsProvider is just as you say: overriding a global default. We can safely use these new values everywhere.

The thing with the attribute level option is that it's local to a particular tree instance.

You can, for example, have multiple trees (that maybe even use the same data!) which each use different attributes for tracking expanded/collapsed states. So we want to keep these settings sandboxed.

Coupling view attributes to the service behavior would also create undesirable race conditions:

• ivhTreeviewMgr.expand(...) --- uses existing defaults
• view is processed
• ivhTreeviewMgr.expand(...) --- now uses values specified in view...?

In general I don't think it's a great practice to assume your e.g. controller (or arguably worse, service) knows anything about your view - or even assume a particular view has been compiled and linked. So when you want to use ivhTreeviewMgr to manipulate tree data and that data has attributes which differ from the registered defaults, it's appropriate to have to provide that information to the manager.

from angular-ivh-treeview.

Thanks for the explanation. It makes sense. You can close this.

from angular-ivh-treeview.

Sorry for the confusion, I'll revisit the docs and see if I can make this behavior more clear.

from angular-ivh-treeview.