Access an instance config from a directive in a controller? Or am I barking up the wrong tree?

[Jason Smith]

I'd like to create some reusable components that can be added to the page, but that can have per instance configuration.

That is to say, I'd like to be able to show a "hello [name]" type widget, but provide the "name" as a parameter per-widget so that I can use the controller or directive multiple times on the page with different presentations.

While the instance ID is known at server side, the configuration settings are not necessarily known (pulled via service with instance ID as parameter for example)

So the server side would ideally spit out a directive or controller attached to div with an instance ID as parameter. Within the directive/controller we'd have some base html that may leverage scope for expressions. 

We've tried a number of variations that have scope issues, or requirements for repeated code in every controller. Since the modules are written by a distributed team, we'd like to reduce the potential for error in the boiler plate code in the controllers, if instance available its instance configuration is magically accessible. 

We're currently using something of this form

http://jsfiddle.net/SiliconValet/RMTyY/1/

But dislike the extra wrapper.

Either scope is unavailable to the controller (based on timing) 

http://jsfiddle.net/SiliconValet/RMTyY/2/

http://jsfiddle.net/SiliconValet/RMTyY/3/

or we require every controller to be aware of it's attributes 

http://jsfiddle.net/SiliconValet/RMTyY/4/

The problem here is that we're requiring the developer to rewrite boilerplate code, we'd like to have the instance conf magically available if an instance ID is there. 

Note that the instance ID 'abc' and 'def' would be output by our CMS in the base html. What is the best practice here? 

[Kai Groner]

Hi Jason,

I've been pondering this problem for a while, but I haven't found an answer I'm happy with.

The idea of using reserved names to pass parameters into a controller is very unsatisfying, to me.  It limits composability, since you can only have one variable named instance (going with your example).  It also adds a convention that isn't obvious to someone reading the markup.  Certainly conventions can be learned and if you get a lot of mileage out of a pattern the price might be worth it, but I think the controllers where the price is worth it are the exception and not the rule.

Using a custom directive to be able to have a controller with arguments is the next option I've considered, but it doesn't feel quite right to me.  I wasn't aware $attrs was available to controllers.  It's a bit of a violation of abstraction, but it's closer to what I think I'm looking for.

The other avenue available for this is injecting locally defined dependencies.  $route+ng-view use this in 1.1.x, using the resolve route property.  AFAIK, ng-controller doesn't have a mechanism for injecting locally defined dependencies, yet.

I've been wondering about a syntax like:

<div ng-controller="FooCtrl(instance)">...</div>

or maybe:

<div ng-controller="FooCtrl({instance: instance})">...</div>

This makes clear which instance you are passing (via the scope, or inline), and I think it would make controllers more reusable.

I see @majgis proposed an ng-resolve directive that achieves the same thing with a different  syntax:

https://github.com/angular/angular.js/issues/2092

If this idea appeals to you, you might could implement it as a variant of ng-controller.

Kai

--
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 angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Smith]

In my case, all of the instance configuration is stored in a global array keyed by the instance ID, so one variable is all I ever need. I'm not keen on the idea of potentially having a serialized object as an html param should needs grow out that way. Better to let the model handle it and just find some way to tie instances together. 

The format you describe would fit our needs perfectly, so I adapted the example concept

http://jsfiddle.net/SiliconValet/HzeNE/3/

Probably an easier way to do this, but I've got my proof of concept. Thanks!

[Jason Smith]

Latest fiddle, could I get some comments on this?

http://jsfiddle.net/SiliconValet/HzeNE/6/

[Jason Smith]

Oh ick, meant to write this elsewhere.

Would still appreciate comments but this particular post was meant for a different group

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/6YicM4nOe4k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.