> +1, but large work if we want to change all existing tag in code.
I suggest we simply deprecate the attribute, and add a new one.
And when do we remove the attribute? I don't know. To be lazy about it, never, until we need to
add a new attribute that happens to have the same name as the deprecated attribute. Ie, until we
need to actually remove the deprecated attribute to make way for a new one.
Or until we have built a "migration tool" that automatically converts all tags to use the new
attribute. This isn't tough to do, just a matter of regexp replace work.
Jonathon
Jacques Le Roux wrote:
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
