> 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)
+1, I get caught with this one yesterday :o)
> 2) we should deprecate the usage of map-name attributes and use
instead
> the field="mapName.fieldName" syntax
+1, but large work if we want to change all existing tag in code.
> 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"/>
+1 for the example at least
> 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"
Did not use it much for now, but yes why not...
> 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
Yes totally agree about good productivity with this tools. For instance,
yesterday I just added some fields in the ProdcutStore entity (in the
right place for order of fields to not have to change the form using
sort-order) and I was done, what can compete here ? ;o)
Jacques
> 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
