Hi John,
 

> 1) There are often a number of methods on the directive's controller that 
> are only used by the directive itself and we don't want those available to 
> the outside world and 
>
This is indeed something you might encounter. There are way's around this. 
For example, put those methods inside the link function, and attach them to 
the isolate scope. They still will be available to your controller, just 
less visible. As often, building a system is handling the trade-offs you 
are comfortable with.
 

> 2) when you see a directive in a template, you have to go look up the 
> directive source to understand what the API is.  
>
Hmm, I would say you are in need of some documentation. This is the same 
issue you had with your initial point 1. Building an API for something 
brings the need for some documentation with it.

If the above trade-offs are not acceptable for you, you can go indeed with 
your option 2. However, if you want to create directives that work 
together, this is going to be much harder. Have another look at the sample 
I linked in. There are 3 directives in the template that work as a single 
API. (as this was a code-sample from somebody else, it's not exactly how I 
would name/do things normally!) The clearSet directive handles as a group 
holder, the other 2 interact via that one. 
I believe a directive should have a single purpose. then you can combine 
those to achieve complex behaviors. 

Hope this helps you a bit,
Regards
Sander

-- 
You received this message because you are subscribed to the Google Groups 
"AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

Reply via email to