I am inclined to say +1. But I see some concerns rising (with respect to some suggestions) with new additions, e.g:
1. No more simple (entity-auto) services, ecas and secas in xml? Or only no more complex ones? Do we opt for Java, Groovy, or leave that to the discretion of each contributor? 2. No more screen, form and grid definitions, but instead everything in Freemarker? Or something else? 3. No more ofbiz-component.xml, *Data.xml and *Label.xml? Into what do we want these be refactored? As implied elsewhere in this thread this refactoring will take a serious amount of effort. Without a plan (probably a SMART one) this can go in any direction (from just 'it is only a wish' to halted contributions). Clarity up front will speed up conversion down the line. Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Sat, Feb 18, 2017 at 12:16 PM, Paul Foxworthy <p...@cohsoft.com.au> wrote: > +1 > > I have wondered how hard it would be to create an isomorphic conversion > between minilang and a Groovy DSL - bidirectional conversion between the > two. That would mean we could automatically convert the existing minilang > to the DSL, and if there is anyone who prefers minilang, they could convert > in the other direction. > > There would even be benefits if we just worked on generating an Abstract > Syntax Tree from minilang, which is then compiled to bytecode. That would > increase the performance of minilang code, and perhaps allow for debugging > it. It might be possible to verify that replacement DSL was doing the same > thing as existing minilang by comparing the ASTs (before we start > refactoring!). > > Cheers > > Paul Foxworthy > > > > On 18 February 2017 at 21:45, Jacques Le Roux < > jacques.le.r...@les7arts.com> > wrote: > > > I agree with both of you. > > > > The recent FinAccount deadlock issue reported on dev ML is one example of > > the type of issues which would be easier to deal with with a Turing > > complete language or at least a better DSL. > > > > My 2 cts > > > > Jacques > > > > > > > > > > Le 18/02/2017 à 10:25, Taher Alkhateeb a écrit : > > > >> +1 > >> > >> let's maintain but not add more to the pile, and try to replace > everything > >> written in minilang with other languages over time. I think your > arguments > >> and proposal are well founded and would really improve the health of > this > >> project. > >> > >> On Feb 18, 2017 12:17 PM, "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 > >>> > >>> > >>> > >>> > >>> > > > > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: i...@coherentsoftware.com.au >
