Is it possible to access top-level function inside Dart WebUI WebComponent?
This is possible with Fancy Syntax. See the section on registering top-level variables: https://github.com/dart-lang/fancy-syntax#registering-top-level-variables
Related
I'm creating a Template Spec using Bicep, which works fine. Adding a custom UI to the Template Spec using a uiFormDefinition file also works. However, when I try to use the control 'Microsoft.Solutions.ArmApiControl' in the UI definition, it fails with the error Failed to create element of type: 'Microsoft.Solutions.ArmApiControl' named 'sqlCapabilities'. I found that I can get rid of the error by removing all referencing functions from the path property, like this:
{
"name": "sqlCapabilities",
"type": "Microsoft.Solutions.ArmApiControl",
"request": {
"method": "GET",
"path": "/subscriptions/34d76722-9b63-464d-b742-11bf072d1fc1/providers/Microsoft.Sql/locations/westeurope/capabilities?api-version=2021-11-01"
}
}
... but that doesn't actually seems to do anything. (And even if this would work the element wouldn't be very useful without referencing functions.)
While reading the documentation, I noticed there are two sandboxes in the Azure Portal for developing uiFormDefinition files:
https://portal.azure.com/#view/Microsoft_Azure_CreateUIDef/FormSandboxBlade (titled "Form view Sandbox"), which is linked to from the Create portal form page of the ARM template documentation using the shortlink https://aka.ms/form/sandbox.
https://portal.azure.com/#view/Microsoft_Azure_CreateUIDef/SandboxBlade (titled "Create UI Definition Sandbox"), which is linked to from the Create portal interface page of the Azure Managed Applications Documentation.
They look similar, but they use different schemas: the UI Definition sandbox uses https://schema.management.azure.com/schemas/0.1.2-preview/CreateUIDefinition.MultiVm.json# and the Form sandbox uses https://schema.management.azure.com/schemas/2021-09-09/uiFormDefinition.schema.json. The Form sandbox also has a few additional options such as the ability to specify the "Package Type" and "CUID".
Both sandboxes have a list documenting UI elements, which both point to the same destination: the Azure Managed Applications documentation.
The thing is: when I use the "Create UI Definition Sandbox" the 'Microsoft.Solutions.ArmApiControl' UI element works fine, even when using referencing functions like location(). However, I can't use the resulting file with the Template Spec: it attaches OK but when trying to deploy the Template Spec in the Portal I get this error: Invalid UIFormDefinition Schema. Click here to fallback to default experience.
Using referencing functions and/or 'Microsoft.Solutions.ArmApiControl' in the "Form view Sandbox" results in the problems mentioned at the beginning of this question.
Experimenting further, it looks like all functions work in both sandboxes, with the exception of referencing functions like location(), resourceGroup() orsubscription(): those only appear to work in the UI definition sandbox. The same applies to some UI elements.
Perhaps I missed it, but I wasn't able to find where this behavior is documented.
Is there a way to use the referencing functions and Microsoft.Solutions.ArmApiControl in a form definition for a Template Spec? If so, how can I do that?
TL;DR - you can do what you want, take a look at this: https://techcommunity.microsoft.com/t5/azure-governance-and-management/using-azure-templatespecs-with-a-custom-ui/ba-p/3586173
Long version, there are 2 schemas/formats for portal ui (as you discovered), there is an "old" version CreateUIDefinition.MultiVm.json and a newer version uiFormDefinition.schema.json - the newer version is largely a superset of the old version... i.e. it supports all the old stuff and has some new stuff. This distinction is not well documented yet.
templateSpecs only support the "newer" schema.
That help?
I habe puppetserver and three nodes. I created on master createuser.pp file with createuser class.
Additionally I created site.pp with following content:
node 'app01','app02,'app03'{
include createuser
}
Now executing from each app server: puppet agent -tv will create user. All work fine.
My question is can I do the same without defining site.pp manifest ?
I can of course add include createuser at the end of class definition in file createuser.pp
but how can i run it from all three app hosts ? Do I need to create a tag ?
Thanks for any tips.
can I do the same without defining site.pp manifest ?
In any version of Puppet still supported, you can do it without a file named site.pp, but not without a "site manifest" in a more general sense. This can be a single file of configurable name (default "site.pp"), or it can be the collective contents of all the files in a specified directory. Either way, the site manifest is the entry point for catalog building. Other manifests are consulted only as needed.
I can of course
add include createuser at the end of class definition in file
createuser.pp
In current Puppet, top-scope code may appear only in the site manifest (though some historic versions were more lax). Your class should be in a module, not in the site manifest, and in that case no, you couldn't use an include statement in the same file with the class definition. You need a class declaration either in the site manifest or in some other class directly or indirectly declared by the site manifest.
but how can i run it from all three app hosts ? Do I
need to create a tag ?
On the agent side, tags are useful only for limiting which classes and resources are applied. Only those already in its catalog are available -- you cannot use tags from that end to apply classes or resources that wouldn't ordinarily be applied.
You ensure that the class is in the node's catalog by declaring it in the site manifest (as you are doing now) or in another class directly or indirectly declared in the site manifest.
is there a way to update configuration variables of my app within app's code?
I want to get the effect of running:
firebase functions:config:set service.client_secret='YMzPjIaVZBZKLRgGq'
in one of my functions.
I'm looking for something like this:
functions.config.allegro.refresh_token = json.refresh_token;
Thanks in advance!
This is not possible. Environment variables are effectively deployed along with your functions. Just like the code of your function can't be modified at runtime, your env vars also can't be modified. You need to redeploy your functions to get new configs.
If you need dynamic configs, consider storing them in a database instead.
I'm using ReactJS.NET to render react components on the server. To do this, you need to pass it a list of components on app start up (on the server). ReactJS.NET doesn't do modules though, so you need to pass it a bundle in which all components are public in scope.
The preferred way of doing this is by creating a separate local bundle that you can pass it.
In the documentation for ReactJS.NET (http://reactjs.net/guides/webpack.html) they give an example of doing this with webpack, specifically with the expose-loader plugin (https://github.com/webpack/expose-loader).
Is there a similar plugin / option using JSPM?
I've been trying to modularize my server and web apps. i've read about exports and module.exports in Node here and here.
http://www.sitepoint.com/understanding-module-exports-exports-node-js/
http://liangzan.net/blog/blog/2012/06/04/how-to-use-exports-in-nodejs/
I get how it makes the functions available to other files / scripts, but what happens to the modules required within the exported file? If I require websockets in some file, export it and require it within another file, does the other file inherit the websockets from the exported file? Is it similar to a header file in C and just pastes that module into your file?
When you require() a module in node, it gets executed inside a closure and the value exported by the module is cached. So any additional require()s for the same module (located at the same absolute path) will always get the same object/value/whatever.
So in your websockets example, the require('websockets') that you do in your module is not automagically available to anyone requiring your module. Everything in a module is done within a separate, local scope (you can read/write the global scope accessible by all modules, but you really should not do that). This is why you need to explicitly export values for them to be seen by outsiders.