I'm working on an editor in which I need to be able to define a custom view and controller as config items, then load these if the config items exist.
I'm storing each as a path to the view/controller, then loading the controller using assetsService, and setting the path in a call to dialogService.open to the view path from the config.
View works fine, it opens the custom view as the dialog. Issue is the controller - it loads (I see the promise resolve) but throws an AngularJs error where the controller is not a function.
Is it possible to define the path to the controller, load the file using assetsService, then have it resolve correctly when I render the view?
Thanks Dave - I took the easy way out. Figure if a user is having to add a controller, they can also register it in the package manifest. Would have been nice to not have to, but the end result is the same.
Adding conditional controller to property editor
I'm working on an editor in which I need to be able to define a custom view and controller as config items, then load these if the config items exist.
I'm storing each as a path to the view/controller, then loading the controller using assetsService, and setting the path in a call to dialogService.open to the view path from the config.
View works fine, it opens the custom view as the dialog. Issue is the controller - it loads (I see the promise resolve) but throws an AngularJs error where the controller is not a function.
Is it possible to define the path to the controller, load the file using assetsService, then have it resolve correctly when I render the view?
Is this even possible?
I know this can be done with angular but it requires to change routing and other things.
I know Andy Butland was trying something similar in his Personalisations Group package.
Maybe you can have a look at his source to see if he found a solution. https://github.com/AndyButland/UmbracoPersonalisationGroups
Dave
Thanks Dave - I took the easy way out. Figure if a user is having to add a controller, they can also register it in the package manifest. Would have been nice to not have to, but the end result is the same.
is working on a reply...