Substring method for minilang?

[byersa]

I cannot figure out how to safely get a substring value in minilang. I don't
even see an OFBiz utility for doing it. The String method will blow up if
the cutoff value is greater than the length of the string, so it seems like
I need to do a bunch of String and Math functions to get it and I am
wondering if we need a safe substring method in minilang (and widget for
that matter).

I will be glad to add it if it looks like it is needed.

-Al

[cjhowe]

remember that simple methods have the method <call-class-method> so
that you can call any method that exists in java, just be sure to use
type that is part of the method signature, not a subtype.  As far as
adding the function more natively, if necessary, it might be best as
one of the map processor functions.

--- Al Byers <[hidden email]> wrote:

> I cannot figure out how to safely get a substring value in minilang.
> I don't
> even see an OFBiz utility for doing it. The String method will blow
> up if
> the cutoff value is greater than the length of the string, so it
> seems like
> I need to do a bunch of String and Math functions to get it and I am
> wondering if we need a safe substring method in minilang (and widget
> for
> that matter).
>
> I will be glad to add it if it looks like it is needed.
>
> -Al
>

[byersa]

Thanks Chris,

I was aware of the "call" methods, but here is the code that I wrote in
order to get the first x characters of the text body to use as a
description:

        <call-object-method method-name="length" obj-field-name="
parameters.textData" ret-field-name="textDataLen"/>
        <log level="info" message="textDataLen:${textDataLen}"/>
        <property-to-field resource="forum" property="descriptLen"
field-name="descriptLen" />
        <log level="info" message="descriptLen:${descriptLen}"/>
        <set field="dblTextDataLen" from-field="textDataLen" type="Double"/>
        <set field="dblDescriptLen" from-field="descriptLen" type="Double"/>
        <call-class-method method-name="min" class-name="java.lang.Math"
ret-field-name="subStringLen">
            <field field-name="dblTextDataLen" type="double"/>
            <field field-name="dblDescriptLen" type="double"/>
        </call-class-method>
        <set field="intSubStringLen" from-field="subStringLen"
type="Integer"/>
        <log level="info" message="subStringLen:${subStringLen}"/>
        <set field="zeroValue" value="0" type="Integer"/>
        <call-object-method method-name="substring" obj-field-name="
parameters.textData" ret-field-name="subDescript">
            <field field-name="zeroValue" type="int"/>
            <field field-name="intSubStringLen" type="int"/>
        </call-object-method>
        <log level="info" message="subDescript:${subDescript}"/>

As you can see there is a lot of code just to get the variables into the
right type for calling the class and object methods. Does anyone see a
better way to do this?

