+1 Thank you Michael for the well thought proposal.
Jacopo On Sat, Feb 18, 2017 at 10:17 AM, Michael Brohl <michael.br...@ecomify.de> wrote: > 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 > > > >
