Forums

by Barry Williams >> Wed, 25 Jan 2006 21:15:17 GMT

I am just starting to use Jade for a new development project and have a question for experienced Jade developers. I want to develop some core modules that are common to most applications, eg: GL, Invoicing, statements/receipts, client/staff details, security module, etc. Looking at the options, there are two obvious approaches that could be taken.

1. Have a common superschema with these common modules and then create subschemas to add the application specific modules and any application specific customizations that may be required to the common modules inherited from the superschema.

2. Create the modules in stand-alone schemas and then import them as packages into the application specific schemas.

What experiences have other developers had with these two approaches and what are the pros and cons that you have encountered with each approach. Are there any modules that you have found lend themselves better to each approach and therefore using a combination of both options is appropriate. eg: Are packages most suited where the problem domain being solved is well defined and extending the behavior for specific applications is unlikely to be required.

Thanks for your time and I look forward to your comments and advice.

by Alan >> Fri, 27 Jan 2006 7:49:54 GMT

Barry, some of my thoughts - for what they are worth.
Have only just started using packages (previously used a similar concept called peer schemas – I think packages just wrap them up nicely).
We are slowly implementing packages into an existing system. We have placed an Interface Schema over the CardSchema (distributed as part of Jade Start) to provide simple interface methods that wrapped up the card schema functionality, specifically for email and stack dumps – CardSchema was not in our schema hierarchy and it used to be very messy to insert new schemas after the fact. We then created the package from the interface schema which we imported into our existing schema structure.
We also have another package to perform generic application control and monitoring.
In the schema hierarchy we include functions and classes that you would commonly want to inherit – depending upon the nature of your system e.g. reporting, GUI, primitive methods, TCP connection re-implementations (to cater for specific remote applications), packages

by dcooper@jade.co.nz >> Sun, 29 Jan 2006 21:18:13 GMT

Packages are great to encapsulate reusable functionality that's best extended by aggregation rather than inheritance (you have a similar set of design considerations at the package/schema level as you do when thinking about inheritance vs aggregation at the class level). High-grain components/modules that are reusable across a number of scenarios without individual applications needing to subclass things to extend/customise them are ideal package candidates (as you pointed out). Keep in mind that with package classes, there is one set of map files (defined in the package schema) that is used by all applications that import the package. Often infrastructure components (eg: email, LDAP, file transfer, etc) are a good fit for packages because they tend to be more general in nature. If you think it will be common, better or easier for applications to extend the functionality via inheritance (eg: an application framework, a set of fine-grain GUI controls perhaps, etc) then encapsulating that in a superschema is probably best.

Dean.

PS: If you haven't already found it, have a look at the Packages White Paper at this page on the web site:

http://www.jadeworld.com/jade/whitepapers.htm

by Barry Williams >> Tue, 31 Jan 2006 8:02:18 GMT

Thanks to Alan and Dean for your thoughts and comments. It looks like a mixture of inheritance and packages is indeed the approach to take and that packages are better suited where there is unlikely to be any requirement to extend the behaviour for specific applications.