Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

Rationale

We are currently working hard to make OFBiz a modern, quality, robust and easy to use framework. There are several ongoing initiatives like refactoring the core, UX, changing the build and plugin system and cleaning up the javadocs, only to mention a few.

According to the proposal thread in [1], we decided to deprecate mini lang [2]. Here are some of the reasons:

  • Programming in XML is hard to deal with when it comes to refactoring.
  • The "code" cannot be debugged and is hard to review and maintain.
  • It is slower because of the overhead of parsing and processing XML documents
  • It is highly verbose, even so more than Java!
  • It is difficult to reason about because everything appears as a string (variables, maps, objects, etc ...) which makes it very difficult to know where something was declared or modified
  • It is highly error prone and brittle (again due to string declarations)
  • It is not a full programming language (unlike groovy, or any other language that supports a DSL). Thus it has many limitations that forces the developer to write many more lines of code to achieve the same result.
  • The code is not reusable (limitation of the DSL)
  • The code is not composable (limitation of the DSL)
  • Minilang depends on a lot of Java constructs (implementations, not interfaces) that require refactoring, making any improvements to the core API more challenging
  • Minilang is used inconsistently (different DSL in widgets, services and entities). Hence, we need to keep only a minimal DSL to declare things only.

 

We already have Java based implementations for services and events and there are ideas to implement a Groovy DSL [3] which can be used as a replacement for mini lang and does not have the above mentioned flaws.

One important thing we should not forget when replacing minilang is its ability to work without recompiling on changes. So for instance when replacing minilang services, and in general when writing small services, it's better to use Groovy (than eg Java). It makes quite a difference when you want to develop fast.
Note though that, if you don't enforce type using the def keyword, Groovy is less reliable than Java because Groovy is optionnaly typed, when Java which is type safe. Also, at least at the moment, it's harder to refactor because, for the same reason, there are less or even no tools in IDEs.

Impact of mini lang deprecation

Deprecation of mini lang means:

  1. there will be no new implementations based on mini lang accepted to go into the code base (as of April 2017).
  2. mini lang and mini lang code will be maintained with bug and security fixes for backwards compatibility and to support existing adopters relying on mini lang. There will be no new features though.
  3. we will continously replace the mini lang implementations with Java and/or Groovy code. This will be another good opportunity for contributors to engage in the project.

Issue tracking

The efforts for the mini lang deprecation are tracked in Unable to render Jira issues macro, execution error. .

Steps to deprecate mini lang in the code base

TODO

 

 


[1] https://lists.apache.org/thread.html/253b41060a295b8ab68bc78763cc129fc74b712cf776f8716022097f@%3Cdev.ofbiz.apache.org%3E
[2] https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference
[3] https://cwiki.apache.org/confluence/display/OFBIZ/Groovy+DSL+for+OFBiz+business+logic

  • No labels