Development in a Class Library over Plugin

[SBarnes]

For a project that I am quoting on for a customer there will be a number of Business Logic Objects and Forms that need to be developed, whilst having done this in a plugin before I am leaning towards building a class library to do this instead for several technical reasons similar to what many of Jiwa own modules do. For this I have a couple of questions which are:

1. To make any form be able to be registered in Jiwa apart from declaring it as public is anything else required so that it can be registered in Form Maintenance?

2. To debug the class library is it possible to attach as a process to Jiwa like you used to be able to do with VB 6 or do you need to use System.Diagnostics.Debugger.Break?

3. Are there any other considerations or conventions that should be followed to simplify the process?

[pricerc]

re: 2 - yes. I do it all the time, although I'm generous with this bit of code as well:

Code: Select all

If Diagnostics.Debugger.IsAttached Then Diagnostics.Debugger.Break()


re: 3 - I haven't done it for a while, but you could try setting up a dummy executable that can instantiate Jiwa and fire off whichever plugin code you need to test, as an alternative to firing up a full JIWA every time.

I'd be interested in hearing about your technical reasons for doing a class library.

I have several class libraries that I've done as plugins. The project I'm working on now, I have over 30 plugins, mostly class libraries. The only downside I've experienced is circular referencing - e.g. Sales Order and Purchase Order libraries that need to talk to each other. If you have that going on, then you need to get creative, like add an "Interface" library that defines the interfaces you're going to be using, and have it earlier in the priority list.

I do most development in using Visual Studio - as suggested in a previous discussion on this topic, I now have a plugin that exports a plugin to a project folder, and will create a project file as well (.vbproj/.csproj).

[Mike.Sheen]

For a project that I am quoting on for a customer there will be a number of Business Logic Objects and Forms that need to be developed, whilst having done this in a plugin before I am leaning towards building a class library to do this instead for several technical reasons similar to what many of Jiwa own modules do. For this I have a couple of questions which are:

1. To make any form be able to be registered in Jiwa apart from declaring it as public is anything else required so that it can be registered in Form Maintenance?

2. To debug the class library is it possible to attach as a process to Jiwa like you used to be able to do with VB 6 or do you need to use System.Diagnostics.Debugger.Break?

3. Are there any other considerations or conventions that should be followed to simplify the process?

1. Yes - you need to implement the JiwaFinancials.Jiwa.JiwaApplication.IJiwaForm interface, or inherit from something which already implements that interface (such as JiwaFinancials.Jiwa.Maintenance.UserInterface).

2. As Ryan mentioned - yes you can attach your class lib project to a running Jiwa.exe instance and debug that way.

3. Not that I can think of right now.

[SBarnes]

Thanks guys

To answer Ryan's question as to the technical reasons

1. This will be calling apis for other products and putting API keys secrets inside code that can be opened and seen is something I would like to avoid.

2. Given the amount of code that will be involved if this goes ahead it will be more maintainable if all the source code doesn't have to reside in one file as it does with a plugin.

3. Use of an ORM preferably Entity Framework for reads from the database to simplify code could be used from inside a class library, which is definitely something that can't be done for a plugin.

4. Being able to use visual studio as the total ide, no offence to Jiwa as I think plugins and the way you can extend Jiwa is absolutely fantastic(In fact some other products I won't name could learn how to do extensibility from Jiwa) but it doesn't have the capabilities of VS but in fairness VS is no ERP either. Its use the right tool for the right job.

[pricerc]

2. Given the amount of code that will be involved if this goes ahead it will be more maintainable if all the source code doesn't have to reside in one file as it does with a plugin.

this is probably on the top of my list of things I'd add to plugins - I mentioned it somewhere else already; the ability for a plugin to be composed out of multiple files. It would certainly make it easier to maintain plugins using VS, or migrate existing code *into* a plugin.

[SBarnes]

Hi Ryan,

I don't disagree but support for multiple assets as well as source file would be optimal as would support for the entity framework to avoid lines of redundant SQL code but the other issue I see is also that any user can access the code by simply opening the plugin so there is no protection for sensitive data.

From the support of multiple files the ability to point at a vs project file and import a project wouldn't be that hard either.