Re: [PROPOSAL] deprecate mini lang

[Michael Brohl]

Hi Pierre,




Regards,

Michael


Am 18.02.17 um 13:12 schrieb Pierre Smits:

my proposal was to deprecate mini lang, not to drop xml based definitions and configurations as a whole.

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

smime.p7s
Description: S/MIME Cryptographic Signature