I agree that it would make sense to put any added functionality in the map
processor, but then you have to create a file ( don't you? ) just to do one
little thing.

Thanks,

-Al

On 6/4/07, Chris Howe <[hidden email]> wrote:

>
> remember that simple methods have the method <call-class-method> so
> that you can call any method that exists in java, just be sure to use
> type that is part of the method signature, not a subtype.  As far as
> adding the function more natively, if necessary, it might be best as
> one of the map processor functions.
>
> --- Al Byers <[hidden email]> wrote:
>
> > I cannot figure out how to safely get a substring value in minilang.
> > I don't
> > even see an OFBiz utility for doing it. The String method will blow
> > up if
> > the cutoff value is greater than the length of the string, so it
> > seems like
> > I need to do a bunch of String and Math functions to get it and I am
> > wondering if we need a safe substring method in minilang (and widget
> > for
> > that matter).
> >
> > I will be glad to add it if it looks like it is needed.
> >
> > -Al
> >
>
>

[Jacques Le Roux]

Al,

De : "Al Byers" <[hidden email]>
> Thanks Chris,
>
> I was aware of the "call" methods, but here is the code that I wrote
in

> order to get the first x characters of the text body to use as a
> description:
>
>         <call-object-method method-name="length" obj-field-name="
> parameters.textData" ret-field-name="textDataLen"/>
>         <log level="info" message="textDataLen:${textDataLen}"/>
>         <property-to-field resource="forum" property="descriptLen"
> field-name="descriptLen" />
>         <log level="info" message="descriptLen:${descriptLen}"/>
>         <set field="dblTextDataLen" from-field="textDataLen"

type="Double"/>
>         <set field="dblDescriptLen" from-field="descriptLen"
type="Double"/>
>         <call-class-method method-name="min"
class-name="java.lang.Math"

> ret-field-name="subStringLen">
>             <field field-name="dblTextDataLen" type="double"/>
>             <field field-name="dblDescriptLen" type="double"/>
>         </call-class-method>
>         <set field="intSubStringLen" from-field="subStringLen"
> type="Integer"/>
>         <log level="info" message="subStringLen:${subStringLen}"/>
>         <set field="zeroValue" value="0" type="Integer"/>
>         <call-object-method method-name="substring" obj-field-name="
> parameters.textData" ret-field-name="subDescript">
>             <field field-name="zeroValue" type="int"/>
>             <field field-name="intSubStringLen" type="int"/>
>         </call-object-method>
>         <log level="info" message="subDescript:${subDescript}"/>
>
> As you can see there is a lot of code just to get the variables into

the
> right type for calling the class and object methods. Does anyone see a
> better way to do this?
>
> I agree that it would make sense to put any added functionality in the
map
> processor, but then you have to create a file ( don't you? ) just to
do one
> little thing.

You'd not need to create a file if you were using simple-map-processor
inside of a call-map-processor

Jacques

> Thanks,
>
> -Al
>
> On 6/4/07, Chris Howe <[hidden email]> wrote:
> >
> > remember that simple methods have the method <call-class-method> so
> > that you can call any method that exists in java, just be sure to
use
> > type that is part of the method signature, not a subtype.  As far as
> > adding the function more natively, if necessary, it might be best as
> > one of the map processor functions.
> >
> > --- Al Byers <[hidden email]> wrote:
> >
> > > I cannot figure out how to safely get a substring value in
minilang.
> > > I don't
> > > even see an OFBiz utility for doing it. The String method will
blow
> > > up if
> > > the cutoff value is greater than the length of the string, so it
> > > seems like
> > > I need to do a bunch of String and Math functions to get it and I
am
> > > wondering if we need a safe substring method in minilang (and
widget

> > > for
> > > that matter).
> > >
> > > I will be glad to add it if it looks like it is needed.
> > >
> > > -Al
> > >
> >
> >
>

[cjhowe]

I'm having trouble quickly reading how you're hacking it to work versus
what you're trying to do...

What are you trying to perform if this were java?

--- Al Byers <[hidden email]> wrote:

> Thanks Chris,
>
> I was aware of the "call" methods, but here is the code that I wrote
> in
> order to get the first x characters of the text body to use as a
> description:
>
>         <call-object-method method-name="length" obj-field-name="
> parameters.textData" ret-field-name="textDataLen"/>
>         <log level="info" message="textDataLen:${textDataLen}"/>
>         <property-to-field resource="forum" property="descriptLen"
> field-name="descriptLen" />
>         <log level="info" message="descriptLen:${descriptLen}"/>
>         <set field="dblTextDataLen" from-field="textDataLen"
> type="Double"/>
>         <set field="dblDescriptLen" from-field="descriptLen"
> type="Double"/>
>         <call-class-method method-name="min"
> class-name="java.lang.Math"
> ret-field-name="subStringLen">
>             <field field-name="dblTextDataLen" type="double"/>
>             <field field-name="dblDescriptLen" type="double"/>
>         </call-class-method>
>         <set field="intSubStringLen" from-field="subStringLen"
> type="Integer"/>
>         <log level="info" message="subStringLen:${subStringLen}"/>
>         <set field="zeroValue" value="0" type="Integer"/>
>         <call-object-method method-name="substring" obj-field-name="
> parameters.textData" ret-field-name="subDescript">
>             <field field-name="zeroValue" type="int"/>
>             <field field-name="intSubStringLen" type="int"/>
>         </call-object-method>
>         <log level="info" message="subDescript:${subDescript}"/>
>
> As you can see there is a lot of code just to get the variables into
> the
> right type for calling the class and object methods. Does anyone see
> a
> better way to do this?
>
> I agree that it would make sense to put any added functionality in
> the map
> processor, but then you have to create a file ( don't you? ) just to
> do one
> little thing.
>
> Thanks,
>
> -Al
>
> On 6/4/07, Chris Howe <[hidden email]> wrote:
> >
> > remember that simple methods have the method <call-class-method> so
> > that you can call any method that exists in java, just be sure to
> use
> > type that is part of the method signature, not a subtype.  As far
> as
> > adding the function more natively, if necessary, it might be best
> as
> > one of the map processor functions.
> >
> > --- Al Byers <[hidden email]> wrote:
> >
> > > I cannot figure out how to safely get a substring value in
> minilang.
> > > I don't
> > > even see an OFBiz utility for doing it. The String method will
> blow
> > > up if
> > > the cutoff value is greater than the length of the string, so it
> > > seems like
> > > I need to do a bunch of String and Math functions to get it and I
> am
> > > wondering if we need a safe substring method in minilang (and
> widget
> > > for
> > > that matter).
> > >
> > > I will be glad to add it if it looks like it is needed.
> > >
> > > -Al
> > >
> >
> >
>

[byersa]

I just want to get the first <x> characters in a text string (which may be
shorter than <x>). Ideally, I want to break at a whitespace - more reason
for writing a special function.

I suppose I can just write a service to do it. I was trying to determine if
this (and maybe other string processing) should be added to the minilang and
widget functionality.

-Al

On 6/4/07, Chris Howe <[hidden email]> wrote:

>
> I'm having trouble quickly reading how you're hacking it to work versus
> what you're trying to do...
>
> What are you trying to perform if this were java?
>
> --- Al Byers <[hidden email]> wrote:
>
> > Thanks Chris,
> >
> > I was aware of the "call" methods, but here is the code that I wrote
> > in
> > order to get the first x characters of the text body to use as a
> > description:
> >
> >         <call-object-method method-name="length" obj-field-name="
> > parameters.textData" ret-field-name="textDataLen"/>
> >         <log level="info" message="textDataLen:${textDataLen}"/>
> >         <property-to-field resource="forum" property="descriptLen"
> > field-name="descriptLen" />
> >         <log level="info" message="descriptLen:${descriptLen}"/>
> >         <set field="dblTextDataLen" from-field="textDataLen"
> > type="Double"/>
> >         <set field="dblDescriptLen" from-field="descriptLen"
> > type="Double"/>
> >         <call-class-method method-name="min"
> > class-name="java.lang.Math"
> > ret-field-name="subStringLen">
> >             <field field-name="dblTextDataLen" type="double"/>
> >             <field field-name="dblDescriptLen" type="double"/>
> >         </call-class-method>
> >         <set field="intSubStringLen" from-field="subStringLen"
> > type="Integer"/>
> >         <log level="info" message="subStringLen:${subStringLen}"/>
> >         <set field="zeroValue" value="0" type="Integer"/>
> >         <call-object-method method-name="substring" obj-field-name="
> > parameters.textData" ret-field-name="subDescript">
> >             <field field-name="zeroValue" type="int"/>
> >             <field field-name="intSubStringLen" type="int"/>
> >         </call-object-method>
> >         <log level="info" message="subDescript:${subDescript}"/>
> >
> > As you can see there is a lot of code just to get the variables into
> > the
> > right type for calling the class and object methods. Does anyone see
> > a
> > better way to do this?
> >
> > I agree that it would make sense to put any added functionality in
> > the map
> > processor, but then you have to create a file ( don't you? ) just to
> > do one
> > little thing.
> >
> > Thanks,
> >
> > -Al
> >
> > On 6/4/07, Chris Howe <[hidden email]> wrote:
> > >
> > > remember that simple methods have the method <call-class-method> so
> > > that you can call any method that exists in java, just be sure to
> > use
> > > type that is part of the method signature, not a subtype.  As far
> > as
> > > adding the function more natively, if necessary, it might be best
> > as
> > > one of the map processor functions.
> > >
> > > --- Al Byers <[hidden email]> wrote:
> > >
> > > > I cannot figure out how to safely get a substring value in
> > minilang.
> > > > I don't
> > > > even see an OFBiz utility for doing it. The String method will
> > blow
> > > > up if
> > > > the cutoff value is greater than the length of the string, so it
> > > > seems like
> > > > I need to do a bunch of String and Math functions to get it and I
> > am
> > > > wondering if we need a safe substring method in minilang (and
> > widget
> > > > for
> > > > that matter).
> > > >
> > > > I will be glad to add it if it looks like it is needed.
> > > >
> > > > -Al
> > > >
> > >
> > >
> >
>
>

[cjhowe]

I wouldn't bother with the service engine, but instead add a method to
base.util.StringUtil

That seems to be a safe tool that would be beneficial in other places..

--- Al Byers <[hidden email]> wrote:

> I just want to get the first <x> characters in a text string (which
> may be
> shorter than <x>). Ideally, I want to break at a whitespace - more
> reason
> for writing a special function.
>
> I suppose I can just write a service to do it. I was trying to
> determine if
> this (and maybe other string processing) should be added to the
> minilang and
> widget functionality.
>
> -Al
>
> On 6/4/07, Chris Howe <[hidden email]> wrote:
> >
> > I'm having trouble quickly reading how you're hacking it to work
> versus
> > what you're trying to do...
> >
> > What are you trying to perform if this were java?
> >
> > --- Al Byers <[hidden email]> wrote:
> >
> > > Thanks Chris,
> > >
> > > I was aware of the "call" methods, but here is the code that I
> wrote
> > > in
> > > order to get the first x characters of the text body to use as a
> > > description:
> > >
> > >         <call-object-method method-name="length" obj-field-name="
> > > parameters.textData" ret-field-name="textDataLen"/>
> > >         <log level="info" message="textDataLen:${textDataLen}"/>
> > >         <property-to-field resource="forum"
> property="descriptLen"
> > > field-name="descriptLen" />
> > >         <log level="info" message="descriptLen:${descriptLen}"/>
> > >         <set field="dblTextDataLen" from-field="textDataLen"
> > > type="Double"/>
> > >         <set field="dblDescriptLen" from-field="descriptLen"
> > > type="Double"/>
> > >         <call-class-method method-name="min"
> > > class-name="java.lang.Math"
> > > ret-field-name="subStringLen">
> > >             <field field-name="dblTextDataLen" type="double"/>
> > >             <field field-name="dblDescriptLen" type="double"/>
> > >         </call-class-method>
> > >         <set field="intSubStringLen" from-field="subStringLen"
> > > type="Integer"/>
> > >         <log level="info"
> message="subStringLen:${subStringLen}"/>
> > >         <set field="zeroValue" value="0" type="Integer"/>
> > >         <call-object-method method-name="substring"
> obj-field-name="
> > > parameters.textData" ret-field-name="subDescript">
> > >             <field field-name="zeroValue" type="int"/>
> > >             <field field-name="intSubStringLen" type="int"/>
> > >         </call-object-method>
> > >         <log level="info" message="subDescript:${subDescript}"/>
> > >
> > > As you can see there is a lot of code just to get the variables
> into
> > > the
> > > right type for calling the class and object methods. Does anyone
> see
> > > a
> > > better way to do this?
> > >
> > > I agree that it would make sense to put any added functionality
> in
> > > the map
> > > processor, but then you have to create a file ( don't you? ) just
> to
> > > do one
> > > little thing.
> > >
> > > Thanks,
> > >
> > > -Al
> > >
> > > On 6/4/07, Chris Howe <[hidden email]> wrote:
> > > >
> > > > remember that simple methods have the method
> <call-class-method> so
> > > > that you can call any method that exists in java, just be sure
> to
> > > use
> > > > type that is part of the method signature, not a subtype.  As
> far
> > > as
> > > > adding the function more natively, if necessary, it might be
> best
> > > as
> > > > one of the map processor functions.
> > > >
> > > > --- Al Byers <[hidden email]> wrote:
> > > >
> > > > > I cannot figure out how to safely get a substring value in
> > > minilang.
> > > > > I don't
> > > > > even see an OFBiz utility for doing it. The String method
> will
> > > blow
> > > > > up if
> > > > > the cutoff value is greater than the length of the string, so
> it
> > > > > seems like
> > > > > I need to do a bunch of String and Math functions to get it
> and I
> > > am
> > > > > wondering if we need a safe substring method in minilang (and
> > > widget
> > > > > for
> > > > > that matter).
> > > > >
> > > > > I will be glad to add it if it looks like it is needed.
> > > > >
> > > > > -Al
> > > > >
> > > >
> > > >
> > >
> >
> >
>

[jonwimp]

Al,

A bit OT, but I thought you might want to know that I've created in Minilang a
<call-simple-method-scoped> that allows you to call simple methods as reentrant functions.

Without <call-simple-method-scoped>, about the only way to do reentrant functions in Minilang was
to use services.

But note that <call-simple-method-scoped> does not have the parameters (IN/OUT) checking that the
Service Engine provides.

Jonathon

Al Byers wrote:

> I just want to get the first <x> characters in a text string (which may be
> shorter than <x>). Ideally, I want to break at a whitespace - more reason
> for writing a special function.
>
> I suppose I can just write a service to do it. I was trying to determine if
> this (and maybe other string processing) should be added to the minilang
> and
> widget functionality.
>
> -Al
>
> On 6/4/07, Chris Howe <[hidden email]> wrote:
>>
>> I'm having trouble quickly reading how you're hacking it to work versus
>> what you're trying to do...
>>
>> What are you trying to perform if this were java?
>>
>> --- Al Byers <[hidden email]> wrote:
>>
>> > Thanks Chris,
>> >
>> > I was aware of the "call" methods, but here is the code that I wrote
>> > in
>> > order to get the first x characters of the text body to use as a
>> > description:
>> >
>> >         <call-object-method method-name="length" obj-field-name="
>> > parameters.textData" ret-field-name="textDataLen"/>
>> >         <log level="info" message="textDataLen:${textDataLen}"/>
>> >         <property-to-field resource="forum" property="descriptLen"
>> > field-name="descriptLen" />
>> >         <log level="info" message="descriptLen:${descriptLen}"/>
>> >         <set field="dblTextDataLen" from-field="textDataLen"
>> > type="Double"/>
>> >         <set field="dblDescriptLen" from-field="descriptLen"
>> > type="Double"/>
>> >         <call-class-method method-name="min"
>> > class-name="java.lang.Math"
>> > ret-field-name="subStringLen">
>> >             <field field-name="dblTextDataLen" type="double"/>
>> >             <field field-name="dblDescriptLen" type="double"/>
>> >         </call-class-method>
>> >         <set field="intSubStringLen" from-field="subStringLen"
>> > type="Integer"/>
>> >         <log level="info" message="subStringLen:${subStringLen}"/>
>> >         <set field="zeroValue" value="0" type="Integer"/>
>> >         <call-object-method method-name="substring" obj-field-name="
>> > parameters.textData" ret-field-name="subDescript">
>> >             <field field-name="zeroValue" type="int"/>
>> >             <field field-name="intSubStringLen" type="int"/>
>> >         </call-object-method>
>> >         <log level="info" message="subDescript:${subDescript}"/>
>> >
>> > As you can see there is a lot of code just to get the variables into
>> > the
>> > right type for calling the class and object methods. Does anyone see
>> > a
>> > better way to do this?
>> >
>> > I agree that it would make sense to put any added functionality in
>> > the map
>> > processor, but then you have to create a file ( don't you? ) just to
>> > do one
>> > little thing.
>> >
>> > Thanks,
>> >
>> > -Al
>> >
>> > On 6/4/07, Chris Howe <[hidden email]> wrote:
>> > >
>> > > remember that simple methods have the method <call-class-method> so
>> > > that you can call any method that exists in java, just be sure to
>> > use
>> > > type that is part of the method signature, not a subtype.  As far
>> > as
>> > > adding the function more natively, if necessary, it might be best
>> > as
>> > > one of the map processor functions.
>> > >
>> > > --- Al Byers <[hidden email]> wrote:
>> > >
>> > > > I cannot figure out how to safely get a substring value in
>> > minilang.
>> > > > I don't
>> > > > even see an OFBiz utility for doing it. The String method will
>> > blow
>> > > > up if
>> > > > the cutoff value is greater than the length of the string, so it
>> > > > seems like
>> > > > I need to do a bunch of String and Math functions to get it and I
>> > am
>> > > > wondering if we need a safe substring method in minilang (and
>> > widget
>> > > > for
>> > > > that matter).
>> > > >
>> > > > I will be glad to add it if it looks like it is needed.
>> > > >
>> > > > -Al
>> > > >
>> > >
>> > >
>> >
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.472 / Virus Database: 269.8.7/830 - Release Date: 6/3/2007 12:47 PM

[byersa]

That is a good idea. Thanks.
-Al

On 6/4/07, Chris Howe <[hidden email]> wrote:

>
> I wouldn't bother with the service engine, but instead add a method to
> base.util.StringUtil
>
> That seems to be a safe tool that would be beneficial in other places..
>
> --- Al Byers <[hidden email]> wrote:
>
> > I just want to get the first <x> characters in a text string (which
> > may be
> > shorter than <x>). Ideally, I want to break at a whitespace - more
> > reason
> > for writing a special function.
> >
> > I suppose I can just write a service to do it. I was trying to
> > determine if
> > this (and maybe other string processing) should be added to the
> > minilang and
> > widget functionality.
> >
> > -Al
> >
> > On 6/4/07, Chris Howe <[hidden email]> wrote:
> > >
> > > I'm having trouble quickly reading how you're hacking it to work
> > versus
> > > what you're trying to do...
> > >
> > > What are you trying to perform if this were java?
> > >
> > > --- Al Byers <[hidden email]> wrote:
> > >
> > > > Thanks Chris,
> > > >
> > > > I was aware of the "call" methods, but here is the code that I
> > wrote
> > > > in
> > > > order to get the first x characters of the text body to use as a
> > > > description:
> > > >
> > > >         <call-object-method method-name="length" obj-field-name="
> > > > parameters.textData" ret-field-name="textDataLen"/>
> > > >         <log level="info" message="textDataLen:${textDataLen}"/>
> > > >         <property-to-field resource="forum"
> > property="descriptLen"
> > > > field-name="descriptLen" />
> > > >         <log level="info" message="descriptLen:${descriptLen}"/>
> > > >         <set field="dblTextDataLen" from-field="textDataLen"
> > > > type="Double"/>
> > > >         <set field="dblDescriptLen" from-field="descriptLen"
> > > > type="Double"/>
> > > >         <call-class-method method-name="min"
> > > > class-name="java.lang.Math"
> > > > ret-field-name="subStringLen">
> > > >             <field field-name="dblTextDataLen" type="double"/>
> > > >             <field field-name="dblDescriptLen" type="double"/>
> > > >         </call-class-method>
> > > >         <set field="intSubStringLen" from-field="subStringLen"
> > > > type="Integer"/>
> > > >         <log level="info"
> > message="subStringLen:${subStringLen}"/>
> > > >         <set field="zeroValue" value="0" type="Integer"/>
> > > >         <call-object-method method-name="substring"
> > obj-field-name="
> > > > parameters.textData" ret-field-name="subDescript">
> > > >             <field field-name="zeroValue" type="int"/>
> > > >             <field field-name="intSubStringLen" type="int"/>
> > > >         </call-object-method>
> > > >         <log level="info" message="subDescript:${subDescript}"/>
> > > >
> > > > As you can see there is a lot of code just to get the variables
> > into
> > > > the
> > > > right type for calling the class and object methods. Does anyone
> > see
> > > > a
> > > > better way to do this?
> > > >
> > > > I agree that it would make sense to put any added functionality
> > in
> > > > the map
> > > > processor, but then you have to create a file ( don't you? ) just
> > to
> > > > do one
> > > > little thing.
> > > >
> > > > Thanks,
> > > >
> > > > -Al
> > > >
> > > > On 6/4/07, Chris Howe <[hidden email]> wrote:
> > > > >
> > > > > remember that simple methods have the method
> > <call-class-method> so
> > > > > that you can call any method that exists in java, just be sure
> > to
> > > > use
> > > > > type that is part of the method signature, not a subtype.  As
> > far
> > > > as
> > > > > adding the function more natively, if necessary, it might be
> > best
> > > > as
> > > > > one of the map processor functions.
> > > > >
> > > > > --- Al Byers <[hidden email]> wrote:
> > > > >
> > > > > > I cannot figure out how to safely get a substring value in
> > > > minilang.
> > > > > > I don't
> > > > > > even see an OFBiz utility for doing it. The String method
> > will
> > > > blow
> > > > > > up if
> > > > > > the cutoff value is greater than the length of the string, so
> > it
> > > > > > seems like
> > > > > > I need to do a bunch of String and Math functions to get it
> > and I
> > > > am
> > > > > > wondering if we need a safe substring method in minilang (and
> > > > widget
> > > > > > for
> > > > > > that matter).
> > > > > >
> > > > > > I will be glad to add it if it looks like it is needed.
> > > > > >
> > > > > > -Al
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

[Ean Schuessler]

I realize that this isn't productive in any way... but... Minilang is the work
of the Devil and I will do anything I can not to write code in it.

Just thought I'd chime in. ;-)

On Monday 04 June 2007 03:57:10 pm Al Byers wrote:

> I was aware of the "call" methods, but here is the code that I wrote in
> order to get the first x characters of the text body to use as a
> description:
>
>         <call-object-method method-name="length" obj-field-name="
> parameters.textData" ret-field-name="textDataLen"/>
>         <log level="info" message="textDataLen:${textDataLen}"/>
>         <property-to-field resource="forum" property="descriptLen"
> field-name="descriptLen" />
>         <log level="info" message="descriptLen:${descriptLen}"/>
>         <set field="dblTextDataLen" from-field="textDataLen"
> type="Double"/> <set field="dblDescriptLen" from-field="descriptLen"
> type="Double"/> <call-class-method method-name="min"
> class-name="java.lang.Math" ret-field-name="subStringLen">
>             <field field-name="dblTextDataLen" type="double"/>
>             <field field-name="dblDescriptLen" type="double"/>
>         </call-class-method>
>         <set field="intSubStringLen" from-field="subStringLen"
> type="Integer"/>
>         <log level="info" message="subStringLen:${subStringLen}"/>
>         <set field="zeroValue" value="0" type="Integer"/>
>         <call-object-method method-name="substring" obj-field-name="
> parameters.textData" ret-field-name="subDescript">
>             <field field-name="zeroValue" type="int"/>
>             <field field-name="intSubStringLen" type="int"/>
>         </call-object-method>
>         <log level="info" message="subDescript:${subDescript}"/>
>
> As you can see there is a lot of code just to get the variables into the
> right type for calling the class and object methods. Does anyone see a
> better way to do this?
>
> I agree that it would make sense to put any added functionality in the map
> processor, but then you have to create a file ( don't you? ) just to do one
> little thing.

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

[byersa]

Ean,

Hey, if Andrew can see the light and convert then there may even be hope for
you :0)

-Al


On 6/6/07, Ean Schuessler <[hidden email]> wrote:

>
> I realize that this isn't productive in any way... but... Minilang is the
> work
> of the Devil and I will do anything I can not to write code in it.
>
> Just thought I'd chime in. ;-)
>
> On Monday 04 June 2007 03:57:10 pm Al Byers wrote:
> > I was aware of the "call" methods, but here is the code that I wrote in
> > order to get the first x characters of the text body to use as a
> > description:
> >
> >         <call-object-method method-name="length" obj-field-name="
> > parameters.textData" ret-field-name="textDataLen"/>
> >         <log level="info" message="textDataLen:${textDataLen}"/>
> >         <property-to-field resource="forum" property="descriptLen"
> > field-name="descriptLen" />
> >         <log level="info" message="descriptLen:${descriptLen}"/>
> >         <set field="dblTextDataLen" from-field="textDataLen"
> > type="Double"/> <set field="dblDescriptLen" from-field="descriptLen"
> > type="Double"/> <call-class-method method-name="min"
> > class-name="java.lang.Math" ret-field-name="subStringLen">
> >             <field field-name="dblTextDataLen" type="double"/>
> >             <field field-name="dblDescriptLen" type="double"/>
> >         </call-class-method>
> >         <set field="intSubStringLen" from-field="subStringLen"
> > type="Integer"/>
> >         <log level="info" message="subStringLen:${subStringLen}"/>
> >         <set field="zeroValue" value="0" type="Integer"/>
> >         <call-object-method method-name="substring" obj-field-name="
> > parameters.textData" ret-field-name="subDescript">
> >             <field field-name="zeroValue" type="int"/>
> >             <field field-name="intSubStringLen" type="int"/>
> >         </call-object-method>
> >         <log level="info" message="subDescript:${subDescript}"/>
> >
> > As you can see there is a lot of code just to get the variables into the
> > right type for calling the class and object methods. Does anyone see a
> > better way to do this?
> >
> > I agree that it would make sense to put any added functionality in the
> map
> > processor, but then you have to create a file ( don't you? ) just to do
> one
> > little thing.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

[David E Jones]

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.

-David


Al Byers wrote:

> Ean,
>
> Hey, if Andrew can see the light and convert then there may even be hope
> for
> you :0)
>
> -Al
>
>
> On 6/6/07, Ean Schuessler <[hidden email]> wrote:
>>
>> I realize that this isn't productive in any way... but... Minilang is the
>> work
>> of the Devil and I will do anything I can not to write code in it.
>>
>> Just thought I'd chime in. ;-)
>>
>> On Monday 04 June 2007 03:57:10 pm Al Byers wrote:
>> > I was aware of the "call" methods, but here is the code that I wrote in
>> > order to get the first x characters of the text body to use as a
>> > description:
>> >
>> >         <call-object-method method-name="length" obj-field-name="
>> > parameters.textData" ret-field-name="textDataLen"/>
>> >         <log level="info" message="textDataLen:${textDataLen}"/>
>> >         <property-to-field resource="forum" property="descriptLen"
>> > field-name="descriptLen" />
>> >         <log level="info" message="descriptLen:${descriptLen}"/>
>> >         <set field="dblTextDataLen" from-field="textDataLen"
>> > type="Double"/> <set field="dblDescriptLen" from-field="descriptLen"
>> > type="Double"/> <call-class-method method-name="min"
>> > class-name="java.lang.Math" ret-field-name="subStringLen">
>> >             <field field-name="dblTextDataLen" type="double"/>
>> >             <field field-name="dblDescriptLen" type="double"/>
>> >         </call-class-method>
>> >         <set field="intSubStringLen" from-field="subStringLen"
>> > type="Integer"/>
>> >         <log level="info" message="subStringLen:${subStringLen}"/>
>> >         <set field="zeroValue" value="0" type="Integer"/>
>> >         <call-object-method method-name="substring" obj-field-name="
>> > parameters.textData" ret-field-name="subDescript">
>> >             <field field-name="zeroValue" type="int"/>
>> >             <field field-name="intSubStringLen" type="int"/>
>> >         </call-object-method>
>> >         <log level="info" message="subDescript:${subDescript}"/>
>> >
>> > As you can see there is a lot of code just to get the variables into
>> the
>> > right type for calling the class and object methods. Does anyone see a
>> > better way to do this?
>> >
>> > I agree that it would make sense to put any added functionality in the
>> map
>> > processor, but then you have to create a file ( don't you? ) just to do
>> one
>> > little thing.
>>
>> --
>> Ean Schuessler, CTO
>> [hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>
>

[Ean Schuessler]

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

[jonwimp]

Minilang does just about everything I need for data operations (retrieval, update, creation,
deletion). Via map-processors, there's even some decent ways to manipulate (pre-massage) the data
for display or storage. About 99% of the backend codes deal with data operations like that.

Minilang also does not require a server restart or a code compile, making it an extremely rapid
tool for development.

The only problem with Minilang is the inability to create reentrant functions. I've fixed that
already, and am now enjoying Minilang like any other standard procedural script/language, except
Minilang deals specifically and competently with backend codes.

I can't say the same for Widget Forms (I've since moved to a Widget Screens and Freemarker macros
combination). But I must say that OFBiz development simply isn't as... well... simple without
Simple Methods.

The alternative is Java in BSH. Between Java and Minilang, it is obvious that Minilang is easier.

The complete reference for Minilang can be gotten from the source codes themselves. Start digging
around SimpleMethod.readOperations() and reverse-engineer from there.

Jonathon

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.
>
> -David
>
>
> Al Byers wrote:
>> Ean,
>>
>> Hey, if Andrew can see the light and convert then there may even be
>> hope for
>> you :0)
>>
>> -Al
>>
>>
>> On 6/6/07, Ean Schuessler <[hidden email]> wrote:
>>>
>>> I realize that this isn't productive in any way... but... Minilang is
>>> the
>>> work
>>> of the Devil and I will do anything I can not to write code in it.
>>>
>>> Just thought I'd chime in. ;-)
>>>
>>> On Monday 04 June 2007 03:57:10 pm Al Byers wrote:
>>> > I was aware of the "call" methods, but here is the code that I
>>> wrote in
>>> > order to get the first x characters of the text body to use as a
>>> > description:
>>> >
>>> >         <call-object-method method-name="length" obj-field-name="
>>> > parameters.textData" ret-field-name="textDataLen"/>
>>> >         <log level="info" message="textDataLen:${textDataLen}"/>
>>> >         <property-to-field resource="forum" property="descriptLen"
>>> > field-name="descriptLen" />
>>> >         <log level="info" message="descriptLen:${descriptLen}"/>
>>> >         <set field="dblTextDataLen" from-field="textDataLen"
>>> > type="Double"/> <set field="dblDescriptLen" from-field="descriptLen"
>>> > type="Double"/> <call-class-method method-name="min"
>>> > class-name="java.lang.Math" ret-field-name="subStringLen">
>>> >             <field field-name="dblTextDataLen" type="double"/>
>>> >             <field field-name="dblDescriptLen" type="double"/>
>>> >         </call-class-method>
>>> >         <set field="intSubStringLen" from-field="subStringLen"
>>> > type="Integer"/>
>>> >         <log level="info" message="subStringLen:${subStringLen}"/>
>>> >         <set field="zeroValue" value="0" type="Integer"/>
>>> >         <call-object-method method-name="substring" obj-field-name="
>>> > parameters.textData" ret-field-name="subDescript">
>>> >             <field field-name="zeroValue" type="int"/>
>>> >             <field field-name="intSubStringLen" type="int"/>
>>> >         </call-object-method>
>>> >         <log level="info" message="subDescript:${subDescript}"/>
>>> >
>>> > As you can see there is a lot of code just to get the variables
>>> into the
>>> > right type for calling the class and object methods. Does anyone see a
>>> > better way to do this?
>>> >
>>> > I agree that it would make sense to put any added functionality in the
>>> map
>>> > processor, but then you have to create a file ( don't you? ) just
>>> to do
>>> one
>>> > little thing.
>>>
>>> --
>>> Ean Schuessler, CTO
>>> [hidden email]
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>>
>>
>
>

[jonwimp]

Ean,

A major part of the reason why Simple Methods can be difficult to read is this: you can't write
reentrant functions in Minilang. Maybe repeated chunks of Minilang codes cannot be abstracted into
neat reentrant functions.

Once you introduce reentrant functions, you'll find Minilang just as simple as any other
script/language, like PHP, C, Javascript.

Plus Minilang is specifically made for backend data operations.

As for any syntactic sugars that may be absent from Minilang, it really won't be difficult to
enhance it. All we need (or all I need) is feedback! :) Chris Howe is a good source for opinions
and experience on Minilang, I think. Maybe we can ask him.

I added the ability to do reentrant Simple Methods inside of an hour.

Jonathon

Ean Schuessler wrote:

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

[Jacques Le Roux]

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

[jonwimp]

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 ?

I think it does not exist because there isn't anyone who can create for Minilang "everything under
the sun". No time. :)

But if there is a Minilang committee set up to assess contributions to Minilang, perhaps we can
dump all our wishlists to such a committee?

Just FYI, some of the enhancements I do for OFBiz core, if not taken up by ASL, will likely become
proprietary codes that none of us can use in future. The default licensing for all my work is to
transfer all rights to my clients.

Jonathon

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

[cjhowe]

My almost exclusive use of simple methods stems from my lack of
technical skills and not from a perceived superiority of it.  When
getting familiar with OFBiz I found it much easier to find examples of
use because the tags could be searched for.  Without the tags that are
present in an xml structured language, it is much more difficult for
someone to produce anything of value unless they have a strong
understanding of java and are willing to spend the time to get
intimately involved with the major classes in OFBiz.

As far as typing, if you're talking keystrokes, that's an editor issue.
 The xml editor available in the the eclipse web tools platform does a
perfect job of reading the xsd.  If it's actual characters on the
screen, I can't really offer anything there.  If you find it difficult
to read, changing the coloring of the editor is a rather obvious point
of help, but I imagine you already know that.

In regards to a possible GUI aspect or using OFBiz as a sort of IDE, I
think you would need to be able to load/unload components and services
before you would want to seriously consider the potential benefit.

Is minilang the devil?  Possibly.  It's allowed just enough crutch for
me not to really invest the time in learning Java.  I can certainly
read what's going on, but I still lack the creative tonicity needed to
write quickly in Java starting with a blank screen.  If minilang is the
devil, maybe the devil has gotten a bad wrap ;-)

--- Jonathon -- Improov <[hidden email]> wrote:

> Ean,
>
> A major part of the reason why Simple Methods can be difficult to
> read is this: you can't write
> reentrant functions in Minilang. Maybe repeated chunks of Minilang
> codes cannot be abstracted into
> neat reentrant functions.
>
> Once you introduce reentrant functions, you'll find Minilang just as
> simple as any other
> script/language, like PHP, C, Javascript.
>
> Plus Minilang is specifically made for backend data operations.
>
> As for any syntactic sugars that may be absent from Minilang, it
> really won't be difficult to
> enhance it. All we need (or all I need) is feedback! :) Chris Howe is
> a good source for opinions
> and experience on Minilang, I think. Maybe we can ask him.
>
> I added the ability to do reentrant Simple Methods inside of an hour.
>
> Jonathon
>
> Ean Schuessler wrote:
> > 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.
> >
>
>

[Jacopo Cappellato]

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

[Jacques Le Roux]

> 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