How to avoid resetting server with <call-bsh><![CDATA]> and Minilang?

[jonwimp]

Topic was "Re: <if-empty> test for Map does not do deep test".

Hi Chris (Howe),

You were saying that I can avoid restarting the server or recompiling my codes if I use
<call-bsh><![CDATA]> and Minilang. I haven't explored using Minilang in bean shell. Is it possible?

 > To attempt the test that you're trying, either test the actual field that
 > you're interested in or if unknown run an iterate-map and set the value of
 > some field (to if-not-empty test later) to a value if you encounter an empty
 > field.

I currently do it in some "validateInputs" method, which avoids setting a field (inside a deep map
structure, a constructed result, like a map-processor but more elaborate) if the input parameters
were empty. It's a matter of doing it there, or later on before I use the constructed results.

If there were a deep if-empty test for Map(s), it'll just mean I can do away with many individual
<if-empty> statements, and just plonk values in "parameters" into my constructed result.

Ultimately, I want to do <if-not-empty field-name="result.primaryPhone">, rather than go through
primaryPhone.countryCode and primaryPhone.areaCode individually.

When you say "test the field [I] am interested in", that's difficult to apply in my case. I think
I've been using Minilang too much like Java, object-oriented, with nested Map structures being
passed around.

Well, if you're interested, and I think you use lots of Minilang, I've been unwittingly making
Minilang more and more robust like OO Java. It started out with the motivation to avoid server
restarts and Java code compiles, but is looking like the resultant Minilang is as good and clean
as Java can be. I might just continue to use Minilang and avoid Java as much as possible. The
extensions to Minilang is minimal. Took me an hour or less to create and test
CallSimpleMethodScoped.java.

Jonathon

[cjhowe]

Hi Jonathon,
I'm finding it a bit difficult to follow, so I'll attempt to group it.
Please correct me if I group your concerns incorrectly.

1. <call-bsh>
If you find some part of simple methods cumbersome or too difficult,
you can always drop into beanshell script (interpreted Java) by using
the <call-bsh> tag e.g.
<call-bsh><![CDATA[
...
some java code or beanshell script code
...
return org.ofbiz.base.util.UtilMisc.toMap("noMapVariableName", value);
or
mapName.put("variableName", value);
]]/></call-bsh>
this makes available either nomapVariableName or mapName.variableName
for the rest of your simple method.

2. if conditionals
if you're wanting to test multiple statements, you can use the
following
<if>
  <condition>
    <or>
      <not>
        <if-empty field-name=""></if-empty>
        <if-empty field-name=""></if-empty>
        <if-empty field-name=""></if-empty>
      </not>
    </or>
  </condition>
  <then>
  ...
  </then>
</if>

or you may find it easier to accomplish what you're wanting through a
java method

<call-class-method method="jonathonEmptyMapTest"
class="org.jon.w.specialClass" ret-field="emptyMapBoolean">
<field field-name="mapToTest" type="Map"/>
</call-class-method>

<if-compare field="emptyMapBoolean" operator="equals" value="true"
type="Boolean">

...
</if-compare>

3. final thoughts...
What helps to keep simple methods easy to use is it's limited
operations.  As far as the scope improvement, I'm on the fence on the
benefit it may offer versus how it might complicate and confuse the
easy to understand non-scoped call.  Be careful thinking of simple
methods as a replacement for java classes, it's simply another tool in
your OFBiz toolbox.  No sense outfitting a nail gun with a rotary
attachment when you already have a Dremel lying on your bench.


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

> Topic was "Re: <if-empty> test for Map does not do deep test".
>
> Hi Chris (Howe),
>
> You were saying that I can avoid restarting the server or recompiling
> my codes if I use
> <call-bsh><![CDATA]> and Minilang. I haven't explored using Minilang
> in bean shell. Is it possible?
>
>  > To attempt the test that you're trying, either test the actual
> field that
>  > you're interested in or if unknown run an iterate-map and set the
> value of
>  > some field (to if-not-empty test later) to a value if you
> encounter an empty
>  > field.
>
> I currently do it in some "validateInputs" method, which avoids
> setting a field (inside a deep map
> structure, a constructed result, like a map-processor but more
> elaborate) if the input parameters
> were empty. It's a matter of doing it there, or later on before I use
> the constructed results.
>
> If there were a deep if-empty test for Map(s), it'll just mean I can
> do away with many individual
> <if-empty> statements, and just plonk values in "parameters" into my
> constructed result.
>
> Ultimately, I want to do <if-not-empty
> field-name="result.primaryPhone">, rather than go through
> primaryPhone.countryCode and primaryPhone.areaCode individually.
>
> When you say "test the field [I] am interested in", that's difficult
> to apply in my case. I think
> I've been using Minilang too much like Java, object-oriented, with
> nested Map structures being
> passed around.
>
> Well, if you're interested, and I think you use lots of Minilang,
> I've been unwittingly making
> Minilang more and more robust like OO Java. It started out with the
> motivation to avoid server
> restarts and Java code compiles, but is looking like the resultant
> Minilang is as good and clean
> as Java can be. I might just continue to use Minilang and avoid Java
> as much as possible. The
> extensions to Minilang is minimal. Took me an hour or less to create
> and test
> CallSimpleMethodScoped.java.
>
> Jonathon
>

[jonwimp]

Chris,

 > 1. <call-bsh>
 > If you find some part of simple methods cumbersome or too difficult,
 > you can always drop into beanshell script (interpreted Java) by using
 > the <call-bsh> tag

Yes, that's what I thought, only Java so far, not Minilang. I'm trying to use Minilang as a
procedural programming language. I can't use <call-bsh> for this then.

 > 2. if conditionals
 > if you're wanting to test multiple statements, you can use the
 > following

That's what I'm doing. Works. Thanks. Would've been better if there was something like
<if-map-values-empty> that digs recursively into a map and tests if all keys point to empty values.

 > or you may find it easier to accomplish what you're wanting through a
 > java method

Not this, it requires a recompile and OFBiz restart.

 > 3. final thoughts...
 > What helps to keep simple methods easy to use is it's limited operations.  As
 > far as the scope improvement, I'm on the fence on the benefit it may offer
 > versus how it might complicate and confuse the easy to understand non-scoped
 > call.  Be careful thinking of simple methods as a replacement for java
 > classes, it's simply another tool in your OFBiz toolbox.  No sense outfitting
 > a nail gun with a rotary attachment when you already have a Dremel lying on
 > your bench.

"Private scope" calls (callee has private scope) are cleaner and easier to program than "global
scope" calls (mere macros). Simple analogy. Suppose your office hires my company to do work, and
you have a Jonathon and I have a Jonathon here too. You send me this instruction: "Get Jonathon to
do some work". If I had access to your Jonathon (and knew about him), I would probably tell him to
do the work, rather than tell my Jonathon to do it.

All I wanted was to break up my growing SimpleMethod(s), factor repeated chunks of codes into
generic SimpleMethod(s) to be called.

That's just typical procedural programming. Put repeated codes in separate functions.

So, I searched the OFBiz codes to find examples of where this can be done. Well, ok, I cheated, I
went into SimpleMethod.java and CallSimpleMethod.java, and quickly concluded that procedural
programming wasn't straightforward using <call-simple-method>.

And then I looked into CallService.java, and realized that it provided some form of return results
(via MethodContext.results). How it achieves "private scope" for the procedure/method being called
was simple: it just ran a service, which inherently already uses its own context (MethodContext,
if engine="simple").

I did another targeted search for <call-service> examples. I found PartyContactMechServices.xml.
In there, I saw a lot of procedural programming. Very neat, very reusable. Then I realized that
about the only examples of procedural programming with Minilang in OFBiz was this, it was to use
services (<call-service>).

Now that I am able to do true procedural programming (not mere macros), I can easily do chunks of
codes with your suggested <condition><not><or><if-empty> structure.

As for not having to restart the server, I just did procedural Minilang without using servicedef.

I know, I know. The Service Engine checks the input/output, safer. I'll do the servicedef part
when I have time. The procedural Minilang SimpleMethod(s) are written such that it can be reused
by services. After all, <call-simple-method-scoped> follows <call-service> very closely.

I just did a version of <call-service> that doesn't require server restarts, that's all.

Jonathon

Chris Howe wrote:

> Hi Jonathon,
> I'm finding it a bit difficult to follow, so I'll attempt to group it.
> Please correct me if I group your concerns incorrectly.
>
> 1. <call-bsh>
> If you find some part of simple methods cumbersome or too difficult,
> you can always drop into beanshell script (interpreted Java) by using
> the <call-bsh> tag e.g.
> <call-bsh><![CDATA[
> ...
> some java code or beanshell script code
> ...
> return org.ofbiz.base.util.UtilMisc.toMap("noMapVariableName", value);
> or
> mapName.put("variableName", value);
> ]]/></call-bsh>
> this makes available either nomapVariableName or mapName.variableName
> for the rest of your simple method.
>
> 2. if conditionals
> if you're wanting to test multiple statements, you can use the
> following
> <if>
>   <condition>
>     <or>
>       <not>
>         <if-empty field-name=""></if-empty>
>         <if-empty field-name=""></if-empty>
>         <if-empty field-name=""></if-empty>
>       </not>
>     </or>
>   </condition>
>   <then>
>   ...
>   </then>
> </if>
>
> or you may find it easier to accomplish what you're wanting through a
> java method
>
> <call-class-method method="jonathonEmptyMapTest"
> class="org.jon.w.specialClass" ret-field="emptyMapBoolean">
> <field field-name="mapToTest" type="Map"/>
> </call-class-method>
>
> <if-compare field="emptyMapBoolean" operator="equals" value="true"
> type="Boolean">
>
> ...
> </if-compare>
>
> 3. final thoughts...
> What helps to keep simple methods easy to use is it's limited
> operations.  As far as the scope improvement, I'm on the fence on the
> benefit it may offer versus how it might complicate and confuse the
> easy to understand non-scoped call.  Be careful thinking of simple
> methods as a replacement for java classes, it's simply another tool in
> your OFBiz toolbox.  No sense outfitting a nail gun with a rotary
> attachment when you already have a Dremel lying on your bench.
>
>
> --- Jonathon -- Improov <[hidden email]> wrote:
>
>> Topic was "Re: <if-empty> test for Map does not do deep test".
>>
>> Hi Chris (Howe),
>>
>> You were saying that I can avoid restarting the server or recompiling
>> my codes if I use
>> <call-bsh><![CDATA]> and Minilang. I haven't explored using Minilang
>> in bean shell. Is it possible?
>>
>>  > To attempt the test that you're trying, either test the actual
>> field that
>>  > you're interested in or if unknown run an iterate-map and set the
>> value of
>>  > some field (to if-not-empty test later) to a value if you
>> encounter an empty
>>  > field.
>>
>> I currently do it in some "validateInputs" method, which avoids
>> setting a field (inside a deep map
>> structure, a constructed result, like a map-processor but more
>> elaborate) if the input parameters
>> were empty. It's a matter of doing it there, or later on before I use
>> the constructed results.
>>
>> If there were a deep if-empty test for Map(s), it'll just mean I can
>> do away with many individual
>> <if-empty> statements, and just plonk values in "parameters" into my
>> constructed result.
>>
>> Ultimately, I want to do <if-not-empty
>> field-name="result.primaryPhone">, rather than go through
>> primaryPhone.countryCode and primaryPhone.areaCode individually.
>>
>> When you say "test the field [I] am interested in", that's difficult
>> to apply in my case. I think
>> I've been using Minilang too much like Java, object-oriented, with
>> nested Map structures being
>> passed around.
>>
>> Well, if you're interested, and I think you use lots of Minilang,
>> I've been unwittingly making
>> Minilang more and more robust like OO Java. It started out with the
>> motivation to avoid server
>> restarts and Java code compiles, but is looking like the resultant
>> Minilang is as good and clean
>> as Java can be. I might just continue to use Minilang and avoid Java
>> as much as possible. The
>> extensions to Minilang is minimal. Took me an hour or less to create
>> and test
>> CallSimpleMethodScoped.java.
>>
>> Jonathon
>>
>
>

[cjhowe]

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

>
>  > or you may find it easier to accomplish what you're wanting
> through a
>  > java method
>
> Not this, it requires a recompile and OFBiz restart.

I'm saying you create your one time java class that does the recursion,
then you have it available forever and don't need to play with the
community code. Thus separating the application logic from the business
logic.  Java and simple methods can be mixed quite nicely at times.

>
>  > 3. final thoughts...
 
> "Private scope" calls (callee has private scope) are cleaner and
> easier to program than "global
> scope" calls (mere macros). Simple analogy. Suppose your office hires
> my company to do work, and
> you have a Jonathon and I have a Jonathon here too. You send me this
> instruction: "Get Jonathon to
> do some work". If I had access to your Jonathon (and knew about him),
> I would probably tell him to
> do the work, rather than tell my Jonathon to do it.

Any code that you create, I should be consuming as a service, not
inline as a simple method. I understand the lazy, no restart benefit
(up until a month ago I was developing on a sub Ghz machine and that
took about 5 minutes to restart, now I'm down to 13 seconds :) )
however, as you allude to in the rest of your post by the time
something is polished enough to do real work it should be in a service
structure.

[jonwimp]

Chris,

Well, it still doesn't hurt to allow for reentrant codes in Minilang. If it's easily possible, why
not? How do you usually develop reentrant codes in Minilang? With services?

I move around a bit with my laptop, and it still takes a minute or two to restart, though it's not
sub-Ghz. :/

Jonathon

Chris Howe wrote:

> --- Jonathon -- Improov <[hidden email]> wrote:
>
>>  > or you may find it easier to accomplish what you're wanting
>> through a
>>  > java method
>>
>> Not this, it requires a recompile and OFBiz restart.
>
> I'm saying you create your one time java class that does the recursion,
> then you have it available forever and don't need to play with the
> community code. Thus separating the application logic from the business
> logic.  Java and simple methods can be mixed quite nicely at times.
>
>>  > 3. final thoughts...
>  
>> "Private scope" calls (callee has private scope) are cleaner and
>> easier to program than "global
>> scope" calls (mere macros). Simple analogy. Suppose your office hires
>> my company to do work, and
>> you have a Jonathon and I have a Jonathon here too. You send me this
>> instruction: "Get Jonathon to
>> do some work". If I had access to your Jonathon (and knew about him),
>> I would probably tell him to
>> do the work, rather than tell my Jonathon to do it.
>
> Any code that you create, I should be consuming as a service, not
> inline as a simple method. I understand the lazy, no restart benefit
> (up until a month ago I was developing on a sub Ghz machine and that
> took about 5 minutes to restart, now I'm down to 13 seconds :) )
> however, as you allude to in the rest of your post by the time
> something is polished enough to do real work it should be in a service
> structure.
>
>
>
>