Skip to content
This repository was archived by the owner on May 29, 2019. It is now read-only.

support nested properties and evaluations on <tab active=".."> attribute #1539

Closed
bloo opened this issue Jan 7, 2014 · 6 comments
Closed

Comments

@bloo
Copy link

bloo commented Jan 7, 2014

I can only get:

<tab active="adminrole">

to work if $scope.adminrole=true, but I would like to see:

<tab active="role == 'admin'">

or even

<tab active="role[admin]">

supported.

@chrisirhc
Copy link
Contributor

If you mean to make the tab selected when role['admin'] is true, I don't see why that doesn't work. See this plunker: http://plnkr.co/edit/1zSyRyrIOitmuDD0zBbN?p=preview

Could you post an example?

Regarding the second case for active="role == 'admin'", this expression isn't assignable while the active attribute currently only supports models. It might be an interesting use case to support and shouldn't be difficult to add.

@bloo
Copy link
Author

bloo commented Jan 8, 2014

Thank you Chris - you're right, that does indeed work. I had a careless
syntax error in my trial example.

The other example (evaluation) is not supported, correct? I can live
without it now that I can nest my boolean properties deeper within $scope,
though.

On Tue, Jan 7, 2014 at 6:48 PM, Chris Chua [email protected] wrote:

If you mean to make the tab selected when role['admin'] is true, I don't
see why that doesn't work. See this plunker:
http://plnkr.co/edit/1zSyRyrIOitmuDD0zBbN?p=preview

Could you post an example?


Reply to this email directly or view it on GitHubhttps://github.com//issues/1539#issuecomment-31792517
.

@chrisirhc
Copy link
Contributor

Yes, the other evaluation-only method doesn't work right now. No problem. Cheers!

@pkozlowski-opensource
Copy link
Member

@chrisirhc we could try to have support for the read-only active attribute, or just do what we've discussed in #1496
Personally I'm more and more leaning towards #1496. WDYT?

@chrisirhc
Copy link
Contributor

#1562 's fix for read-only attribute seems reasonable. I think should still go through with #1496 as it cleans up the implementation but we can put that off for a bit as it might be a breaking change.

@rvanbaalen
Copy link
Contributor

Continuing in #1496

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants