Substring method for minilang?

[Al Byers <by...@automationgroups.com>]

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

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Substring method for minilang?

[David E Jones <jo...@hotwaxmedia.com>]

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

Re: Substring method for minilang?

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Substring method for minilang?

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Substring method for minilang?

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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
>> ean@brainfood.com
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
> 
> 

Re: Substring method for minilang?

[Jacques Le Roux <ja...@les7arts.com>]

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" <jo...@improov.com>
À : <de...@ofbiz.apache.org>
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
> >>>> ean@brainfood.com
> >>>> 214-720-0700 x 315
> >>>> Brainfood, Inc.
> >>>> http://www.brainfood.com
> >
> >

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Substring method for minilang?

[Chris Howe <cj...@yahoo.com>]

--- Jacques Le Roux <ja...@les7arts.com> 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.

Re: Substring method for minilang?

[Jacques Le Roux <ja...@les7arts.com>]

> 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
> >> ean@brainfood.com
> >> 214-720-0700 x 315
> >> Brainfood, Inc.
> >> http://www.brainfood.com

Re: Substring method for minilang?

[Jacopo Cappellato <ti...@sastau.it>]

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
>> ean@brainfood.com
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com

Re: Substring method for minilang?

[Jacques Le Roux <ja...@les7arts.com>]

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
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com

Re: Substring method for minilang?

[Chris Howe <cj...@yahoo.com>]

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 <jo...@improov.com> 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.
> > 
> 
> 

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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

Re: Substring method for minilang?

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Substring method for minilang?

[Al Byers <by...@automationgroups.com>]

That is a good idea. Thanks.
-Al

On 6/4/07, Chris Howe <cj...@yahoo.com> 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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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

Re: Substring method for minilang?

[Chris Howe <cj...@yahoo.com>]

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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> > > > >
> > > >
> > > >
> > >
> >
> >
> 

Re: Substring method for minilang?

[Al Byers <by...@automationgroups.com>]

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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> > > >
> > >
> > >
> >
>
>

Re: Substring method for minilang?

[Jacques Le Roux <ja...@les7arts.com>]

Al,

De : "Al Byers" <by...@automationgroups.com>
> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> > >
> >
> >
>

Re: Substring method for minilang?

[Chris Howe <cj...@yahoo.com>]

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 <by...@automationgroups.com> 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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> > >
> >
> >
> 

Re: Substring method for minilang?

[Jonathon -- Improov <jo...@improov.com>]

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 <ea...@brainfood.com> 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
>>> ean@brainfood.com
>>> 214-720-0700 x 315
>>> Brainfood, Inc.
>>> http://www.brainfood.com
>>>
>>
> 
> 

Re: Substring method for minilang?

[David E Jones <jo...@hotwaxmedia.com>]

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 <ea...@brainfood.com> 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
>> ean@brainfood.com
>> 214-720-0700 x 315
>> Brainfood, Inc.
>> http://www.brainfood.com
>>
> 

Re: Substring method for minilang?

[Al Byers <by...@automationgroups.com>]

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 <ea...@brainfood.com> 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
> ean@brainfood.com
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>

Re: Substring method for minilang?

[Ean Schuessler <ea...@brainfood.com>]

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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

Re: Substring method for minilang?

[Al Byers <by...@automationgroups.com>]

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 <cj...@yahoo.com> 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 <by...@automationgroups.com> 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
> >
>
>

Re: Substring method for minilang?

[Chris Howe <cj...@yahoo.com>]

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 <by...@automationgroups.com> 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
>