The opentaps Way of Coding

From Opentaps Wiki
Jump to navigationJump to search

One of the biggest challenges for implementing any enterprise software, such as ERP or CRM, is the need for customizations or enhancements. Virtually all ERP or CRM implementations require some customizations, and yet customizations are often difficult to implement and even harder to support through upgrade cycles. This is why we developed the opentaps Way of Coding, a set of technical tools and coding approaches to help you customize or extend opentaps more easily.

Why the opentaps Way of Coding

If you're reading this, you're probably either planning to customize opentaps Open Source ERP + CRM or build extensions with additional features for it.

Having done both many times, we've gradually developed a distinctly "opentaps Way of Coding" to help you do these things. Our goal is to make it easier for you to write your code with IDE's such as Eclipse and maintain your code through future versions of opentaps as they are released.

The opentaps Way follows these principles:

  • Write clean object-oriented code
  • Support your code with automated tests
  • Maintain your code with compile time checking
  • Separate your code cleanly versus existing opentaps code base

How It Works

First you need to write good, object-oriented code that's easy to understand and easy to manage and extend. To help you with this, we have implemented:

Because all these enhancements are in Java, you will be able to use an IDE such as Eclipse to work with the data model, services, and constants. For example,

Eclipse opentaps class.png

Next, you should test your code. opentaps has an expanded unit testing module which helps you write comprehensive tests for your features.

Together, these features help you maintain your code through different versions of opentaps. As the core code base changes, the Java Base Entities, Java Service Wrappers, and Java Constants Classes will change with them. If your code is written in Java and utilizes these artefacts, the Java compiler will immediately flag incompatibilities when you try to compile your code on top of future versions of opentaps. For example, if a field's type changes from Double to BigDecimal, or a field name changes, the Java compiler would catch it for you. This is much better than hunting through your code to fix the changes one by one.

Finally, with opentaps 1.5, it is now possible to create your own module completely outside of the core opentaps code base, even if they change the functionality of existing opentaps applications. This can be done by a combination of controller injection and re-defining the opentaps user interface in the database. See Customizing opentaps Applications for more details.