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 <[EMAIL PROTECTED]> 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
