I'm using VB/.NET through Wonderware's ArchestraIDE Quickscript.net scripting language. I see there's quite a few ways to deal with JSON deserialization in .NET (DataContractJsonSerializer, JavaScriptSerializer, Json.net/Newtonsoft.Json) - but can't find any in the Wonderware subset.
It seems like JavaScriptSerializer isn't included as part of the .NET framework for Quickscript.NET, as ArchestrA doesn't recognise anything from System.Web.Script; and neither is DataContractJsonSerializer (System.Runtime.Serialization.Json isn't there).
I didn't find anything about json in the Quickscript.net docs either.
What is the standard/best way to deserialize JSON in this environment?
I'd recommend you to work on an external program to test JSON deserialization as a Stand-Alone method (using some third party libraries like Newtonsoft .NET) to compile it into a DLL. Then later import it to ArchestrA framework via the IDE and use your own method.
It will be a better approach since that with ArchestrA scripting you won't be able to declare classes or use listings, which are some things you should do when dealing with nice structured JSON deserialization for your better understanding.
Here's the catch, avoid compiling a code library that makes external reference to another one. ArchestrA's objects can't handle that external call in runtime, even if you import the other library and all other dependencies. There is a way to properly import a DLL that depends on other libraries to execute, but it's not the best practice in my opinion if you (or other unadvised person) are going to do future maintenance in your source code.
My final recommendation is to get the source code of open libraries (like Newtonsoft .NET), and make your program as a class alongside its project, and compile it into a single build. After that, you'll just need to import the library and do the proper method calls and classes instances.
If you prefer not to use a single compilation project, try to use ILMerge to merge the two libraries into one, even if they have a dependency, it works on ArchestrA objects at runtime.
I use newtonsoft .net library by importing it into the Wonderware IDE (Galaxy>Import>Script Function Library)
https://www.newtonsoft.com/json
Related
My application's vaadin version is upgraded from 7.3.6 to 7.4.6 and my Json code wherever I was using the GSON is starting to break.
I did googling for the same I found the similar issue mentioned in this stackOverflowPost
So should I conclude that elemental.json is not compatible with GSON and org.json was compatible with GSON.
GSON is not GWT compatible, which makes sense since it requires reflection to do its work. Likewise, org.json is meant to be used on a normal JVM.
On the other hand, GWT knows it is running in the browser, so doesn't need to implement its own JSON parser, since the browser already has one. There are several ways to use JSON in GWT, and GSON, org.json, and the built-in JSON parser of the browser all speak the same JSON.
All are compatible with each other, though you can't simply use elemental on the server or GSON on the client, or reuse the same server types on the client.
What specifically is 'starting to break'? What errors do you get, and what does the data that you are trying to send look like?
(Also worth noting, some of the 'json' in the linked post uses ' quotes for properties and strings, which is not legal JSON and should not work in the first place with any proper JSON parser.)
I am writing a Java EE app to be run within either Glassfish or JBoss, and I've been asked to provide JSON support for our JAX-RS clients.
Of course, simply enabling the JSON media type is simple enough but results in vendor-specific representations of my JAXB annotated models. So I'm looking for a way forward, one that ensures my tests work with both AS servers and that I still leverage JAXB/JAX-RS instead of writing lots of custom code.
I've tried adding a jaxb.properties file to select a specific implementation, but presumably shipping Jackson/MOXy/other JAXB library may conflict with provided libraries?
Any other ideas would be appreciated.
A new requirement has come down from the top: implement 'proprietary business tech' with the awesome, resilient Elixir database I have set up. I've tried a lot of different things, such as creating an implib from the provided interop DLL (which apparently doesn't work like COM dlls) which didn't work at all. CPython doesn't like the MFC stuff either, so all attempts to create a Python lib have failed (using C anyway, not sure you can create a python library from .NET directly).
The only saving grace is the developer saw fit to provide VBA, .NET and MFC Interop C++ hooks into his library, so there are "some" choices, though they all ultimately lead back to the same framework. What would be the best method to:
A) Keep my model definitions in one place, in one language (Python/Elixir/SQLAlchemy)
B) Have this new .NET access the models without resorting to brittle, hard-coded SQL.
Any and all suggestions are welcome.
After a day or so of deliberation, I'm attempting to load the new business module in IronPython. Although I don't really want to introduce to python interpreters into my environment, I think that this will be the glue I need to get this done efficiently.
I'm writing a RIM BlackBerry client app. BlackBerry uses a simplified version of Java (no generics, no annotations, limited collections support, etc.; roughly a Java 1.3 dialect). My client will be speaking JSON to a server. We have a bunch of JAXB-generated POJOs, but they're heavily annotated, and they use various classes that aren't available on this platform (ArrayList, BigDecimal, XMLGregorianCalendar). We also have the XSD used by the JAXB-XJC compiler to generate those source files.
Being the lazy programmer that I am, I'd really rather not manually translate the existing source files to Java 1.3-compatible JSON-marshalling classes. I already tried JAXB 1.0.6 xjc. Unfortunately, it doesn't understand the XSD file well enough to emit proper classes.
Do you know of a tool that will take JAXB 2.0 XSD files and emit Java 1.3 classes? And do you know of a JSON marshalling library that works with old Java?
I think I am doomed because JSON arrived around 2006, and Java 5 was released in late 2004, meaning that people probably wouldn't be writing JSON-parsing code for old versions of Java.
However, it seems that there must be good JSON libraries for J2ME, which is why I'm holding out hope.
For the first part good luck but I really don't think you're going to find a better solution than to modify the code yourself. However, there is a good J2ME JSON library you can find a link to the mirror here.
I ended up using apt (annotation processing tool) to run over the 1.5 sources and emit new 1.3-friendly source. Actually turned out to be a pretty nice solution!
I still haven't figured out an elegant way to do the actual JSON marshalling, but the apt tool can probably help write the rote code that interfaces with a JSON library like the one Jonathan pointed out.
I'd like to know what is the most efficient way of handling properties in Scala. I'm tired of having gazillion property files, xml files and other type of configuration files in Java and wonder if there's "best practice" to handle those someway more efficient in Scala?
Why would you have a gazillion property files?
I'm still using the Apache commons Digester, which works perfectly well in Scala. It's basically a very easy way of making a user-defined XML document map to method calls on a user-defined configurator class. I find it extremely useful when I want to parse some configuration data (as opposed to application properties).
For application properties, you might either use a dependency injection framework (like Spring) or just plain old property files. I'd also be interested to see if Scala offers anything on top of this, though.
EDIT: Typesafe config gives you a simple and powerful solution for configuration - https://github.com/typesafehub/config
ORIGINAL (possibly not very useful):
Quoting from "Programming in Scala":
"In Scala, you can configure via Scala code itself."
Scala's runtime linking allows for classes to be swapped at runtime and the general philosophy of these languages tends to favour convention over configuration. If you don't want to deal with gazillion property files, just don't have them.
Check out Configgy which looks like a neat little library. It includes nesting and change-notification. It also include a logging library.
Unfortunately, it didn't compile for me on the Mac instances I tried. Let us know if you have better luck and what you think...
Update: solved Mac compilation problems. See this post.