I really like Minilang too.
It's true that the syntax of each single operation is not concise, but the end results, i.e. the whole methods/services, are incredibly compact. And the best thing is that you write down a service in Minilang in the same exact way as you describe it in English language. However theree are a few areas where Minilang could be improved, in my opinion:

1) consolidation of similar operations; for example <if>, <if-compare> and <if-compare-field> could be probably unified to one (a similar effort was done with the <set/> operation) 2) we should deprecate the usage of map-name attributes and use instead the field="mapName.fieldName" syntax 3) the naming conventions for attributes is not always the same: for example "field-name" and "field" (and sometimes "value-name" or "env-name", even if I know they are slightly different concepts) are used to reference similar objects in different operations; I'd prefer to always use everywhere the "field" and "from-field"/"value" attributes everywhere, foe example: instead of <store-value value-name="product"/>, I'd prefer <store-value field="product"/> 4) math operations in Minilang are a bit complex to write/read: it would be great to have something like "fieldA * (fieldB + fieldC) - 3.0"

This is my wish list for this great tool that, together with Menu/Screen/Form widgets, can greatly improve your efficiency in the development/customization of OFBiz

Jacopo


Jacques Le Roux wrote:
It took me some time to got used to Minilang but now I really like it.
Not having to deal with try/catch is one of the feature I like (will
Groovy be able to do such thing ?). Be able to easily deal with the
entity engine is really pleaseant too. Using an XML editor with syntax
completion you do not have to type too much characters (and you can
enjoy copy/paste as everywhere).

Once you get acquainted to it, I believe Minilang is the right tool in
the right place.

This said, I agree that Groovy is for sure very interesting...

Jacques

PS : Jonathon has explained why he likes the map-processor. I agree, I
just wonder if there is a way to use it the other way around when you
copy fields from a map to another. Is there a way to copy all but some ?
Sort of exclude tag. I wonder why this does not exist. I miss something
here ?


On Wednesday 06 June 2007 10:51:28 pm David E Jones wrote:
Alternatively Ean, and maybe even better: in an ideal world what
would you
use in place of the MiniLang/simple-method code (regardless of
whether or
not it exists already)?

As we've done in the past, if there is anything that represents a
sufficient efficiency gain for development and maintenance it may
very well
be worth the transition to it.
Wellll....

I don't like the XML approach because the code is difficult to read
and it
makes me type a lot of characters that have no syntactic meaning when
I
presume Minilang is intended to reduce typing. I also assume (or have
heard)
that using XML simplifies parsing and generation so that a GUI based
tool
could be built on top of it. I accept that idea but note that pretty
much any
major language built on the Java VM generates some sort of the AST and
outputting that tree to an XML format would be pretty trivial. I also
note
that we do not have such a case tool and wonder if we really want to
duel
with something like BPEL (I vote no).

I think that most of the scripting conveniences afforded by MiniLang
can be
achieved more thoroughly by one of the many scripting languages
available for
the JVM. My personal choice would be Groovy because it offers the same
conveniences touted by other dynamic languages and its Map syntactic
sugar
directly supports native Java Maps. This feature should not be
underestimated
because it is suprsingly absent from both Jython and JRuby and is
very, very
useful:

delegator.findByPrimaryKey("UserLogin", ["userLoginId": "admin"])
person.firstName = "Ean"
address.putAll([address1: "1000 Smith St.", stateProvinceGeoId: "TX",
postalCode: "75226"]);
...etc...

More than once I've thought about XSLT that produces Groovy from
Minilang.
Regex sugar, closures, dynamic typing and tree builders all are
tremendous
conveniences. Operator overloading also implies certain guilty
pleasures that
are best not discussed on this public list. Plus Groovy compiles to
native
bytecode and is already supported by a JSR.

Plus we'd get lots of marketing cheese out of a move like that.

I also wonder if we shouldn't wrap the dispatcher in a proxy and do
things
like:

me = [:]
me.firstName = "Ean"
me.lastName = "Schuessler"
dispatcher.createPerson(me)

That's my .02 anyway.

--
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Reply via email to