Substring method for minilang?

[cjhowe]

--- Jacques Le Roux <[hidden email]> wrote:

>
> > 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.
>

The minilang model was done really well, and allows this kind of change
to take place over time and not need to be done all at once.  If you
initially have the java support both ways and just remove the map-name
attribute from the xsd, over time as people get tired of the parser
complaining, it gets upgraded.  This assuming of course there isn't an
ongoing technical justification for separating the field from the map.

[jonwimp]

 > +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
>>>> [hidden email]
>>>> 214-720-0700 x 315
>>>> Brainfood, Inc.
>>>> http://www.brainfood.com
>
>

[Jacques Le Roux]

I agree with Chris and Jonathon that this is not a major issue (if an
issue at all). And of course yes deprecate something does not mean
removing it.

Jacques

----- Message d'origine -----
De : "Jonathon -- Improov" <[hidden email]>
À : <[hidden email]>
Envoyé : jeudi 7 juin 2007 09:44
Objet : Re: Substring method for minilang?


> > +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
> >>>> [hidden email]
> >>>> 214-720-0700 x 315
> >>>> Brainfood, Inc.
> >>>> http://www.brainfood.com
> >
> >

[Ean Schuessler]

On Thursday 07 June 2007 01:20:23 am 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).

How do you get fine-grained exception handling without try/catch?

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

Well, I guess the moral of the story is that there are different strokes for
different folks!

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

[jonwimp]

Ean,

 > How do you get fine-grained exception handling without try/catch?

With Minilang, you don't. Just do some pre-checks of incoming data (for CRUD operations). Often,
checking incoming data in a consolidated "pre" section can be neater than throwing it all into a
"try" block.

I think most/all CRUD operations are straightforward, and don't require complex try-catch blocks.

Jonathon

Ean Schuessler wrote:

> On Thursday 07 June 2007 01:20:23 am 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).
>
> How do you get fine-grained exception handling without try/catch?
>
>> This said, I agree that Groovy is for sure very interesting...
>
> Well, I guess the moral of the story is that there are different strokes for
> different folks!
>

[Ean Schuessler]

On Monday 11 June 2007 11:54:25 pm Jonathon -- Improov wrote:
> With Minilang, you don't. Just do some pre-checks of incoming data (for
> CRUD operations). Often, checking incoming data in a consolidated "pre"
> section can be neater than throwing it all into a "try" block.

You can certainly write pre-check intensive code without try/catch blocks in
most any language. The point with exceptions is that some things can't be
checked in advance (ie. IOException).

> I think most/all CRUD operations are straightforward, and don't require
> complex try-catch blocks.

That is an optimistic outlook. :-)

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

[jonwimp]

I use Minilang mostly to deal with incoming parameters from http requests. I would think that any
issues with reading those parameters would've been centrally and conveniently handled at the
"Webapp" engine. If not, they should.

Even reading uploaded temporary files can be pre-checked by the underlying OFBiz engine.

Sanitizing of incoming parameters is a common design pattern meant to simplify codes further
downstream. It's like "Quality Control" (QC), making it easier for me to plug a harddisk into my
computer without first checking for exceptional circuitry in the harddisk that might feedback
harmful currents into my computer.

Also like how you can easily "assert" (assume) that I can read English, and not have to consider
the exceptional case that I might come from Mars. :) (Do they speak English?).

Jonathon

Ean Schuessler wrote:

> On Monday 11 June 2007 11:54:25 pm Jonathon -- Improov wrote:
>> With Minilang, you don't. Just do some pre-checks of incoming data (for
>> CRUD operations). Often, checking incoming data in a consolidated "pre"
>> section can be neater than throwing it all into a "try" block.
>
> You can certainly write pre-check intensive code without try/catch blocks in
> most any language. The point with exceptions is that some things can't be
> checked in advance (ie. IOException).
>
>> I think most/all CRUD operations are straightforward, and don't require
>> complex try-catch blocks.
>
> That is an optimistic outlook. :-)
>

