I'm creating a property editor in code, where I can define JavaScript assets that are needed (i.e. angular controllers), like this:
[PropertyEditor("My Alias", "My Name", "/App_Plugins/MyPath/my.angular.view.html", ValueType = "JSON")]
[PropertyEditorAsset(ClientDependencyType.Javascript, "/App_Plugins/MyPath/my.angular.controller.js")] public class MyPropertyError : PropertyEditor
{
}
However I have a requirement where some of the JavaScript assets aren't known until run-time. Does anyone know if there's a means of specifying these in code rather than through these attributes?
That sounds promisingDave, could pass the information at run-time to the default angular controller for the property type and load them in that way. Thanks very much, will give it a go and update with some details if it works out.
Hmm... seems to load OK, but if I open up the angular view (that I'm requesting via the dialogService) I get this JavaScript error
Argument 'MyController' is not a function, got undefined
So somehow the view isn't finding it's controller.
If I add it using the [PropertyEditorAsset] attribute though like in my original post, it works as expected. Is there something else I need to do after loading it via the assetsService to "register it" or something like that?
That's the thing. If I include it as an asset on the C# class it works as expected. If I load it via the assetsService, before I call dialogService to pop up the dialog view, it doesn't.
Sure - the codebase itself is here (whole thing is very early days).
Specifically the property editor is here - you can see on line 10-11 where I have the attribute referencing the asset. This works, but I don't want this as in reality I won't necessarily know the assets needed at run-time (the package is intended to be extendable).
My main angular controller for the property editor is here. Line 20 is where I'm loading the dialog controller asset and line 48 where I'm attempting to use it in the dialog. It's when that is triggered that the error noted above appears.
Thanks Dave, and sorry for delay in responding, was travelling yesterday afternoon. The intention longer term is to have those controllers defined in a separate assembly, so the package can be extended by adding other "criteria". Hence athough in this case the controller I'm looking to load is in the local assembly and hence known at compile time, they won't all be, so I need to be able to discover and load them at runtime. For the server-side parts that is working, but just not for loading the client-side angular controller.
Been looking at this further and don't think it's feasible to use assetsService to dynamically load in controllers unfortunately. This blog post explains the problem with trying to load a controller after the Angular app has bootstrapped. It also gives a way to get around it but I think would need some changes to the core code start-up process for it to work.
So I think I need to solve this server-side after all. And so going back to my original post, the problem/question is whether I can register assets in the same way the PropertyEditorAsset attribute does - but via a code routine rather than an attribute which by necessity needs to be defined at compile time.
Managed to get this working just for the record, though it's rather a hack really. Basically the one (and I think only) way I can find to inject an angular controller is to use the [PropertyEditorAsset] attribute - indeed that's what it was added for. The complication I had was that I wanted to make this package extensible, and hence there could be angular controllers I don't know about at compile time.
The way I've gotten around this is to rely on anyone that would build such an extension creating a property editor, purely for the purpose of adding a [PropertyEditorAsset] attribute to it. It wouldn't actually be used - but that's sufficient to have the JavaScript containing the angular controller added and registered. Only practical downside is there's an entry in the Create new data type's property editor drop-down list that's not needed and shouldn't be used, so think I can live with that.
Loading PropertyEditorAssets at runtime
I'm creating a property editor in code, where I can define JavaScript assets that are needed (i.e. angular controllers), like this:
[PropertyEditor("My Alias", "My Name", "/App_Plugins/MyPath/my.angular.view.html", ValueType = "JSON")] [PropertyEditorAsset(ClientDependencyType.Javascript, "/App_Plugins/MyPath/my.angular.controller.js")]public class MyPropertyError : PropertyEditor { }
However I have a requirement where some of the JavaScript assets aren't known until run-time. Does anyone know if there's a means of specifying these in code rather than through these attributes?
Thanks
Andy
Maybe you can use the angular assest service to load the assests ?
http://umbraco.github.io/Belle/#/api/umbraco.services.assetsService
Dave
That sounds promisingDave, could pass the information at run-time to the default angular controller for the property type and load them in that way. Thanks very much, will give it a go and update with some details if it works out.
Hmm... seems to load OK, but if I open up the angular view (that I'm requesting via the dialogService) I get this JavaScript error
So somehow the view isn't finding it's controller.
If I add it using the [PropertyEditorAsset] attribute though like in my original post, it works as expected. Is there something else I need to do after loading it via the assetsService to "register it" or something like that?
Andy
Is the controller defined in the view requested by the dialogservice ?
Dave
Yes, the view has...
And you have included the js file for the controller as asset on your csharp class or are loading it through the assetService ?
Dave
That's the thing. If I include it as an asset on the C# class it works as expected. If I load it via the assetsService, before I call dialogService to pop up the dialog view, it doesn't.
Can you show me the code with the asset service and the view loading ?
Dave
Sure - the codebase itself is here (whole thing is very early days).
Specifically the property editor is here - you can see on line 10-11 where I have the attribute referencing the asset. This works, but I don't want this as in reality I won't necessarily know the assets needed at run-time (the package is intended to be extendable).
My main angular controller for the property editor is here. Line 20 is where I'm loading the dialog controller asset and line 48 where I'm attempting to use it in the dialog. It's when that is triggered that the error noted above appears.
Thanks Dave, appreciate you taking a look.
Andy
Hi Andy,
I had a look at your code. What is confusing me is that you try to load a controller which seems to be fixed to me. So why one to load it at runtime ?
Dave
Thanks Dave, and sorry for delay in responding, was travelling yesterday afternoon. The intention longer term is to have those controllers defined in a separate assembly, so the package can be extended by adding other "criteria". Hence athough in this case the controller I'm looking to load is in the local assembly and hence known at compile time, they won't all be, so I need to be able to discover and load them at runtime. For the server-side parts that is working, but just not for loading the client-side angular controller.
Andy
Okay. Will need to find some time to dig in some deeper.
Dave
Been looking at this further and don't think it's feasible to use assetsService to dynamically load in controllers unfortunately. This blog post explains the problem with trying to load a controller after the Angular app has bootstrapped. It also gives a way to get around it but I think would need some changes to the core code start-up process for it to work.
So I think I need to solve this server-side after all. And so going back to my original post, the problem/question is whether I can register assets in the same way the PropertyEditorAsset attribute does - but via a code routine rather than an attribute which by necessity needs to be defined at compile time.
Andy
Managed to get this working just for the record, though it's rather a hack really. Basically the one (and I think only) way I can find to inject an angular controller is to use the [PropertyEditorAsset] attribute - indeed that's what it was added for. The complication I had was that I wanted to make this package extensible, and hence there could be angular controllers I don't know about at compile time.
The way I've gotten around this is to rely on anyone that would build such an extension creating a property editor, purely for the purpose of adding a [PropertyEditorAsset] attribute to it. It wouldn't actually be used - but that's sufficient to have the JavaScript containing the angular controller added and registered. Only practical downside is there's an entry in the Create new data type's property editor drop-down list that's not needed and shouldn't be used, so think I can live with that.
Andy
is working on a reply...