+1
On 27/02/2017 13:44, Nicolas Malin wrote:
+1
I also agree to replace the minilang by groovy dsl for service.
For screen a prefer wait a good equivalent solution for simple case.
Nicolas
Le 18/02/2017 à 10:17, Michael Brohl a écrit :
Hi everyone,
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.
In mini lang I see another part of our project which needs a
refactoring/change. Here are some 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 which can be used as
easy (or easier) as mini lang and does not have the above mentioned
flaws.
I therefore like to propose to deprecate the mini lang implementation
which means:
1. there will be no new implementations based on mini lang accepted
to go into the code base.
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.
This will certainly be a longer process and we will not stop support
for mini lang but I think we should avoid to add more mini lang
implementations to the project.
What do you think?
Regards,
Michael
