Difference between revisions of "The opentaps Way of Coding"
(New page: __TOC__ ==Why the opentaps Way of Coding== Writing code is easy. Maintaining that code through its entire lifecycle is much, much more complicated. We are always thinking of how to c...) |
|||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
| + | |||
| + | ''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== | ==Why the opentaps Way of Coding== | ||
| − | + | If you're reading this, you're probably either planning to customize [http://www.opentaps.org 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 [http://www.eclipse.org/ 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: | |
| − | + | * [[Base_Entity_Classes|Java Base Entities]], [[Java_Wrapper_for_OFBiz_Services|Java Service Wrappers]], and [[Java_Classes_for_Constants|Java Constants Classes]] which encapsulate the data model, available services, and constant values in Java classes that can be extended or overriden | |
| + | * [[Domain Driven Architecture]], which implements object-oriented domains on top of the data model with logical methods and services. | ||
| + | * [[POJO Service Engine]], which allows you to write true object-oriented Java classes and methods for the ofbiz service engine. | ||
| + | * [[Screen_Widget_Actions_in_Java|Java Screen Actions]], which allows you to write your user interface screens with Java methods instead of scripting languages. | ||
| + | |||
| + | Because all these enhancements are in Java, you will be able to use an IDE such as [http://www.eclipse.org Eclipse] to work with the data model, services, and constants. For example, | ||
| + | |||
| + | [[Image:Eclipse_opentaps_class.png|800px]] | ||
| + | |||
| + | Next, you should test your code. opentaps has an expanded [[Unit_Testing|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 [[Base_Entity_Classes|Java Base Entities]], [[Java_Wrapper_for_OFBiz_Services|Java Service Wrappers]], and [[Java_Classes_for_Constants|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 <tt>Double</tt> to <tt>BigDecimal</tt>, 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. | ||
Latest revision as of 17:57, 22 February 2011
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:
- Java Base Entities, Java Service Wrappers, and Java Constants Classes which encapsulate the data model, available services, and constant values in Java classes that can be extended or overriden
- Domain Driven Architecture, which implements object-oriented domains on top of the data model with logical methods and services.
- POJO Service Engine, which allows you to write true object-oriented Java classes and methods for the ofbiz service engine.
- Java Screen Actions, which allows you to write your user interface screens with Java methods instead of scripting languages.
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,
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.