[Ean Schuessler]

On Tuesday 12 June 2007 06:46:40 pm Jonathon -- Improov wrote:

> I use Minilang mostly to deal with incoming parameters from http requests.
> I would think that any issues with reading those parameters would've been
> centrally and conveniently handled at the "Webapp" engine. If not, they
> should.
>
> Even reading uploaded temporary files can be pre-checked by the underlying
> OFBiz engine.
>
> Sanitizing of incoming parameters is a common design pattern meant to
> simplify codes further downstream. It's like "Quality Control" (QC), making
> it easier for me to plug a harddisk into my computer without first checking
> for exceptional circuitry in the harddisk that might feedback harmful
> currents into my computer.
>
> Also like how you can easily "assert" (assume) that I can read English, and
> not have to consider the exceptional case that I might come from Mars. :)
> (Do they speak English?).

If the point of Minilang is to provide an orchestration and sequencing
definition that does not touch on programming intrinsics then we should
consider BPEL. The diagramming approach really opens the process to
non-technical stakeholders who have deep domain knowledge.

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

[jonwimp]

I think the point of Minilang is simply to make development faster. At least that's how I use it.
Whatever works. :)

Perhaps Minilang is a hybrid, somewhere between hardcore programming and BPEL? If Minilang evolves
into BPEL, so be it. I'll use it as long as it is easy and quick to cook. For now, it's
intrinsically tied to OFBiz framework, and very little work (zero) is needed to tie Minilang into
OFBiz.

BPEL has exception handling, doesn't it?

Jonathon

Ean Schuessler wrote:

> On Tuesday 12 June 2007 06:46:40 pm Jonathon -- Improov wrote:
>> I use Minilang mostly to deal with incoming parameters from http requests.
>> I would think that any issues with reading those parameters would've been
>> centrally and conveniently handled at the "Webapp" engine. If not, they
>> should.
>>
>> Even reading uploaded temporary files can be pre-checked by the underlying
>> OFBiz engine.
>>
>> Sanitizing of incoming parameters is a common design pattern meant to
>> simplify codes further downstream. It's like "Quality Control" (QC), making
>> it easier for me to plug a harddisk into my computer without first checking
>> for exceptional circuitry in the harddisk that might feedback harmful
>> currents into my computer.
>>
>> Also like how you can easily "assert" (assume) that I can read English, and
>> not have to consider the exceptional case that I might come from Mars. :)
>> (Do they speak English?).
>
> If the point of Minilang is to provide an orchestration and sequencing
> definition that does not touch on programming intrinsics then we should
> consider BPEL. The diagramming approach really opens the process to
> non-technical stakeholders who have deep domain knowledge.
>

[David E Jones]

Ean Schuessler wrote:

> On Tuesday 12 June 2007 06:46:40 pm Jonathon -- Improov wrote:
>> I use Minilang mostly to deal with incoming parameters from http requests.
>> I would think that any issues with reading those parameters would've been
>> centrally and conveniently handled at the "Webapp" engine. If not, they
>> should.
>>
>> Even reading uploaded temporary files can be pre-checked by the underlying
>> OFBiz engine.
>>
>> Sanitizing of incoming parameters is a common design pattern meant to
>> simplify codes further downstream. It's like "Quality Control" (QC), making
>> it easier for me to plug a harddisk into my computer without first checking
>> for exceptional circuitry in the harddisk that might feedback harmful
>> currents into my computer.
>>
>> Also like how you can easily "assert" (assume) that I can read English, and
>> not have to consider the exceptional case that I might come from Mars. :)
>> (Do they speak English?).
>
> If the point of Minilang is to provide an orchestration and sequencing
> definition that does not touch on programming intrinsics then we should
> consider BPEL. The diagramming approach really opens the process to
> non-technical stakeholders who have deep domain knowledge.

BPEL may be a valuable add-on to OFBiz, but it is really more similar to the Service ECA rules than to the simple-method. The simple-method is meant for moving around data (mapping, validating, going to/from services and entities, etc).

-David