We have just published an Exchange Resource that shows how to use javascript with your Perspective views. The webdev module is required until they implement the srcdoc property of the iframe.
The resource makes use of jquery and velocity libraries.
Nice job. We do similar things by using WebSocket which sends a bidirectionaly to Perspective in an iframe. I try to make the iframe msg unique with sessionId and iframeId.
In any case, I don't understand why IA doesn't want to support Javascript in the Perspective.
Yeah, folks already get confused between the expression language and Jython, multiplied by the different execution scopes. Adding another base factor to that (with its own execution scope...) is not a winning combo.
I could see us adding an additional module (or maybe bundling functionality into WebDev) to allow you this level of control as an explicit opt in at some point. Another reason we don't expose Javascript to end users is to give us more control over the page - with user authored JS, anything is possible, and so there's more potential for "shenanigans" - explicitly malicious or unintentionally so, which leads to bad end user experiences (that they'll then blame on Ignition, naturally ).
Sure we will not call IA Support for this resources
Thanks @jpark for this new idea ..
Hope IA will come with something low code of consuming JS in Perspective
Even if this is true then why do other SCADA solutions or platforms support JS directly? I don't mention a name here but almost everyone does that. So surely they find a way to that problem
It is a quite bad idea to pass all UI data manipulation to the server to handle when we have a lot of horsepower on the client side. This causes client number limitation on one Ignition Server and the response is quite slow over the internet.
This is getting even worse when people use Jython instead of JAVA or expression for this. @pturmel created a wonderful free module for minimizing the usage of Jython and using the expression for some dataset manipulation which is 5 to 10 times faster but in the end, there are a lot of use cases you need JavaScript.
JS is faster, and it run on the client side, and give a lot of amazing option to the user which is not possible in other scripting language.
Also, I believe if IA opens this capability, the dev team doesn't need to add more components to Perspective and they are free to do better things as people themself can create new components and functionality and share it in exchange.
For example in the current version of the input box in Perspective, it doesn't support debouncer(Add some delay before exposing user key press). The debouncer logic is quite simple in JS with setTimeout() and clearTimerout() functions to implement.
But as of now, we need to go through to create a new module for our own custom input components which is hard and costly and loads extra code(resources) at Perspective Startup.
I hope in 8.3 instead of Ruby or GO language we have Javascript.
This will probably benefit you and @victordcq , but I'd rather not touch JavaScript.
JavaScript and Jython are very seductive languages because, at the beginning, you are just typing stuff and it's working. They don't tend to be very memory disciplined, and when you don't have serious static type checking, and you start doing something non-trivial, it's very easy to make mistakes and very hard to find mistakes since you don't even have a real debugger.
Especially when you are not a programmer by trade and you will start making changes in the mess that is web development, IA will have to triple its support budget probably.
The inspection tool in the browser could be used to debug js (it has breakpoints and such)
But yh, adding yet another langaugue the common designer would need to know seems not great.
And for the advanded js userers there is the markdown or component development avaible.
If you have a team of webdevs who can create even bigger js features/pages, then why do you need igntion and not just devolop the whole app in js?
As the one who started all this js stuff, i dont mind there not being a dedicated way to do this, it would be messy anyways even if they made somethign that worked in views. But yeah i did look into it, because there were some small things i wanted to change here and there... So there being a markdown which accepts html is rly nice, even if its ugly/hard to use.
I ask it again why other solutions use it then? How can prevent these kind of problem?
Also regard type if your program is big you use type script
In our case the code is very small and tend to manipulate the UI so let’s enjoy type less support for that
Of course
For example you use frame work x from Tatsoft
Which is base .net and support js and python 3 and .net language like c#
Or Wonderware
There are other solutions like myscada or webiq which base on node us and support is in client side for user
oh i dont know anything about other platforms, ia was the first scada platform i used.
Well anyways, if they have the budget to hire a js support team than good for them, but before i found out the js-injection in markdown, there wasn't really any talk about js. And even after, now there are only a handful of users who use it (unless maybe copypaste a solution of mine). So i dont think for now there is a big enough market for them to support this. Most people still struggle with css, let alone js.
Anyways the css stylesheet (which probably exists because of me) is great. So maybe they will find something for js too after a while If more and more js tricks start to exists on the forum or like this exange resource that poped up.
or an update to webdev module (tho no idea how those resources work there ive not used it)
Not familiar with Tatsoft, but for certain, Wonderware does not support Javascript. They support limited .Net with their own "QuickScript" on top of it. That's it unless something drastic has changed recently I'm unaware of. Wonderware's solution to web-based clients is AccessAnywhere and it's just pushing remote desktop through a web page.
You'll have none of those in 8.3, guaranteed. Offering alternatives to Jython is something we want to do, but as I mentioned in the dev panel at ICC, there isn't a solution out there right now that's compatible with our technology stack (and without significant non-technical drawbacks).
I already said I was on board with this capability! But the fact remains - for at least 90% of our users, Perspective as it is works well enough and offers enough functionality for them to accomplish what they need today. Everything we bundle into the platform or a first-party module like Perspective has to be supported more or less forever. There are absolutely use cases for "power users" like you, who are over-represented on this forum. Joe and Jane Doe working in a small factory have no use for those advanced capabilities. We have to try to cater to both audiences at the same time. Right now, the way we cater to power users is the module SDK.
Like I already said, I could see an enhancement to the Webdev module that made it easier to integrate custom JS with Perspective - that would be an olive branch to folks like you who want that extra power and flexibility without overwhelming "regular" users.
JS is not faster than Java. It is probably faster than Jython. But with things like WASM GC support getting integrated into browsers, it's possible there's a future where we can deliver a single compatible scripting language that works in Vision, Perspective, and on the Gateway. That's absolutely a better deliverable than telling end users they have to learn a third programming language to use Ignition.
This isn't a technical limitation. We're fully aware of how we could expose Javascript, authored in the Designer, onto Perspective pages. This is a business limitation - we haven't seen an argument compelling enough to make it worth the significant uplift required in: 1. our support department, 2. our training department, 3. our sales department, 4. our QA process.
OMI from what I've played with it is just a cleaned up window/graphical window manager that uses WPF instead of WinForms. It uses and works with the same graphics designed in System Platform with some additional components. Any old .Net controls you were using with InTouch have to be converted over to WPF (I have some that I can't get working because there's no WPF equivalent), but otherwise, it's still a desktop application that's more modern than InTouch, but last time I tried using it, there were limitations that prevented a lot of functionality we needed from working, so we didn't use it. I haven't tried it with 2020 or 2023 yet as we haven't had a client request it since 2017 when it came out. Now our clients that are still currently using Wonderware are looking at switching over to Ignition due to cost savings and potentially better functionality as well.
).
we will not call IA Support for this resources
