- What is a “New Mounted Folder” in webdev? Its not explained in documentation.
- How is it different from a New Folder? This resources is also not explained in documentation though its self explanatory.
- Do we have to create each new resource by manually selecting/linking them in webdev?
- Are the the resources created under webdev copied in ignition project or they are just linked?
- Is it possible to copy an entire directory and its sub directories from disk to webdev component?
Are the “New Folder” and “New Mounted Folder” resources in wedev new additions in version 8 of ignition or they are available in previous versions as well? They don’t seem to be documented in webdev documentation?
Any help will be appreciated from any one.
Mounted folder resources have been in WebDev since 2014, so it’s not new!
I’ll notify our training team that we’re missing information in the documentation, but the summary is:
Mounted Folders are a way to expose a folder (on disk in your gateway) as a fetchable resource endpoint. Meaning, if you have a folder structure on your gateway machine that looks like:
/opt/public/webassets/a.jpg
/opt/public/webassets/info.html
You can create a Mounted Folder named “assets”, and point it to /opt/public/webassets/, and then you can access those assets via http://host:port/main/system/webdev/projectname/assets/a.jpg.
Hopefully this clarifies things.
2 Likes
Wow! A great feature indeed! So the resources are not copied to ignition project,they are just linked, (meaning the mounted folder structure should exist in the gateway server, when the module is deployed?).
And what is New Folder? I guess we can add any type of resource here such as html, css, js etc linking it from any folder in the gateway server? These resources are also just linked, not copied in the ignition project? Is that right?
Thanks a lot Perry.
best regards
I observe that the documentation for webDev is already updated! Very efficient! Really great team Ignition!
regards
1 Like
Thanks for updating the documentation for webDev. The Post example works fine! However, can you please also modify the same example to include doGet as well in postjson python resource with another button on client? I tried to modify it based on the documentation, but without success!
Can I define and initialize global variables in global scripts and use them in webDev GET/POST etc functions? If not then how can I define and initialize them out side the GET/POST etc functions. ( It works fine if I define them in the GET/POST functions but I want to be able to do it in some function outside of them?)
Also how do I distribute webDev code to others? Are these part of resources saved in project files? Is there a way to obfuscate the script code in these modules or its always visible and editable to users (for safety & security purposes.)?
WebDev objects are project resources just like anything else. Export/Import or use EAM to distribute.
You can use the standard resource "Protect" functionality to lock the resources from being edited, but AFAIK not obfuscate. If you have static content you could store it on the file system of the GW and use it as a mounted resource, but I don't think this will work with python code.
That's a good idea! This resource can then be included in the scripts I guess.
That a great idea too! So can I just export the webDev resource as a file which anyone can import in their projects?
Webdev scripts can call project and script modules like any other event script can. Project script module globals are persistent between project save events, or any designer that saves global (shared) scripts. You can see “restarting scripts” in the gateway log when this happens. Script modules that hold state in global variables should have some top-level code to initialize them. Consider using system.util.getGlobals() to gain access to a dictionary that lives longer.
If I want to initialize a list of global variables from a text file (say from one of the the webDev resources or a mounted drive) at the start, before webDev module is accessed by any client, what is the best place to initialize it from? can I initialize them from within webDev once with an init flag? Hopefully the global list will be accessible across different sessions (clients).
Incidentally, I created some global variable in a global script in server, and tried to access in webDev module, it doesn't recognize it!
If your initialize directly within the top level of your script module, no users of your module globals or functions will be able to use them uninitialized. But reading an external resource during init, if not reliably local, could block all scripting. For such resources, you would have to initialize some locking and kick off the rest of the initialization asynchronously. But then each user or function must wait on the init lock.
Such variables would be accessed as shared.someModule.someVariable. (Don't import them!)
If these are exclusively used by only webDev module, no other modules use these globals, then I think this approach should be ok!
But if the list is not too big, then perhaps reading it synchronously from a file only once at startup may not take long time! Also when I am sure that this resource is not required by any other module or user, then perhaps the solution may be ok.
No, it's not about limiting where you use the resource, but limiting the threads that can call it. WebDev, like everything else in Ignition (except Swing) is fully multithreaded.
The declaration should in which module? Where its defined or where they are used?
OK got it. However the global variables I want to define will be outside like static variable, not specific to threads. Any way let me try my approach, then I can discuss with specific code, with you.
If you have stuff that needs to be initialized just once on gateway startup, your script module should be something like this:
# Persistent data in project.someMod
#
persist = system.util.getGlobals().setdefault('project.'+__name__, {})
# Perform one-time initialization
if not 'someKey' in persist:
persist['someKey'] = 'whatever'
# Perform other initialization, every script restart
persist['otherKey'] = 'whatever else'
# Anything above stored in the persist dictionary can be more
# elaborately populated. Note that jython dictionaries are
# internally thread-safe, but you must protect your algorithms
# yourself.
Then elsewhere, like a WebDev script, you can do things like this:
print project.someMod.persist['someKey']
project.someMod.persist['otherKey'] = 'something new'
2 Likes
What about initializing the variables/stuff in gateway startup scripts and using them with their full path?
Also can we read a file from disk in these startup scripts? i.e. is file access possible in gateway scripts giving their absolute paths?
Your gateway startup script should call something in the script -- even a no-op function -- to cause it to be imported, which runs the top level code under jython's import lock. Top level variables are basically (but not quite) read-only to other scopes. Assignment should be in the script module, even if it is just an empty dictionary. You can read and set and remove keys in such a dictionary from wherever you wish.
Yes, but script importing is locked by the jython interpreter for the duration -- you can have side effects if you spend too much time doing it. You probably want to make sure to only use small, local files. That's why defining and running an async function that fills in your state dictionary is a best practice -- you can safely read your initialization from remote files or your DB.
1 Like