Visual Studio/Git integration.

[perry]

Jiwa is an ERP not an IDE, and whilst a full blown IDE in Jiwa would be wonderful, I doubt its going to be a reality but better integration with visual studio is something I would like to see.

It would also be helpful it there was a way to drag and drop controls to not only extend custom forms but also Jiwa's standard forms.

Agreed! The overall customization experience in Jiwa for developers is fine as it is ((thanks to Mike and Scot). I think giving non-developers ability to customize system will be more beneficial. e.g. custom workflows UI (on event X, perform Y, set value, insert record etc, etc.), customisable form (drag/drop/move fields).

VSCode is probably a better editor than what we have now, however, how would that help with source control of custom fields, dependencies and system settings? or we should we define everything inside VSCode?

[pricerc]

how would that help with source control of custom fields, dependencies and system settings? or we should we define everything inside VSCode?

It's been a while, but IIRC, VS Code operates within a folder (VS proper has a similar option), so I suppose all the pieces you mention could be exported to a plugin-specific folder, and then you manage it from there. Not terribly different from what I described for a VS proper integration, but perhaps a little simpler, since there would be no project file to manage.

Jiwa already compiles the code in plugin-specific folders, so I don't see it being a huge stretch for a VS code instance to use that folder.

There will still be the tricky part of getting code between VS<Whatever> and Jiwa.

[SBarnes]

One thing I hadn't added in is it would be good if through Visual Studio and then into the plugin itself if Jiwa supported the Entity Framework for reading data as it would enable getting rid of a lot of cookie cutter SQL code.

[pricerc]

One thing I hadn't added in is it would be good if through Visual Studio and then into the plugin itself if Jiwa supported the Entity Framework for reading data as it would enable getting rid of a lot of cookie cutter SQL code.

You'll need to expand that. Which cookie cutter code?

As a consumer of Jiwa's business objects, surely you shouldn't care what they're using underneath? Jiwa should be free to use whatever they want underneath, as long as the objects presented to you work.

I'd be curious to know what cookie-cutter code you have. In 7.2 I've removed most of the SQL queries I had left in plugin code, instead relying on the Jiwa business objects to do as much of that work as I can get them to.


Personally, I'm not a fan of EF. I used it for a while when I last had a job, but when every new version was completely incompatible with the previous one, and graphical designers disappeared in favour of 'code first' design, I lost interest.

In the end, if I needed classes, I typically used a micro ORM called PetaPoco https://github.com/CollaboratingPlatypus/PetaPoco.

Otherwise I now usually go straight to SqlCommands.

EF core may be better, but I'm not currently in a role where I'm building new applications, so I've no cause to check it out.

[SBarnes]

I am referring to non Jiwa tables and for look ups where you may usually use an SQL statement to query the database.

[pricerc]

I am referring to non Jiwa tables and for look ups where you may usually use an SQL statement to query the database.

Ah OK. If you're mostly wanting to avoid SQL, but do want to use classes, then you should definitely check out petapoco - it requires very little ceremony to use, and it only took me a couple of hours to get the hang of it; it's really easy.

To be fair, I haven't used it personally now in over two years (I can't believe it's that long since I left my job!), but I see it's still under active development.

[SBarnes]

If I was picking an ORM I'd have to say the Entity Framework or ORMLite (ServiceStack) would probably be the best choices only in the sense that if you are looking for learning material then the Entity Framework wins hands down and well ServiceStack is already used by Jiwa's Web API so don't learn something new if you don't have to.

I also would mind seeing support for .net Core and the ability to do more microservice type stuff including inbuilt web apps but that's going to move Jiwa from an ERP to a framework and that's probably going to be well beyond the scope of the original intent of this post.