Page 1 of 3

What is your preferred language for plugin development?

PostPosted: Tue Oct 27, 2015 7:23 pm
by Mike.Sheen
When Jiwa 7 was first released, we only supported VB.NET development for plugins.

We heard from a few people expressing their desire for us to support C#, so we added that back in version 7.00.115.00.

Now that we support either C# or VB.NET - we're curious as to what is the preferred langage? Answer the poll and we'll find out!

Re: What is your preferred language for plugin development?

PostPosted: Wed Oct 28, 2015 3:47 pm
by SBarnes
Hi Mike,

Are there any ideas / plans to support any languages beyond these two?

Re: What is your preferred language for plugin development?

PostPosted: Wed Oct 28, 2015 4:42 pm
by Scott.Pearce
There are currently no plans to support further languages. Feel free to suggest some here though!

Re: What is your preferred language for plugin development?

PostPosted: Wed Oct 28, 2015 7:20 pm
by Mike.Sheen
SBarnes wrote:Are there any ideas / plans to support any languages beyond these two?


Certainly no plans, and introducing another is quite a big deal.

The support for compiling and running any CLI language is fairly trivial, but the support for the editor to provide background compilation, syntax highlighting and intelliprompt is definitely non-trivial. The third party component we use for the editor to give the editing sugar (intellisense via reflection, et cetera) is the Actipro Syntax Editor. We purchased an add-on which does the VB.NET and C# support, but any other languages would require us to spend months writing the semantic grammar parser to support it. We wouldn't need that to compile and run plugins, but in order to make the editor more than just notepad, that would be required.

So, no - there probably won't be any other languages supported - not by the plugin code editor anyway. We feel C# and VB.NET are probably enough for 90% of developers and if you do have a pressing need to invoke say some elegant code you've got in F# or something, then there is nothing stopping you from writing in another language, and compiling that assembly and using a single line in a C# or VB.NET plugin to invoke that code - we just won't provide the editing support - you'll need Visual Studio or similar for that.

Mike

Re: What is your preferred language for plugin development?

PostPosted: Fri Oct 30, 2015 9:29 am
by SBarnes
Hi Mike and Scott

I was actually not thinking about .net languages at all and more towards the likes of HTML5, CSS and JavaScript that would open the possibility of for example of creating a screen such as a dashboard that could use something like d3.js. Given that there are a heap of good free frameworks and libraries in JavaScript being able to load them in and use them from with a hosted environment would be fantastic and have the beauty of being free.

I had seen something like this a while back in a completely different software system that allowed you house the equivalent of a web page /site within the application, I had thought of the connection when I notice a plugin to host a web browser, I suppose it would come down to whether or not there was a way to expose the Jiwa object model to JavaScript and how to allow Jiwa to self host a web site which is definitely possible under .net but would be completely different to MEF model where everything compiles.

To be honest this might now be way outside the scope of preferred language for plugins and on a completely different tangent than the original post.

Re: What is your preferred language for plugin development?

PostPosted: Fri Oct 30, 2015 9:45 am
by Mike.Sheen
SBarnes wrote:more towards the likes of HTML5, CSS and JavaScript that would open the possibility of for example of creating a screen such as a dashboard


I did mess around with a merged language, which let you embed C# or VB.NET with HTML, CSS and JS, which generates a web page viewed in a browser. I got this working, but the Actipro Syntax editor didn't give me intellisense I wanted. I started that project to see if I could get a good email template editor in Jiwa, and soon realised it could be used for a lot more - like reports, or as you suggested dashboards.

That project is on the backburner for the time being, but it has some exciting possibilities and I'm keen to get something like this into the product.

MergedLangTest.PNG
MergedLangTest.PNG (11.11 KiB) Viewed 9085 times

Re: What is your preferred language for plugin development?

PostPosted: Tue Nov 03, 2015 11:03 am
by SBarnes
Hi Mike,

Sounds great, pity it's on the back burner, being able to integrate with 3rd party products/ solutions particularly open source technologies that are becoming defacto standards would make the possibilities of integration endless.

Hopefully at some point all of this will make it to production.

Re: What is your preferred language for plugin development?

PostPosted: Tue Nov 03, 2015 7:50 pm
by Mike.Sheen
SBarnes wrote:Hi Mike,

Sounds great, pity it's on the back burner, being able to integrate with 3rd party products/ solutions particularly open source technologies that are becoming defacto standards would make the possibilities of integration endless.

Hopefully at some point all of this will make it to production.


Ahh - our coming REST API is probably going to be suited to your needs for that! I've been working on that on and off, and it will allow querying, reading and writing.

Re: What is your preferred language for plugin development?

PostPosted: Wed Nov 04, 2015 9:31 am
by SBarnes
By querying do you mean OData support(although its not true REST) or similar to on the objects currently and is there a "Beta Release Candidate" ?

Re: What is your preferred language for plugin development?

PostPosted: Wed Nov 04, 2015 9:30 pm
by Mike.Sheen
SBarnes wrote:By querying do you mean OData support(although its not true REST) or similar to on the objects currently and is there a "Beta Release Candidate" ?


Yes, OData is exactly what I've been tinkering with, along with a Swagger implementation known as Swashbuckle for interactive API documentation. I only leveraged OData for the querying aspects, as I didn't want to repeat what the OData guys did with the selecting / querying of data - which is ideal for our purposes - The other operations are pure WebAPI 2 RESTful.

I had some issues initially with Odata (but only with the querying / reading), but found by parsing the AST (Abstract Syntax Tree) OData gives in a request and mapping that to predefined queries against entities, I could successfully serve up results for select, sort, filter, expand, top, skip et cetera type queries. Swagger and thus Swashbuckle don't support OData (yet), so the interactive documentation I found lacking - there is some interest in swagger / swashbuckle supporting OData, but it does not look hopeful. My aim was to have Swagger as part of our WebAPI, but without significant modifications to swagger that doesn't seem likely. We'll need to either abandon hope of using Swagger, and roll our own API documentation - or find an alternative.

Sadly, there is no beta of this yet - my venture into this territory was cut short with other pressing needs.