Removing fields from a map in Minilang clear-field

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

I can't find any usage of ContextAccessor.remove(MethodContext) in Minilang's source codes at 
src/org/ofbiz/minilang/method/envops .

Shall I add an option to <clear-field> that will trigger a ContextAccessor.remove() rather than a 
ContextAccessor.put() that merely replaces a field with null?

I'm doing a custom service that <implements> an existing service in OFBiz, and I need to trim away 
the extra input fields before putting them to the existing service.

Jonathon

Re: How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field

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

Jacopo,

 > it seems you did things in the right way... so my two last comments were not
 > probably correct (I mean the answers about the transactional behaviour and
 > about the parameters passed in the eca), I'm sorry for this. I will do more
 > research on this in my spare time but in the meantime I'll try to 'refund'
 > you with a better advice :-)

Maybe I came across to you in a wrong way before. Please don't say sorry for that "try-this?" 
advice. I'm just glad you find the time to "experiment together" with me. I'm not really a robot 
with no heart, asking humans "why do you need to sleep, can you please research for days then 
answer my question ONCE and ACCURATELY?". I'm not that bad a monster. :P

 > I'd suggest to create another custom service that performs "your own
 > stuff here. Like updating entity NoteData...", let's call it
 > myown.updateWorkInstructions: in it's service definition you can put all
 > the relevant parameters (a subset of the parameters of the
 > myown.updateWorkEffort service).
 > After this is done, the myown.updateWorkEffort service can be
 > implemented in this way:
 >
 > <simple-method method-name="myown.updateWorkEffort"
 >   short-description="Update Work Effort and then Work Instruction">
 >     <set-service-fields map-name="parameters"
 > service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
 >     <call-service service-name="updateWorkEffort"
 > in-map-name="updateWorkEffortParams">
 >         <default-message>Work Effort successfully
 > updated.</default-message>
 >     </call-service>
 >     <check-errors/>
 >
 >     <set-service-fields map-name="parameters"
 > service-name="myown.updateWorkInstructions"
 > to-map-name="updateWorkInstructionsParams"/>
 >     <call-service service-name="myown.updateWorkInstructions"
 > in-map-name="updateWorkInstructionsParams">
 >         <default-message>Work Effort Instructions successfully
 > updated.</default-message>
 >     </call-service>
 >
 > </simple-method>
 >
 > Does it make sense?

So, service "myown.updateWorkEffort" will contain a superset of input parameters, both for service 
"updateWorkEffort" and for service "myown.updateWorkInstructions"? Yeah, that's what I'm currently 
doing too.

Your suggestion to put the logics "update work instruction" in a separate service 
"myown.updateWorkInstructions" will properly modularize things, such that I can call service 
"myown.updateWorkInstructions" separately from some other place.

Wrapping the 2 services "updateWorkEffort" and "myown.updateWorkInstructions" together into 
service "myown.updateWorkEffort" will certainly wrap it all up in a single ACID transaction.

Yeah, that makes sense. Thanks.

 > PS: If you are in the mood of doing some experiments, another alternative
 > solution is to create a new service of type service-group (you should find at
 > least an example of this in the system).

Ok, I'll try that. Thanks for pointing it out.

Jonathon

Jacopo Cappellato wrote:
> Hmmmm...
> 
> it seems you did things in the right way... so my two last comments were 
> not probably correct (I mean the answers about the transactional 
> behaviour and about the parameters passed in the eca), I'm sorry for 
> this. I will do more research on this in my spare time but in the 
> meantime I'll try to 'refund' you with a better advice :-)
> 
> Back to your original question:
> 
> This is the code from your original message:
> 
> <simple-method method-name="myown.updateWorkEffort"
>   short-description="Update Work Effort and then Work Instruction">
>     <set-service-fields map-name="parameters" 
> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>     <call-service service-name="updateWorkEffort" 
> in-map-name="updateWorkEffortParams">
>         <default-message>Work Effort successfully 
> updated.</default-message>
>     </call-service>
>     <check-errors/>
>     <!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
> </simple-method>
> 
> I'd suggest to create another custom service that performs "your own 
> stuff here. Like updating entity NoteData...", let's call it 
> myown.updateWorkInstructions: in it's service definition you can put all 
> the relevant parameters (a subset of the parameters of the 
> myown.updateWorkEffort service).
> After this is done, the myown.updateWorkEffort service can be 
> implemented in this way:
> 
> <simple-method method-name="myown.updateWorkEffort"
>   short-description="Update Work Effort and then Work Instruction">
>     <set-service-fields map-name="parameters" 
> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>     <call-service service-name="updateWorkEffort" 
> in-map-name="updateWorkEffortParams">
>         <default-message>Work Effort successfully 
> updated.</default-message>
>     </call-service>
>     <check-errors/>
> 
>     <set-service-fields map-name="parameters" 
> service-name="myown.updateWorkInstructions" 
> to-map-name="updateWorkInstructionsParams"/>
>     <call-service service-name="myown.updateWorkInstructions" 
> in-map-name="updateWorkInstructionsParams">
>         <default-message>Work Effort Instructions successfully 
> updated.</default-message>
>     </call-service>
> 
> </simple-method>
> 
> Does it make sense?
> 
> Jacopo
> 
> 
> PS: If you are in the mood of doing some experiments, another 
> alternative solution is to create a new service of type service-group 
> (you should find at least an example of this in the system).
> 
> 
> Jonathon -- Improov wrote:
>> Jacopo,
>>
>> Sorry to bother you again.
>>
>> I seem to have problems with both the service eca method and the 
>> chained request method.
>>
>> The eca method seems to give me the triggering service's parameters. 
>> For eg, say I have a service B triggered on eca by service A. Service 
>> B will receive only the parameters passed to A. Ie, it seems that the 
>> invocation of service A:
>>
>> 1. Creates a local context that contains only the parameters that 
>> service A expects,
>>
>> 2. Passes this same local context on to service B.
>>
>>
>> The chained request method did not roll back the 1st service when an 
>> error is encountered in the 2nd service.
>>
>> In the 2nd service, I threw a deliberate error like this:
>>
>> <add-error>
>>   <fail-message message="Deliberate error"/>
>> </add-error>
>> <check-errors/>
>>
>> Maybe I didn't throw the error correctly?
>>
>> The chained requests:
>>
>> <request-map uri="UpdateRoutingTask">
>>     <security https="true" auth="true"/>
>>     <event type="service" invoke="updateWorkEffort"/>
>>     <response name="success" type="request" 
>> value="UpdateRoutingTaskPlusMore"/>
>>     <response name="error" type="view" value="EditRoutingTask"/>
>> </request-map>
>> <request-map uri="UpdateRoutingTaskPlusMore">
>>     <security https="true" auth="true"/>
>>     <event type="service" invoke="myOwn.updateWorkEffort"/>
>>     <response name="success" type="view" value="EditRoutingTask"/>
>>     <response name="error" type="view" value="EditRoutingTask"/>
>> </request-map>
>>
>> Thanks for your time.
>>
>> Jonathon
>>
> 
> 
> 

Re: How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field

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

Hmmmm...

it seems you did things in the right way... so my two last comments 
were not probably correct (I mean the answers about the transactional 
behaviour and about the parameters passed in the eca), I'm sorry for 
this. I will do more research on this in my spare time but in the 
meantime I'll try to 'refund' you with a better advice :-)

Back to your original question:

This is the code from your original message:

<simple-method method-name="myown.updateWorkEffort"
   short-description="Update Work Effort and then Work Instruction">
     <set-service-fields map-name="parameters" 
service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
     <call-service service-name="updateWorkEffort" 
in-map-name="updateWorkEffortParams">
         <default-message>Work Effort successfully 
updated.</default-message>
     </call-service>
     <check-errors/>
     <!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
</simple-method>

I'd suggest to create another custom service that performs "your own 
stuff here. Like updating entity NoteData...", let's call it 
myown.updateWorkInstructions: in it's service definition you can put all 
the relevant parameters (a subset of the parameters of the 
myown.updateWorkEffort service).
After this is done, the myown.updateWorkEffort service can be 
implemented in this way:

<simple-method method-name="myown.updateWorkEffort"
   short-description="Update Work Effort and then Work Instruction">
     <set-service-fields map-name="parameters" 
service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
     <call-service service-name="updateWorkEffort" 
in-map-name="updateWorkEffortParams">
         <default-message>Work Effort successfully 
updated.</default-message>
     </call-service>
     <check-errors/>

     <set-service-fields map-name="parameters" 
service-name="myown.updateWorkInstructions" 
to-map-name="updateWorkInstructionsParams"/>
     <call-service service-name="myown.updateWorkInstructions" 
in-map-name="updateWorkInstructionsParams">
         <default-message>Work Effort Instructions successfully 
updated.</default-message>
     </call-service>

</simple-method>

Does it make sense?

Jacopo


PS: If you are in the mood of doing some experiments, another 
alternative solution is to create a new service of type service-group 
(you should find at least an example of this in the system).


Jonathon -- Improov wrote:
> Jacopo,
> 
> Sorry to bother you again.
> 
> I seem to have problems with both the service eca method and the chained 
> request method.
> 
> The eca method seems to give me the triggering service's parameters. For 
> eg, say I have a service B triggered on eca by service A. Service B will 
> receive only the parameters passed to A. Ie, it seems that the 
> invocation of service A:
> 
> 1. Creates a local context that contains only the parameters that 
> service A expects,
> 
> 2. Passes this same local context on to service B.
> 
> 
> The chained request method did not roll back the 1st service when an 
> error is encountered in the 2nd service.
> 
> In the 2nd service, I threw a deliberate error like this:
> 
> <add-error>
>   <fail-message message="Deliberate error"/>
> </add-error>
> <check-errors/>
> 
> Maybe I didn't throw the error correctly?
> 
> The chained requests:
> 
> <request-map uri="UpdateRoutingTask">
>     <security https="true" auth="true"/>
>     <event type="service" invoke="updateWorkEffort"/>
>     <response name="success" type="request" 
> value="UpdateRoutingTaskPlusMore"/>
>     <response name="error" type="view" value="EditRoutingTask"/>
> </request-map>
> <request-map uri="UpdateRoutingTaskPlusMore">
>     <security https="true" auth="true"/>
>     <event type="service" invoke="myOwn.updateWorkEffort"/>
>     <response name="success" type="view" value="EditRoutingTask"/>
>     <response name="error" type="view" value="EditRoutingTask"/>
> </request-map>
> 
> Thanks for your time.
> 
> Jonathon
> 

Re: How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field

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

Jacopo,

Sorry to bother you again.

I seem to have problems with both the service eca method and the chained request method.

The eca method seems to give me the triggering service's parameters. For eg, say I have a service 
B triggered on eca by service A. Service B will receive only the parameters passed to A. Ie, it 
seems that the invocation of service A:

1. Creates a local context that contains only the parameters that service A expects,

2. Passes this same local context on to service B.


The chained request method did not roll back the 1st service when an error is encountered in the 
2nd service.

In the 2nd service, I threw a deliberate error like this:

<add-error>
   <fail-message message="Deliberate error"/>
</add-error>
<check-errors/>

Maybe I didn't throw the error correctly?

The chained requests:

<request-map uri="UpdateRoutingTask">
     <security https="true" auth="true"/>
     <event type="service" invoke="updateWorkEffort"/>
     <response name="success" type="request" value="UpdateRoutingTaskPlusMore"/>
     <response name="error" type="view" value="EditRoutingTask"/>
</request-map>
<request-map uri="UpdateRoutingTaskPlusMore">
     <security https="true" auth="true"/>
     <event type="service" invoke="myOwn.updateWorkEffort"/>
     <response name="success" type="view" value="EditRoutingTask"/>
     <response name="error" type="view" value="EditRoutingTask"/>
</request-map>

Thanks for your time.

Jonathon

Jacopo Cappellato wrote:
> Jonathon -- Improov wrote:
>> Jacopo,
>>
>>  > 1) define a service eca (event-condition-action), there are many
>>  > examples of ecas in the servicedef/secas.xml files of many components)
>>  > attached to the updateWorkEffort service, to run your custom service
>>  > after it
>>
>> I tried this. But I had to modify the service input params for the 
>> original service updateWorkEffort.
>>
>> The reason is because the input params for my custom service is a 
>> larger superset of that for updateWorkEffort.
>>
> 
> If the additional parameters are available in the context (for example 
> posted by a form) they will be ignored by the updateWorkEffort service 
> and passed to your custom service only.
> 
>>  > 2) in the controller, create a chain of requests (where the first one
>>  > calls the updateWorkEffort, then the control is passed to a second one
>>  > that calls your custom service)
>>
>> This could be the best way I can see so far. Thanks!
>>
>> Oh wait. What about database transactional integrity? Say the 1st 
>> service succeeds, and the 2nd one fails, I would want the first one 
>> rolled back.
>>
> 
> Everything will be rolled back.
> 
> Jacopo
> 
>> Jonathon
>>
>> Jacopo Cappellato wrote:
>>> It really depends on the specificity of what you are doing but, in 
>>> general, there are probably simpler ways of doing this, such as:
>>>
>>> 1) define a service eca (event-condition-action), there are many 
>>> examples of ecas in the servicedef/secas.xml files of many 
>>> components) attached to the updateWorkEffort service, to run your 
>>> custom service after it
>>>
>>> 2) in the controller, create a chain of requests (where the first one 
>>> calls the updateWorkEffort, then the control is passed to a second 
>>> one that calls your custom service)
>>>
>>> etc...
>>>
>>> Jacopo
>>>
>>>
>>> Jonathon -- Improov wrote:
>>>> Chri,s
>>>>
>>>> Ok, here goes.
>>>>
>>>> I've deleted my <iterate-map> chunk, so the below is roughly from 
>>>> memory, untested.
>>>>
>>>> <iterate-map map-name="parameters" key-name="paramKey" 
>>>> value-name="paramValue">
>>>>  <if>
>>>>   <condition>
>>>>    <and>
>>>>     <if-compare field-name="paramKey" operator="not-equals" 
>>>> value="mySpecialCase1"/>
>>>>     <if-compare field-name="paramKey" operator="not-equals" 
>>>> value="mySpecialCase2"/>
>>>>    </and>
>>>>   <then>
>>>>    <!-- This somehow gives me all Strings in myOwnMap. -->
>>>>    <set from-field="parameters.${paramKey}" 
>>>> field="myOwnMap.${paramKey}"/>
>>>>    <!-- This somehow retains the correct data types in myCorrectMap. 
>>>> -->
>>>>    <field-to-field map-name="parameters" field-name="${paramKey}" 
>>>> to-map-name="myCorrectMap"/>
>>>>   </then>
>>>> </iterate-map>
>>>>
>>>> Here's what I really want audited. I'm trying to "extend" an 
>>>> existing service. I change the controller.xml to point to my "super 
>>>> service", which in turn calls the original service and also performs 
>>>> its own stuff. Pattern correct? I'm trying to achieve maximum 
>>>> separation of my customizations from core OFBiz.
>>>>
>>>> <simple-method method-name="myown.updateWorkEffort"
>>>>   short-description="Update Work Effort and then Work Instruction">
>>>>     <set-service-fields map-name="parameters" 
>>>> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>>>>     <call-service service-name="updateWorkEffort" 
>>>> in-map-name="updateWorkEffortParams">
>>>>         <default-message>Work Effort successfully 
>>>> updated.</default-message>
>>>>     </call-service>
>>>>     <check-errors/>
>>>>
>>>>     <!-- Do my own stuff here. Like updating entity NoteData, for 
>>>> eg. -->
>>>> </simple-method>
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> I'm sorry, again I'm not reading everything first.  You weren't asking
>>>>> how to do it, just if we should add the element.
>>>>>
>>>>> I would say that it's not generally needed as it's not a difficult
>>>>> operation, but I'm sure if someone went through the trouble of adding
>>>>> the logic, it would get added.
>>>>>
>>>>>
>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>
>>>>>> Yes, that snippet, I want to verify that you're using it correctly.
>>>>>>
>>>>>> Moving target:
>>>>>> to do a create or store you'll need to do an entity-one or
>>>>>> find-by-primary key and if it returns empty then create, otherwise
>>>>>> update the parameters and store
>>>>>>
>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>
>>>>>>> Chris,
>>>>>>>
>>>>>>>  > Send the code snippet that you're working on and I'll tweak it.
>>>>>>>
>>>>>>> Which snippet? You mean the <iterate-map> thing? Just create any
>>>>>> map
>>>>>>> with types other than String, then try to use <set> within 
>>>>>>> <iterate-map> to copy fields to a new
>>>>>>> map.
>>>>>>>
>>>>>>> Sorry another question! Sorry for moving target.
>>>>>>>
>>>>>>> I noticed there's no usage of delegator.createOrStore() in
>>>>>> Minilang.
>>>>>>> Is the true? Should we add something like <create-or-store-value>?
>>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>> Chris Howe wrote:
>>>>>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>>>>>
>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>
>>>>>>>>> Chris,
>>>>>>>>>
>>>>>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>>>>>> And
>>>>>>> the
>>>>>>>>> title is possibly irrelevant, since I can't find any reason now 
>>>>>>>>> to change
>>>>>>> <clear-field>
>>>>>>>>> after reading your recommendation.
>>>>>>>>>
>>>>>>>>> A question here about <iterate-map>, small digression. You can
>>>>>>> ignore
>>>>>>>>> it and ask for a new thread if you want.
>>>>>>>>>
>>>>>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>>>>>> that
>>>>>>> I
>>>>>>>>> could simply copy over from map "parameters" those fields that 
>>>>>>>>> are not in my own service.
>>>>>>>>>
>>>>>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>>>>>> couldn't get the fields' types (String, Double, etc) from 
>>>>>>>>> <iterate-map>.
>>>>>>>>>
>>>>>>>>> There's a warning about <field-to-field> being deprecated. Is
>>>>>>> there a
>>>>>>>>> need to enhance <iterate-map> to include "field type" in it's 
>>>>>>>>> results?
>>>>>>>>>
>>>>>>>>> Jonathon
>>>>>>>>>
>>>>>>>>> Chris Howe wrote:
>>>>>>>>>> sorry about the conjecture on screens/java...didn't read the
>>>>>>> title
>>>>>>>>> :-)
>>>>>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I'm not quite sure I'm following you as to which has the extra
>>>>>>>>>>> fields,
>>>>>>>>>>> your input map or the interface.
>>>>>>>>>>>
>>>>>>>>>>> I'm thinking your input map has the extra fields otherwise the
>>>>>>>>> extra
>>>>>>>>>>> fields in the interface would be optional, or you would likely
>>>>>>> end
>>>>>>>>> up
>>>>>>>>>>> with inconsistent result from the interface.
>>>>>>>>>>>
>>>>>>>>>>> So, assuming it's your input map and you would only be coming
>>>>>>>>> across
>>>>>>>>>>> this situation in simple-method because the screens->service
>>>>>>> picks
>>>>>>>>>>> the
>>>>>>>>>>> fields from context and java->service has you specify the map
>>>>>>>>>>> specifically.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So, if you're running this from simple-methods...you're
>>>>>>> solution,
>>>>>>>>> I
>>>>>>>>>>> believe, is the following
>>>>>>>>>>>
>>>>>>>>>>> <set-service-fields map-name="myInputMap"
>>>>>>> service-name="myService"
>>>>>>>>>>> to-map-name="inputMap"/>
>>>>>>>>>>> <call-service service-name="myService"
>>>>>> in-map-name="inputMap"/>
>>>>>>>>>>> Does that help?
>>>>>>>>>>>
>>>>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I can't find any usage of
>>>>>> ContextAccessor.remove(MethodContext)
>>>>>>>>> in
>>>>>>>>>>>> Minilang's source codes at 
>>>>>>>>>>>> src/org/ofbiz/minilang/method/envops .
>>>>>>>>>>>>
>>>>>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>>>>>> ContextAccessor.remove() rather than a ContextAccessor.put() 
>>>>>>>>>>>> that merely replaces a field with null?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm doing a custom service that <implements> an existing
>>>>>>> service
>>>>>>>>> in
>>>>>>>>>>>> OFBiz, and I need to trim away the extra input fields before 
>>>>>>>>>>>> putting them to the existing
>>>>>>>>> service.
>>>>>>>>>>>> Jonathon
>>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
> 
> 

How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field

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

Jonathon -- Improov wrote:
> Jacopo,
> 
>  > 1) define a service eca (event-condition-action), there are many
>  > examples of ecas in the servicedef/secas.xml files of many components)
>  > attached to the updateWorkEffort service, to run your custom service
>  > after it
> 
> I tried this. But I had to modify the service input params for the 
> original service updateWorkEffort.
> 
> The reason is because the input params for my custom service is a larger 
> superset of that for updateWorkEffort.
> 

If the additional parameters are available in the context (for example 
posted by a form) they will be ignored by the updateWorkEffort service 
and passed to your custom service only.

>  > 2) in the controller, create a chain of requests (where the first one
>  > calls the updateWorkEffort, then the control is passed to a second one
>  > that calls your custom service)
> 
> This could be the best way I can see so far. Thanks!
> 
> Oh wait. What about database transactional integrity? Say the 1st 
> service succeeds, and the 2nd one fails, I would want the first one 
> rolled back.
> 

Everything will be rolled back.

Jacopo

> Jonathon
> 
> Jacopo Cappellato wrote:
>> It really depends on the specificity of what you are doing but, in 
>> general, there are probably simpler ways of doing this, such as:
>>
>> 1) define a service eca (event-condition-action), there are many 
>> examples of ecas in the servicedef/secas.xml files of many components) 
>> attached to the updateWorkEffort service, to run your custom service 
>> after it
>>
>> 2) in the controller, create a chain of requests (where the first one 
>> calls the updateWorkEffort, then the control is passed to a second one 
>> that calls your custom service)
>>
>> etc...
>>
>> Jacopo
>>
>>
>> Jonathon -- Improov wrote:
>>> Chri,s
>>>
>>> Ok, here goes.
>>>
>>> I've deleted my <iterate-map> chunk, so the below is roughly from 
>>> memory, untested.
>>>
>>> <iterate-map map-name="parameters" key-name="paramKey" 
>>> value-name="paramValue">
>>>  <if>
>>>   <condition>
>>>    <and>
>>>     <if-compare field-name="paramKey" operator="not-equals" 
>>> value="mySpecialCase1"/>
>>>     <if-compare field-name="paramKey" operator="not-equals" 
>>> value="mySpecialCase2"/>
>>>    </and>
>>>   <then>
>>>    <!-- This somehow gives me all Strings in myOwnMap. -->
>>>    <set from-field="parameters.${paramKey}" 
>>> field="myOwnMap.${paramKey}"/>
>>>    <!-- This somehow retains the correct data types in myCorrectMap. -->
>>>    <field-to-field map-name="parameters" field-name="${paramKey}" 
>>> to-map-name="myCorrectMap"/>
>>>   </then>
>>> </iterate-map>
>>>
>>> Here's what I really want audited. I'm trying to "extend" an existing 
>>> service. I change the controller.xml to point to my "super service", 
>>> which in turn calls the original service and also performs its own 
>>> stuff. Pattern correct? I'm trying to achieve maximum separation of 
>>> my customizations from core OFBiz.
>>>
>>> <simple-method method-name="myown.updateWorkEffort"
>>>   short-description="Update Work Effort and then Work Instruction">
>>>     <set-service-fields map-name="parameters" 
>>> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>>>     <call-service service-name="updateWorkEffort" 
>>> in-map-name="updateWorkEffortParams">
>>>         <default-message>Work Effort successfully 
>>> updated.</default-message>
>>>     </call-service>
>>>     <check-errors/>
>>>
>>>     <!-- Do my own stuff here. Like updating entity NoteData, for eg. 
>>> -->
>>> </simple-method>
>>>
>>> Jonathon
>>>
>>> Chris Howe wrote:
>>>> I'm sorry, again I'm not reading everything first.  You weren't asking
>>>> how to do it, just if we should add the element.
>>>>
>>>> I would say that it's not generally needed as it's not a difficult
>>>> operation, but I'm sure if someone went through the trouble of adding
>>>> the logic, it would get added.
>>>>
>>>>
>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>
>>>>> Yes, that snippet, I want to verify that you're using it correctly.
>>>>>
>>>>> Moving target:
>>>>> to do a create or store you'll need to do an entity-one or
>>>>> find-by-primary key and if it returns empty then create, otherwise
>>>>> update the parameters and store
>>>>>
>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>>  > Send the code snippet that you're working on and I'll tweak it.
>>>>>>
>>>>>> Which snippet? You mean the <iterate-map> thing? Just create any
>>>>> map
>>>>>> with types other than String, then try to use <set> within 
>>>>>> <iterate-map> to copy fields to a new
>>>>>> map.
>>>>>>
>>>>>> Sorry another question! Sorry for moving target.
>>>>>>
>>>>>> I noticed there's no usage of delegator.createOrStore() in
>>>>> Minilang.
>>>>>> Is the true? Should we add something like <create-or-store-value>?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> Chris Howe wrote:
>>>>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>>>>
>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>
>>>>>>>> Chris,
>>>>>>>>
>>>>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>>>>> And
>>>>>> the
>>>>>>>> title is possibly irrelevant, since I can't find any reason now 
>>>>>>>> to change
>>>>>> <clear-field>
>>>>>>>> after reading your recommendation.
>>>>>>>>
>>>>>>>> A question here about <iterate-map>, small digression. You can
>>>>>> ignore
>>>>>>>> it and ask for a new thread if you want.
>>>>>>>>
>>>>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>>>>> that
>>>>>> I
>>>>>>>> could simply copy over from map "parameters" those fields that 
>>>>>>>> are not in my own service.
>>>>>>>>
>>>>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>>>>> couldn't get the fields' types (String, Double, etc) from 
>>>>>>>> <iterate-map>.
>>>>>>>>
>>>>>>>> There's a warning about <field-to-field> being deprecated. Is
>>>>>> there a
>>>>>>>> need to enhance <iterate-map> to include "field type" in it's 
>>>>>>>> results?
>>>>>>>>
>>>>>>>> Jonathon
>>>>>>>>
>>>>>>>> Chris Howe wrote:
>>>>>>>>> sorry about the conjecture on screens/java...didn't read the
>>>>>> title
>>>>>>>> :-)
>>>>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I'm not quite sure I'm following you as to which has the extra
>>>>>>>>>> fields,
>>>>>>>>>> your input map or the interface.
>>>>>>>>>>
>>>>>>>>>> I'm thinking your input map has the extra fields otherwise the
>>>>>>>> extra
>>>>>>>>>> fields in the interface would be optional, or you would likely
>>>>>> end
>>>>>>>> up
>>>>>>>>>> with inconsistent result from the interface.
>>>>>>>>>>
>>>>>>>>>> So, assuming it's your input map and you would only be coming
>>>>>>>> across
>>>>>>>>>> this situation in simple-method because the screens->service
>>>>>> picks
>>>>>>>>>> the
>>>>>>>>>> fields from context and java->service has you specify the map
>>>>>>>>>> specifically.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, if you're running this from simple-methods...you're
>>>>>> solution,
>>>>>>>> I
>>>>>>>>>> believe, is the following
>>>>>>>>>>
>>>>>>>>>> <set-service-fields map-name="myInputMap"
>>>>>> service-name="myService"
>>>>>>>>>> to-map-name="inputMap"/>
>>>>>>>>>> <call-service service-name="myService"
>>>>> in-map-name="inputMap"/>
>>>>>>>>>> Does that help?
>>>>>>>>>>
>>>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I can't find any usage of
>>>>> ContextAccessor.remove(MethodContext)
>>>>>>>> in
>>>>>>>>>>> Minilang's source codes at 
>>>>>>>>>>> src/org/ofbiz/minilang/method/envops .
>>>>>>>>>>>
>>>>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>>>>> ContextAccessor.remove() rather than a ContextAccessor.put() 
>>>>>>>>>>> that merely replaces a field with null?
>>>>>>>>>>>
>>>>>>>>>>> I'm doing a custom service that <implements> an existing
>>>>>> service
>>>>>>>> in
>>>>>>>>>>> OFBiz, and I need to trim away the extra input fields before 
>>>>>>>>>>> putting them to the existing
>>>>>>>> service.
>>>>>>>>>>> Jonathon
>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>

Re: Removing fields from a map in Minilang clear-field

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

Jacopo,

 > 1) define a service eca (event-condition-action), there are many
 > examples of ecas in the servicedef/secas.xml files of many components)
 > attached to the updateWorkEffort service, to run your custom service
 > after it

I tried this. But I had to modify the service input params for the original service updateWorkEffort.

The reason is because the input params for my custom service is a larger superset of that for 
updateWorkEffort.

 > 2) in the controller, create a chain of requests (where the first one
 > calls the updateWorkEffort, then the control is passed to a second one
 > that calls your custom service)

This could be the best way I can see so far. Thanks!

Oh wait. What about database transactional integrity? Say the 1st service succeeds, and the 2nd 
one fails, I would want the first one rolled back.

Jonathon

Jacopo Cappellato wrote:
> It really depends on the specificity of what you are doing but, in 
> general, there are probably simpler ways of doing this, such as:
> 
> 1) define a service eca (event-condition-action), there are many 
> examples of ecas in the servicedef/secas.xml files of many components) 
> attached to the updateWorkEffort service, to run your custom service 
> after it
> 
> 2) in the controller, create a chain of requests (where the first one 
> calls the updateWorkEffort, then the control is passed to a second one 
> that calls your custom service)
> 
> etc...
> 
> Jacopo
> 
> 
> Jonathon -- Improov wrote:
>> Chri,s
>>
>> Ok, here goes.
>>
>> I've deleted my <iterate-map> chunk, so the below is roughly from 
>> memory, untested.
>>
>> <iterate-map map-name="parameters" key-name="paramKey" 
>> value-name="paramValue">
>>  <if>
>>   <condition>
>>    <and>
>>     <if-compare field-name="paramKey" operator="not-equals" 
>> value="mySpecialCase1"/>
>>     <if-compare field-name="paramKey" operator="not-equals" 
>> value="mySpecialCase2"/>
>>    </and>
>>   <then>
>>    <!-- This somehow gives me all Strings in myOwnMap. -->
>>    <set from-field="parameters.${paramKey}" 
>> field="myOwnMap.${paramKey}"/>
>>    <!-- This somehow retains the correct data types in myCorrectMap. -->
>>    <field-to-field map-name="parameters" field-name="${paramKey}" 
>> to-map-name="myCorrectMap"/>
>>   </then>
>> </iterate-map>
>>
>> Here's what I really want audited. I'm trying to "extend" an existing 
>> service. I change the controller.xml to point to my "super service", 
>> which in turn calls the original service and also performs its own 
>> stuff. Pattern correct? I'm trying to achieve maximum separation of my 
>> customizations from core OFBiz.
>>
>> <simple-method method-name="myown.updateWorkEffort"
>>   short-description="Update Work Effort and then Work Instruction">
>>     <set-service-fields map-name="parameters" 
>> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>>     <call-service service-name="updateWorkEffort" 
>> in-map-name="updateWorkEffortParams">
>>         <default-message>Work Effort successfully 
>> updated.</default-message>
>>     </call-service>
>>     <check-errors/>
>>
>>     <!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
>> </simple-method>
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> I'm sorry, again I'm not reading everything first.  You weren't asking
>>> how to do it, just if we should add the element.
>>>
>>> I would say that it's not generally needed as it's not a difficult
>>> operation, but I'm sure if someone went through the trouble of adding
>>> the logic, it would get added.
>>>
>>>
>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>
>>>> Yes, that snippet, I want to verify that you're using it correctly.
>>>>
>>>> Moving target:
>>>> to do a create or store you'll need to do an entity-one or
>>>> find-by-primary key and if it returns empty then create, otherwise
>>>> update the parameters and store
>>>>
>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>>> Chris,
>>>>>
>>>>>  > Send the code snippet that you're working on and I'll tweak it.
>>>>>
>>>>> Which snippet? You mean the <iterate-map> thing? Just create any
>>>> map
>>>>> with types other than String, then try to use <set> within 
>>>>> <iterate-map> to copy fields to a new
>>>>> map.
>>>>>
>>>>> Sorry another question! Sorry for moving target.
>>>>>
>>>>> I noticed there's no usage of delegator.createOrStore() in
>>>> Minilang.
>>>>> Is the true? Should we add something like <create-or-store-value>?
>>>>>
>>>>> Jonathon
>>>>>
>>>>> Chris Howe wrote:
>>>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>>>
>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>
>>>>>>> Chris,
>>>>>>>
>>>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>>>> And
>>>>> the
>>>>>>> title is possibly irrelevant, since I can't find any reason now 
>>>>>>> to change
>>>>> <clear-field>
>>>>>>> after reading your recommendation.
>>>>>>>
>>>>>>> A question here about <iterate-map>, small digression. You can
>>>>> ignore
>>>>>>> it and ask for a new thread if you want.
>>>>>>>
>>>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>>>> that
>>>>> I
>>>>>>> could simply copy over from map "parameters" those fields that 
>>>>>>> are not in my own service.
>>>>>>>
>>>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>>>> couldn't get the fields' types (String, Double, etc) from 
>>>>>>> <iterate-map>.
>>>>>>>
>>>>>>> There's a warning about <field-to-field> being deprecated. Is
>>>>> there a
>>>>>>> need to enhance <iterate-map> to include "field type" in it's 
>>>>>>> results?
>>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>> Chris Howe wrote:
>>>>>>>> sorry about the conjecture on screens/java...didn't read the
>>>>> title
>>>>>>> :-)
>>>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> I'm not quite sure I'm following you as to which has the extra
>>>>>>>>> fields,
>>>>>>>>> your input map or the interface.
>>>>>>>>>
>>>>>>>>> I'm thinking your input map has the extra fields otherwise the
>>>>>>> extra
>>>>>>>>> fields in the interface would be optional, or you would likely
>>>>> end
>>>>>>> up
>>>>>>>>> with inconsistent result from the interface.
>>>>>>>>>
>>>>>>>>> So, assuming it's your input map and you would only be coming
>>>>>>> across
>>>>>>>>> this situation in simple-method because the screens->service
>>>>> picks
>>>>>>>>> the
>>>>>>>>> fields from context and java->service has you specify the map
>>>>>>>>> specifically.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, if you're running this from simple-methods...you're
>>>>> solution,
>>>>>>> I
>>>>>>>>> believe, is the following
>>>>>>>>>
>>>>>>>>> <set-service-fields map-name="myInputMap"
>>>>> service-name="myService"
>>>>>>>>> to-map-name="inputMap"/>
>>>>>>>>> <call-service service-name="myService"
>>>> in-map-name="inputMap"/>
>>>>>>>>> Does that help?
>>>>>>>>>
>>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>>
>>>>>>>>>> I can't find any usage of
>>>> ContextAccessor.remove(MethodContext)
>>>>>>> in
>>>>>>>>>> Minilang's source codes at src/org/ofbiz/minilang/method/envops .
>>>>>>>>>>
>>>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>>>> ContextAccessor.remove() rather than a ContextAccessor.put() 
>>>>>>>>>> that merely replaces a field with null?
>>>>>>>>>>
>>>>>>>>>> I'm doing a custom service that <implements> an existing
>>>>> service
>>>>>>> in
>>>>>>>>>> OFBiz, and I need to trim away the extra input fields before 
>>>>>>>>>> putting them to the existing
>>>>>>> service.
>>>>>>>>>> Jonathon
>>>>>>>>>>
>>>>>
>>>>
>>>
> 
> 

Re: Removing fields from a map in Minilang clear-field

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

It really depends on the specificity of what you are doing but, in 
general, there are probably simpler ways of doing this, such as:

1) define a service eca (event-condition-action), there are many 
examples of ecas in the servicedef/secas.xml files of many components) 
attached to the updateWorkEffort service, to run your custom service 
after it

2) in the controller, create a chain of requests (where the first one 
calls the updateWorkEffort, then the control is passed to a second one 
that calls your custom service)

etc...

Jacopo


Jonathon -- Improov wrote:
> Chri,s
> 
> Ok, here goes.
> 
> I've deleted my <iterate-map> chunk, so the below is roughly from 
> memory, untested.
> 
> <iterate-map map-name="parameters" key-name="paramKey" 
> value-name="paramValue">
>  <if>
>   <condition>
>    <and>
>     <if-compare field-name="paramKey" operator="not-equals" 
> value="mySpecialCase1"/>
>     <if-compare field-name="paramKey" operator="not-equals" 
> value="mySpecialCase2"/>
>    </and>
>   <then>
>    <!-- This somehow gives me all Strings in myOwnMap. -->
>    <set from-field="parameters.${paramKey}" field="myOwnMap.${paramKey}"/>
>    <!-- This somehow retains the correct data types in myCorrectMap. -->
>    <field-to-field map-name="parameters" field-name="${paramKey}" 
> to-map-name="myCorrectMap"/>
>   </then>
> </iterate-map>
> 
> Here's what I really want audited. I'm trying to "extend" an existing 
> service. I change the controller.xml to point to my "super service", 
> which in turn calls the original service and also performs its own 
> stuff. Pattern correct? I'm trying to achieve maximum separation of my 
> customizations from core OFBiz.
> 
> <simple-method method-name="myown.updateWorkEffort"
>   short-description="Update Work Effort and then Work Instruction">
>     <set-service-fields map-name="parameters" 
> service-name="updateWorkEffort" to-map-name="updateWorkEffortParams"/>
>     <call-service service-name="updateWorkEffort" 
> in-map-name="updateWorkEffortParams">
>         <default-message>Work Effort successfully 
> updated.</default-message>
>     </call-service>
>     <check-errors/>
> 
>     <!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
> </simple-method>
> 
> Jonathon
> 
> Chris Howe wrote:
>> I'm sorry, again I'm not reading everything first.  You weren't asking
>> how to do it, just if we should add the element.
>>
>> I would say that it's not generally needed as it's not a difficult
>> operation, but I'm sure if someone went through the trouble of adding
>> the logic, it would get added.
>>
>>
>> --- Chris Howe <cj...@yahoo.com> wrote:
>>
>>> Yes, that snippet, I want to verify that you're using it correctly.
>>>
>>> Moving target:
>>> to do a create or store you'll need to do an entity-one or
>>> find-by-primary key and if it returns empty then create, otherwise
>>> update the parameters and store
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> Chris,
>>>>
>>>>  > Send the code snippet that you're working on and I'll tweak it.
>>>>
>>>> Which snippet? You mean the <iterate-map> thing? Just create any
>>> map
>>>> with types other than String, then try to use <set> within 
>>>> <iterate-map> to copy fields to a new
>>>> map.
>>>>
>>>> Sorry another question! Sorry for moving target.
>>>>
>>>> I noticed there's no usage of delegator.createOrStore() in
>>> Minilang.
>>>> Is the true? Should we add something like <create-or-store-value>?
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>>
>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>
>>>>>> Chris,
>>>>>>
>>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>>> And
>>>> the
>>>>>> title is possibly irrelevant, since I can't find any reason now to 
>>>>>> change
>>>> <clear-field>
>>>>>> after reading your recommendation.
>>>>>>
>>>>>> A question here about <iterate-map>, small digression. You can
>>>> ignore
>>>>>> it and ask for a new thread if you want.
>>>>>>
>>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>>> that
>>>> I
>>>>>> could simply copy over from map "parameters" those fields that are 
>>>>>> not in my own service.
>>>>>>
>>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>>> couldn't get the fields' types (String, Double, etc) from 
>>>>>> <iterate-map>.
>>>>>>
>>>>>> There's a warning about <field-to-field> being deprecated. Is
>>>> there a
>>>>>> need to enhance <iterate-map> to include "field type" in it's 
>>>>>> results?
>>>>>>
>>>>>> Jonathon
>>>>>>
>>>>>> Chris Howe wrote:
>>>>>>> sorry about the conjecture on screens/java...didn't read the
>>>> title
>>>>>> :-)
>>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>>
>>>>>>>> I'm not quite sure I'm following you as to which has the extra
>>>>>>>> fields,
>>>>>>>> your input map or the interface.
>>>>>>>>
>>>>>>>> I'm thinking your input map has the extra fields otherwise the
>>>>>> extra
>>>>>>>> fields in the interface would be optional, or you would likely
>>>> end
>>>>>> up
>>>>>>>> with inconsistent result from the interface.
>>>>>>>>
>>>>>>>> So, assuming it's your input map and you would only be coming
>>>>>> across
>>>>>>>> this situation in simple-method because the screens->service
>>>> picks
>>>>>>>> the
>>>>>>>> fields from context and java->service has you specify the map
>>>>>>>> specifically.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, if you're running this from simple-methods...you're
>>>> solution,
>>>>>> I
>>>>>>>> believe, is the following
>>>>>>>>
>>>>>>>> <set-service-fields map-name="myInputMap"
>>>> service-name="myService"
>>>>>>>> to-map-name="inputMap"/>
>>>>>>>> <call-service service-name="myService"
>>> in-map-name="inputMap"/>
>>>>>>>> Does that help?
>>>>>>>>
>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>
>>>>>>>>> I can't find any usage of
>>> ContextAccessor.remove(MethodContext)
>>>>>> in
>>>>>>>>> Minilang's source codes at src/org/ofbiz/minilang/method/envops .
>>>>>>>>>
>>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>>> ContextAccessor.remove() rather than a ContextAccessor.put() 
>>>>>>>>> that merely replaces a field with null?
>>>>>>>>>
>>>>>>>>> I'm doing a custom service that <implements> an existing
>>>> service
>>>>>> in
>>>>>>>>> OFBiz, and I need to trim away the extra input fields before 
>>>>>>>>> putting them to the existing
>>>>>> service.
>>>>>>>>> Jonathon
>>>>>>>>>
>>>>
>>>
>>

Re: Removing fields from a map in Minilang clear-field

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

 > I'm not sure exactly what you're trying to do because what you put will
 > always return the same result unless your map named "parameter"
 > contains only 2 or less keys and one equals mySpecialCase1 and the
 > other equals mySpecialCase2, that's likely not what you're trying to
 > do.  If you could describe the real case instead of a hypothetical
 > case, it might be easier to offer assistance.

Map "parameters" contains many fields of different types.

I have a list of special keys that I want removed from "parameters".

This discussion about <iterate-map> might be irrelevant if it's determined that <clear-field> can 
have an option say 'remove="true"' to Map.remove() fields (not just Map.put(fieldName, null)).

Jonathon

Chris Howe wrote:
> Hey Jonathon,
> while I'm sure there are other uses of iterate-map, it's generally used
> when your keys have become variables themselves. Like if you wanted to
> group certain data by partyId and you were iterating through several
> different lists: ie
> 
> Iterate through List of Invoices
> <iterate entry-name="invoice" list-name="invoices">
> <field-to-list field-name="invoice"
> list-name="myMap.${invoice.partyId}.invoices"/>
> </iterate>
> Then iterate through List of orders
> <iterate entry-name="order" list-name="orders">
> <field-to-list field-name="order"
> list-name="myMap.${order.partyId}.orders"/>
> </iterate>
> Then iterate through list of payments
> <iterate entry-name="payment" list-name="payments">
> <field-to-list field-name="payment"
> list-name="myMap.${payment.partyId}.payments"/>
> </iterate>
> 
> This will result in the following 
> myMap.100.invoices
> myMap.100.orders
> myMap.100.payments
> myMap.101.invoices
> myMap.101.orders
> myMap.101.payments
> myMap.102.invoices
> myMap.102.orders
> myMap.102.payments
> myMap.103.invoices
> myMap.103.orders
> myMap.103.payments
> 
> So, now if you iterate-map through myMap
> <iterate-map map-name="myMap" key-name="key" value-name="value">
>  <set field="result.partyId" from-field="key"/>
>  <set field="result.invoices" from-field="value.invoices"/>
>  <set field="result.orders" from-field="value.orders"/>
>  <set field="result.payments" from-field="value.payments"/>
>  <field-to-list field-name="result" list-name="resultList"/>
> <clear-field field-name="result"/>
> <clear-field field-name="key"/>
> <clear-field field-name="value"/>
> </iterate-map>
> 
> 
> 
> I'm not sure exactly what you're trying to do because what you put will
> always return the same result unless your map named "parameter"
> contains only 2 or less keys and one equals mySpecialCase1 and the
> other equals mySpecialCase2, that's likely not what you're trying to
> do.  If you could describe the real case instead of a hypothetical
> case, it might be easier to offer assistance.
> 
> 
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> Chri,s
>>
>> Ok, here goes.
>>
>> I've deleted my <iterate-map> chunk, so the below is roughly from
>> memory, untested.
>>
>> <iterate-map map-name="parameters" key-name="paramKey"
>> value-name="paramValue">
>>   <if>
>>    <condition>
>>     <and>
>>      <if-compare field-name="paramKey" operator="not-equals"
>> value="mySpecialCase1"/>
>>      <if-compare field-name="paramKey" operator="not-equals"
>> value="mySpecialCase2"/>
>>     </and>
>>    <then>
>>     <!-- This somehow gives me all Strings in myOwnMap. -->
>>     <set from-field="parameters.${paramKey}"
>> field="myOwnMap.${paramKey}"/>
>>     <!-- This somehow retains the correct data types in myCorrectMap.
>> -->
>>     <field-to-field map-name="parameters" field-name="${paramKey}"
>> to-map-name="myCorrectMap"/>
>>    </then>
>> </iterate-map>
>>
>> Here's what I really want audited. I'm trying to "extend" an existing
>> service. I change the 
>> controller.xml to point to my "super service", which in turn calls
>> the original service and also 
>> performs its own stuff. Pattern correct? I'm trying to achieve
>> maximum separation of my 
>> customizations from core OFBiz.
>>
>> <simple-method method-name="myown.updateWorkEffort"
>>    short-description="Update Work Effort and then Work Instruction">
>>      <set-service-fields map-name="parameters"
>> service-name="updateWorkEffort" 
>> to-map-name="updateWorkEffortParams"/>
>>      <call-service service-name="updateWorkEffort"
>> in-map-name="updateWorkEffortParams">
>>          <default-message>Work Effort successfully
>> updated.</default-message>
>>      </call-service>
>>      <check-errors/>
>>
>>      <!-- Do my own stuff here. Like updating entity NoteData, for
>> eg. -->
>> </simple-method>
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> I'm sorry, again I'm not reading everything first.  You weren't
>> asking
>>> how to do it, just if we should add the element.
>>>
>>> I would say that it's not generally needed as it's not a difficult
>>> operation, but I'm sure if someone went through the trouble of
>> adding
>>> the logic, it would get added.
>>>
>>>
>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>
>>>> Yes, that snippet, I want to verify that you're using it
>> correctly.
>>>> Moving target:
>>>> to do a create or store you'll need to do an entity-one or
>>>> find-by-primary key and if it returns empty then create, otherwise
>>>> update the parameters and store
>>>>
>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>>> Chris,
>>>>>
>>>>>  > Send the code snippet that you're working on and I'll tweak
>> it.
>>>>> Which snippet? You mean the <iterate-map> thing? Just create any
>>>> map
>>>>> with types other than String, 
>>>>> then try to use <set> within <iterate-map> to copy fields to a
>> new
>>>>> map.
>>>>>
>>>>> Sorry another question! Sorry for moving target.
>>>>>
>>>>> I noticed there's no usage of delegator.createOrStore() in
>>>> Minilang.
>>>>> Is the true? Should we add 
>>>>> something like <create-or-store-value>?
>>>>>
>>>>> Jonathon
>>>>>
>>>>> Chris Howe wrote:
>>>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>>>
>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>
>>>>>>> Chris,
>>>>>>>
>>>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>>>> And
>>>>> the
>>>>>>> title is possibly 
>>>>>>> irrelevant, since I can't find any reason now to change
>>>>> <clear-field>
>>>>>>> after reading your 
>>>>>>> recommendation.
>>>>>>>
>>>>>>> A question here about <iterate-map>, small digression. You can
>>>>> ignore
>>>>>>> it and ask for a new thread 
>>>>>>> if you want.
>>>>>>>
>>>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>>>> that
>>>>> I
>>>>>>> could simply copy over from 
>>>>>>> map "parameters" those fields that are not in my own service.
>>>>>>>
>>>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>>>> couldn't get the fields' types 
>>>>>>> (String, Double, etc) from <iterate-map>.
>>>>>>>
>>>>>>> There's a warning about <field-to-field> being deprecated. Is
>>>>> there a
>>>>>>> need to enhance 
>>>>>>> <iterate-map> to include "field type" in it's results?
>>>>>>>
>>>>>>> Jonathon
>>>>>>>
>>>>>>> Chris Howe wrote:
>>>>>>>> sorry about the conjecture on screens/java...didn't read the
>>>>> title
>>>>>>> :-)
>>>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> I'm not quite sure I'm following you as to which has the
>> extra
>>>>>>>>> fields,
>>>>>>>>> your input map or the interface.
>>>>>>>>>
>>>>>>>>> I'm thinking your input map has the extra fields otherwise
>> the
>>>>>>> extra
>>>>>>>>> fields in the interface would be optional, or you would
>> likely
>>>>> end
>>>>>>> up
>>>>>>>>> with inconsistent result from the interface.
>>>>>>>>>
>>>>>>>>> So, assuming it's your input map and you would only be coming
>>>>>>> across
>>>>>>>>> this situation in simple-method because the screens->service
>>>>> picks
>>>>>>>>> the
>>>>>>>>> fields from context and java->service has you specify the map
>>>>>>>>> specifically.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, if you're running this from simple-methods...you're
>>>>> solution,
>>>>>>> I
>>>>>>>>> believe, is the following
>>>>>>>>>
>>>>>>>>> <set-service-fields map-name="myInputMap"
>>>>> service-name="myService"
>>>>>>>>> to-map-name="inputMap"/>
>>>>>>>>> <call-service service-name="myService"
>>>> in-map-name="inputMap"/>
>>>>>>>>> Does that help?
>>>>>>>>>
>>>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>>>
>>>>>>>>>> I can't find any usage of
>>>> ContextAccessor.remove(MethodContext)
>>>>>>> in
>>>>>>>>>> Minilang's source codes at 
>>>>>>>>>> src/org/ofbiz/minilang/method/envops .
>>>>>>>>>>
>>>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>>>> ContextAccessor.remove() rather than a 
>>>>>>>>>> ContextAccessor.put() that merely replaces a field with
>> null?
>>>>>>>>>> I'm doing a custom service that <implements> an existing
>>>>> service
>>>>>>> in
>>>>>>>>>> OFBiz, and I need to trim away 
>>>>>>>>>> the extra input fields before putting them to the existing
>>>>>>> service.
>>>>>>>>>> Jonathon
>>>>>>>>>>
> === message truncated ===
> 

Re: Removing fields from a map in Minilang clear-field

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

Hey Jonathon,
while I'm sure there are other uses of iterate-map, it's generally used
when your keys have become variables themselves. Like if you wanted to
group certain data by partyId and you were iterating through several
different lists: ie

Iterate through List of Invoices
<iterate entry-name="invoice" list-name="invoices">
<field-to-list field-name="invoice"
list-name="myMap.${invoice.partyId}.invoices"/>
</iterate>
Then iterate through List of orders
<iterate entry-name="order" list-name="orders">
<field-to-list field-name="order"
list-name="myMap.${order.partyId}.orders"/>
</iterate>
Then iterate through list of payments
<iterate entry-name="payment" list-name="payments">
<field-to-list field-name="payment"
list-name="myMap.${payment.partyId}.payments"/>
</iterate>

This will result in the following 
myMap.100.invoices
myMap.100.orders
myMap.100.payments
myMap.101.invoices
myMap.101.orders
myMap.101.payments
myMap.102.invoices
myMap.102.orders
myMap.102.payments
myMap.103.invoices
myMap.103.orders
myMap.103.payments

So, now if you iterate-map through myMap
<iterate-map map-name="myMap" key-name="key" value-name="value">
 <set field="result.partyId" from-field="key"/>
 <set field="result.invoices" from-field="value.invoices"/>
 <set field="result.orders" from-field="value.orders"/>
 <set field="result.payments" from-field="value.payments"/>
 <field-to-list field-name="result" list-name="resultList"/>
<clear-field field-name="result"/>
<clear-field field-name="key"/>
<clear-field field-name="value"/>
</iterate-map>



I'm not sure exactly what you're trying to do because what you put will
always return the same result unless your map named "parameter"
contains only 2 or less keys and one equals mySpecialCase1 and the
other equals mySpecialCase2, that's likely not what you're trying to
do.  If you could describe the real case instead of a hypothetical
case, it might be easier to offer assistance.



--- Jonathon -- Improov <jo...@improov.com> wrote:

> Chri,s
> 
> Ok, here goes.
> 
> I've deleted my <iterate-map> chunk, so the below is roughly from
> memory, untested.
> 
> <iterate-map map-name="parameters" key-name="paramKey"
> value-name="paramValue">
>   <if>
>    <condition>
>     <and>
>      <if-compare field-name="paramKey" operator="not-equals"
> value="mySpecialCase1"/>
>      <if-compare field-name="paramKey" operator="not-equals"
> value="mySpecialCase2"/>
>     </and>
>    <then>
>     <!-- This somehow gives me all Strings in myOwnMap. -->
>     <set from-field="parameters.${paramKey}"
> field="myOwnMap.${paramKey}"/>
>     <!-- This somehow retains the correct data types in myCorrectMap.
> -->
>     <field-to-field map-name="parameters" field-name="${paramKey}"
> to-map-name="myCorrectMap"/>
>    </then>
> </iterate-map>
> 
> Here's what I really want audited. I'm trying to "extend" an existing
> service. I change the 
> controller.xml to point to my "super service", which in turn calls
> the original service and also 
> performs its own stuff. Pattern correct? I'm trying to achieve
> maximum separation of my 
> customizations from core OFBiz.
> 
> <simple-method method-name="myown.updateWorkEffort"
>    short-description="Update Work Effort and then Work Instruction">
>      <set-service-fields map-name="parameters"
> service-name="updateWorkEffort" 
> to-map-name="updateWorkEffortParams"/>
>      <call-service service-name="updateWorkEffort"
> in-map-name="updateWorkEffortParams">
>          <default-message>Work Effort successfully
> updated.</default-message>
>      </call-service>
>      <check-errors/>
> 
>      <!-- Do my own stuff here. Like updating entity NoteData, for
> eg. -->
> </simple-method>
> 
> Jonathon
> 
> Chris Howe wrote:
> > I'm sorry, again I'm not reading everything first.  You weren't
> asking
> > how to do it, just if we should add the element.
> > 
> > I would say that it's not generally needed as it's not a difficult
> > operation, but I'm sure if someone went through the trouble of
> adding
> > the logic, it would get added.
> > 
> > 
> > --- Chris Howe <cj...@yahoo.com> wrote:
> > 
> >> Yes, that snippet, I want to verify that you're using it
> correctly.
> >>
> >> Moving target:
> >> to do a create or store you'll need to do an entity-one or
> >> find-by-primary key and if it returns empty then create, otherwise
> >> update the parameters and store
> >>
> >> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>
> >>> Chris,
> >>>
> >>>  > Send the code snippet that you're working on and I'll tweak
> it.
> >>>
> >>> Which snippet? You mean the <iterate-map> thing? Just create any
> >> map
> >>> with types other than String, 
> >>> then try to use <set> within <iterate-map> to copy fields to a
> new
> >>> map.
> >>>
> >>> Sorry another question! Sorry for moving target.
> >>>
> >>> I noticed there's no usage of delegator.createOrStore() in
> >> Minilang.
> >>> Is the true? Should we add 
> >>> something like <create-or-store-value>?
> >>>
> >>> Jonathon
> >>>
> >>> Chris Howe wrote:
> >>>> Send the code snippet that you're working on and I'll tweak it.
> >>>>
> >>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>>>
> >>>>> Chris,
> >>>>>
> >>>>> Never mind the conjecture. Your recommendation works! Thanks!
> >> And
> >>> the
> >>>>> title is possibly 
> >>>>> irrelevant, since I can't find any reason now to change
> >>> <clear-field>
> >>>>> after reading your 
> >>>>> recommendation.
> >>>>>
> >>>>> A question here about <iterate-map>, small digression. You can
> >>> ignore
> >>>>> it and ask for a new thread 
> >>>>> if you want.
> >>>>>
> >>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
> >> that
> >>> I
> >>>>> could simply copy over from 
> >>>>> map "parameters" those fields that are not in my own service.
> >>>>>
> >>>>> Using <set> instead of <field-to-field> doesn't work, because I
> >>>>> couldn't get the fields' types 
> >>>>> (String, Double, etc) from <iterate-map>.
> >>>>>
> >>>>> There's a warning about <field-to-field> being deprecated. Is
> >>> there a
> >>>>> need to enhance 
> >>>>> <iterate-map> to include "field type" in it's results?
> >>>>>
> >>>>> Jonathon
> >>>>>
> >>>>> Chris Howe wrote:
> >>>>>> sorry about the conjecture on screens/java...didn't read the
> >>> title
> >>>>> :-)
> >>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
> >>>>>>
> >>>>>>> I'm not quite sure I'm following you as to which has the
> extra
> >>>>>>> fields,
> >>>>>>> your input map or the interface.
> >>>>>>>
> >>>>>>> I'm thinking your input map has the extra fields otherwise
> the
> >>>>> extra
> >>>>>>> fields in the interface would be optional, or you would
> likely
> >>> end
> >>>>> up
> >>>>>>> with inconsistent result from the interface.
> >>>>>>>
> >>>>>>> So, assuming it's your input map and you would only be coming
> >>>>> across
> >>>>>>> this situation in simple-method because the screens->service
> >>> picks
> >>>>>>> the
> >>>>>>> fields from context and java->service has you specify the map
> >>>>>>> specifically.
> >>>>>>>
> >>>>>>>
> >>>>>>> So, if you're running this from simple-methods...you're
> >>> solution,
> >>>>> I
> >>>>>>> believe, is the following
> >>>>>>>
> >>>>>>> <set-service-fields map-name="myInputMap"
> >>> service-name="myService"
> >>>>>>> to-map-name="inputMap"/>
> >>>>>>> <call-service service-name="myService"
> >> in-map-name="inputMap"/>
> >>>>>>> Does that help?
> >>>>>>>
> >>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>>>>>>
> >>>>>>>> I can't find any usage of
> >> ContextAccessor.remove(MethodContext)
> >>>>> in
> >>>>>>>> Minilang's source codes at 
> >>>>>>>> src/org/ofbiz/minilang/method/envops .
> >>>>>>>>
> >>>>>>>> Shall I add an option to <clear-field> that will trigger a
> >>>>>>>> ContextAccessor.remove() rather than a 
> >>>>>>>> ContextAccessor.put() that merely replaces a field with
> null?
> >>>>>>>>
> >>>>>>>> I'm doing a custom service that <implements> an existing
> >>> service
> >>>>> in
> >>>>>>>> OFBiz, and I need to trim away 
> >>>>>>>> the extra input fields before putting them to the existing
> >>>>> service.
> >>>>>>>> Jonathon
> >>>>>>>>
> >>>
> >>
> > 
> 
=== message truncated ===

Re: Removing fields from a map in Minilang clear-field

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

Chri,s

Ok, here goes.

I've deleted my <iterate-map> chunk, so the below is roughly from memory, untested.

<iterate-map map-name="parameters" key-name="paramKey" value-name="paramValue">
  <if>
   <condition>
    <and>
     <if-compare field-name="paramKey" operator="not-equals" value="mySpecialCase1"/>
     <if-compare field-name="paramKey" operator="not-equals" value="mySpecialCase2"/>
    </and>
   <then>
    <!-- This somehow gives me all Strings in myOwnMap. -->
    <set from-field="parameters.${paramKey}" field="myOwnMap.${paramKey}"/>
    <!-- This somehow retains the correct data types in myCorrectMap. -->
    <field-to-field map-name="parameters" field-name="${paramKey}" to-map-name="myCorrectMap"/>
   </then>
</iterate-map>

Here's what I really want audited. I'm trying to "extend" an existing service. I change the 
controller.xml to point to my "super service", which in turn calls the original service and also 
performs its own stuff. Pattern correct? I'm trying to achieve maximum separation of my 
customizations from core OFBiz.

<simple-method method-name="myown.updateWorkEffort"
   short-description="Update Work Effort and then Work Instruction">
     <set-service-fields map-name="parameters" service-name="updateWorkEffort" 
to-map-name="updateWorkEffortParams"/>
     <call-service service-name="updateWorkEffort" in-map-name="updateWorkEffortParams">
         <default-message>Work Effort successfully updated.</default-message>
     </call-service>
     <check-errors/>

     <!-- Do my own stuff here. Like updating entity NoteData, for eg. -->
</simple-method>

Jonathon

Chris Howe wrote:
> I'm sorry, again I'm not reading everything first.  You weren't asking
> how to do it, just if we should add the element.
> 
> I would say that it's not generally needed as it's not a difficult
> operation, but I'm sure if someone went through the trouble of adding
> the logic, it would get added.
> 
> 
> --- Chris Howe <cj...@yahoo.com> wrote:
> 
>> Yes, that snippet, I want to verify that you're using it correctly.
>>
>> Moving target:
>> to do a create or store you'll need to do an entity-one or
>> find-by-primary key and if it returns empty then create, otherwise
>> update the parameters and store
>>
>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>
>>> Chris,
>>>
>>>  > Send the code snippet that you're working on and I'll tweak it.
>>>
>>> Which snippet? You mean the <iterate-map> thing? Just create any
>> map
>>> with types other than String, 
>>> then try to use <set> within <iterate-map> to copy fields to a new
>>> map.
>>>
>>> Sorry another question! Sorry for moving target.
>>>
>>> I noticed there's no usage of delegator.createOrStore() in
>> Minilang.
>>> Is the true? Should we add 
>>> something like <create-or-store-value>?
>>>
>>> Jonathon
>>>
>>> Chris Howe wrote:
>>>> Send the code snippet that you're working on and I'll tweak it.
>>>>
>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>>> Chris,
>>>>>
>>>>> Never mind the conjecture. Your recommendation works! Thanks!
>> And
>>> the
>>>>> title is possibly 
>>>>> irrelevant, since I can't find any reason now to change
>>> <clear-field>
>>>>> after reading your 
>>>>> recommendation.
>>>>>
>>>>> A question here about <iterate-map>, small digression. You can
>>> ignore
>>>>> it and ask for a new thread 
>>>>> if you want.
>>>>>
>>>>> I was doing it via <iterate-map>, <if>, <field-to-field>, so
>> that
>>> I
>>>>> could simply copy over from 
>>>>> map "parameters" those fields that are not in my own service.
>>>>>
>>>>> Using <set> instead of <field-to-field> doesn't work, because I
>>>>> couldn't get the fields' types 
>>>>> (String, Double, etc) from <iterate-map>.
>>>>>
>>>>> There's a warning about <field-to-field> being deprecated. Is
>>> there a
>>>>> need to enhance 
>>>>> <iterate-map> to include "field type" in it's results?
>>>>>
>>>>> Jonathon
>>>>>
>>>>> Chris Howe wrote:
>>>>>> sorry about the conjecture on screens/java...didn't read the
>>> title
>>>>> :-)
>>>>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>>>>
>>>>>>> I'm not quite sure I'm following you as to which has the extra
>>>>>>> fields,
>>>>>>> your input map or the interface.
>>>>>>>
>>>>>>> I'm thinking your input map has the extra fields otherwise the
>>>>> extra
>>>>>>> fields in the interface would be optional, or you would likely
>>> end
>>>>> up
>>>>>>> with inconsistent result from the interface.
>>>>>>>
>>>>>>> So, assuming it's your input map and you would only be coming
>>>>> across
>>>>>>> this situation in simple-method because the screens->service
>>> picks
>>>>>>> the
>>>>>>> fields from context and java->service has you specify the map
>>>>>>> specifically.
>>>>>>>
>>>>>>>
>>>>>>> So, if you're running this from simple-methods...you're
>>> solution,
>>>>> I
>>>>>>> believe, is the following
>>>>>>>
>>>>>>> <set-service-fields map-name="myInputMap"
>>> service-name="myService"
>>>>>>> to-map-name="inputMap"/>
>>>>>>> <call-service service-name="myService"
>> in-map-name="inputMap"/>
>>>>>>> Does that help?
>>>>>>>
>>>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>>>
>>>>>>>> I can't find any usage of
>> ContextAccessor.remove(MethodContext)
>>>>> in
>>>>>>>> Minilang's source codes at 
>>>>>>>> src/org/ofbiz/minilang/method/envops .
>>>>>>>>
>>>>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>>>>> ContextAccessor.remove() rather than a 
>>>>>>>> ContextAccessor.put() that merely replaces a field with null?
>>>>>>>>
>>>>>>>> I'm doing a custom service that <implements> an existing
>>> service
>>>>> in
>>>>>>>> OFBiz, and I need to trim away 
>>>>>>>> the extra input fields before putting them to the existing
>>>>> service.
>>>>>>>> Jonathon
>>>>>>>>
>>>
>>
> 

Re: Removing fields from a map in Minilang clear-field

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

I'm sorry, again I'm not reading everything first.  You weren't asking
how to do it, just if we should add the element.

I would say that it's not generally needed as it's not a difficult
operation, but I'm sure if someone went through the trouble of adding
the logic, it would get added.


--- Chris Howe <cj...@yahoo.com> wrote:

> Yes, that snippet, I want to verify that you're using it correctly.
> 
> Moving target:
> to do a create or store you'll need to do an entity-one or
> find-by-primary key and if it returns empty then create, otherwise
> update the parameters and store
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
> > Chris,
> > 
> >  > Send the code snippet that you're working on and I'll tweak it.
> > 
> > Which snippet? You mean the <iterate-map> thing? Just create any
> map
> > with types other than String, 
> > then try to use <set> within <iterate-map> to copy fields to a new
> > map.
> > 
> > Sorry another question! Sorry for moving target.
> > 
> > I noticed there's no usage of delegator.createOrStore() in
> Minilang.
> > Is the true? Should we add 
> > something like <create-or-store-value>?
> > 
> > Jonathon
> > 
> > Chris Howe wrote:
> > > Send the code snippet that you're working on and I'll tweak it.
> > > 
> > > --- Jonathon -- Improov <jo...@improov.com> wrote:
> > > 
> > >> Chris,
> > >>
> > >> Never mind the conjecture. Your recommendation works! Thanks!
> And
> > the
> > >> title is possibly 
> > >> irrelevant, since I can't find any reason now to change
> > <clear-field>
> > >> after reading your 
> > >> recommendation.
> > >>
> > >> A question here about <iterate-map>, small digression. You can
> > ignore
> > >> it and ask for a new thread 
> > >> if you want.
> > >>
> > >> I was doing it via <iterate-map>, <if>, <field-to-field>, so
> that
> > I
> > >> could simply copy over from 
> > >> map "parameters" those fields that are not in my own service.
> > >>
> > >> Using <set> instead of <field-to-field> doesn't work, because I
> > >> couldn't get the fields' types 
> > >> (String, Double, etc) from <iterate-map>.
> > >>
> > >> There's a warning about <field-to-field> being deprecated. Is
> > there a
> > >> need to enhance 
> > >> <iterate-map> to include "field type" in it's results?
> > >>
> > >> Jonathon
> > >>
> > >> Chris Howe wrote:
> > >>> sorry about the conjecture on screens/java...didn't read the
> > title
> > >> :-)
> > >>> --- Chris Howe <cj...@yahoo.com> wrote:
> > >>>
> > >>>> I'm not quite sure I'm following you as to which has the extra
> > >>>> fields,
> > >>>> your input map or the interface.
> > >>>>
> > >>>> I'm thinking your input map has the extra fields otherwise the
> > >> extra
> > >>>> fields in the interface would be optional, or you would likely
> > end
> > >> up
> > >>>> with inconsistent result from the interface.
> > >>>>
> > >>>> So, assuming it's your input map and you would only be coming
> > >> across
> > >>>> this situation in simple-method because the screens->service
> > picks
> > >>>> the
> > >>>> fields from context and java->service has you specify the map
> > >>>> specifically.
> > >>>>
> > >>>>
> > >>>> So, if you're running this from simple-methods...you're
> > solution,
> > >> I
> > >>>> believe, is the following
> > >>>>
> > >>>> <set-service-fields map-name="myInputMap"
> > service-name="myService"
> > >>>> to-map-name="inputMap"/>
> > >>>> <call-service service-name="myService"
> in-map-name="inputMap"/>
> > >>>>
> > >>>> Does that help?
> > >>>>
> > >>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
> > >>>>
> > >>>>> I can't find any usage of
> ContextAccessor.remove(MethodContext)
> > >> in
> > >>>>> Minilang's source codes at 
> > >>>>> src/org/ofbiz/minilang/method/envops .
> > >>>>>
> > >>>>> Shall I add an option to <clear-field> that will trigger a
> > >>>>> ContextAccessor.remove() rather than a 
> > >>>>> ContextAccessor.put() that merely replaces a field with null?
> > >>>>>
> > >>>>> I'm doing a custom service that <implements> an existing
> > service
> > >> in
> > >>>>> OFBiz, and I need to trim away 
> > >>>>> the extra input fields before putting them to the existing
> > >> service.
> > >>>>> Jonathon
> > >>>>>
> > >>
> > > 
> > 
> > 
> 
> 

Re: Removing fields from a map in Minilang clear-field

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

Yes, that snippet, I want to verify that you're using it correctly.

Moving target:
to do a create or store you'll need to do an entity-one or
find-by-primary key and if it returns empty then create, otherwise
update the parameters and store

--- Jonathon -- Improov <jo...@improov.com> wrote:

> Chris,
> 
>  > Send the code snippet that you're working on and I'll tweak it.
> 
> Which snippet? You mean the <iterate-map> thing? Just create any map
> with types other than String, 
> then try to use <set> within <iterate-map> to copy fields to a new
> map.
> 
> Sorry another question! Sorry for moving target.
> 
> I noticed there's no usage of delegator.createOrStore() in Minilang.
> Is the true? Should we add 
> something like <create-or-store-value>?
> 
> Jonathon
> 
> Chris Howe wrote:
> > Send the code snippet that you're working on and I'll tweak it.
> > 
> > --- Jonathon -- Improov <jo...@improov.com> wrote:
> > 
> >> Chris,
> >>
> >> Never mind the conjecture. Your recommendation works! Thanks! And
> the
> >> title is possibly 
> >> irrelevant, since I can't find any reason now to change
> <clear-field>
> >> after reading your 
> >> recommendation.
> >>
> >> A question here about <iterate-map>, small digression. You can
> ignore
> >> it and ask for a new thread 
> >> if you want.
> >>
> >> I was doing it via <iterate-map>, <if>, <field-to-field>, so that
> I
> >> could simply copy over from 
> >> map "parameters" those fields that are not in my own service.
> >>
> >> Using <set> instead of <field-to-field> doesn't work, because I
> >> couldn't get the fields' types 
> >> (String, Double, etc) from <iterate-map>.
> >>
> >> There's a warning about <field-to-field> being deprecated. Is
> there a
> >> need to enhance 
> >> <iterate-map> to include "field type" in it's results?
> >>
> >> Jonathon
> >>
> >> Chris Howe wrote:
> >>> sorry about the conjecture on screens/java...didn't read the
> title
> >> :-)
> >>> --- Chris Howe <cj...@yahoo.com> wrote:
> >>>
> >>>> I'm not quite sure I'm following you as to which has the extra
> >>>> fields,
> >>>> your input map or the interface.
> >>>>
> >>>> I'm thinking your input map has the extra fields otherwise the
> >> extra
> >>>> fields in the interface would be optional, or you would likely
> end
> >> up
> >>>> with inconsistent result from the interface.
> >>>>
> >>>> So, assuming it's your input map and you would only be coming
> >> across
> >>>> this situation in simple-method because the screens->service
> picks
> >>>> the
> >>>> fields from context and java->service has you specify the map
> >>>> specifically.
> >>>>
> >>>>
> >>>> So, if you're running this from simple-methods...you're
> solution,
> >> I
> >>>> believe, is the following
> >>>>
> >>>> <set-service-fields map-name="myInputMap"
> service-name="myService"
> >>>> to-map-name="inputMap"/>
> >>>> <call-service service-name="myService" in-map-name="inputMap"/>
> >>>>
> >>>> Does that help?
> >>>>
> >>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>>>
> >>>>> I can't find any usage of ContextAccessor.remove(MethodContext)
> >> in
> >>>>> Minilang's source codes at 
> >>>>> src/org/ofbiz/minilang/method/envops .
> >>>>>
> >>>>> Shall I add an option to <clear-field> that will trigger a
> >>>>> ContextAccessor.remove() rather than a 
> >>>>> ContextAccessor.put() that merely replaces a field with null?
> >>>>>
> >>>>> I'm doing a custom service that <implements> an existing
> service
> >> in
> >>>>> OFBiz, and I need to trim away 
> >>>>> the extra input fields before putting them to the existing
> >> service.
> >>>>> Jonathon
> >>>>>
> >>
> > 
> 
> 

Re: Removing fields from a map in Minilang clear-field

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

Chris,

 > Send the code snippet that you're working on and I'll tweak it.

Which snippet? You mean the <iterate-map> thing? Just create any map with types other than String, 
then try to use <set> within <iterate-map> to copy fields to a new map.

Sorry another question! Sorry for moving target.

I noticed there's no usage of delegator.createOrStore() in Minilang. Is the true? Should we add 
something like <create-or-store-value>?

Jonathon

Chris Howe wrote:
> Send the code snippet that you're working on and I'll tweak it.
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> Chris,
>>
>> Never mind the conjecture. Your recommendation works! Thanks! And the
>> title is possibly 
>> irrelevant, since I can't find any reason now to change <clear-field>
>> after reading your 
>> recommendation.
>>
>> A question here about <iterate-map>, small digression. You can ignore
>> it and ask for a new thread 
>> if you want.
>>
>> I was doing it via <iterate-map>, <if>, <field-to-field>, so that I
>> could simply copy over from 
>> map "parameters" those fields that are not in my own service.
>>
>> Using <set> instead of <field-to-field> doesn't work, because I
>> couldn't get the fields' types 
>> (String, Double, etc) from <iterate-map>.
>>
>> There's a warning about <field-to-field> being deprecated. Is there a
>> need to enhance 
>> <iterate-map> to include "field type" in it's results?
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> sorry about the conjecture on screens/java...didn't read the title
>> :-)
>>> --- Chris Howe <cj...@yahoo.com> wrote:
>>>
>>>> I'm not quite sure I'm following you as to which has the extra
>>>> fields,
>>>> your input map or the interface.
>>>>
>>>> I'm thinking your input map has the extra fields otherwise the
>> extra
>>>> fields in the interface would be optional, or you would likely end
>> up
>>>> with inconsistent result from the interface.
>>>>
>>>> So, assuming it's your input map and you would only be coming
>> across
>>>> this situation in simple-method because the screens->service picks
>>>> the
>>>> fields from context and java->service has you specify the map
>>>> specifically.
>>>>
>>>>
>>>> So, if you're running this from simple-methods...you're solution,
>> I
>>>> believe, is the following
>>>>
>>>> <set-service-fields map-name="myInputMap" service-name="myService"
>>>> to-map-name="inputMap"/>
>>>> <call-service service-name="myService" in-map-name="inputMap"/>
>>>>
>>>> Does that help?
>>>>
>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>>> I can't find any usage of ContextAccessor.remove(MethodContext)
>> in
>>>>> Minilang's source codes at 
>>>>> src/org/ofbiz/minilang/method/envops .
>>>>>
>>>>> Shall I add an option to <clear-field> that will trigger a
>>>>> ContextAccessor.remove() rather than a 
>>>>> ContextAccessor.put() that merely replaces a field with null?
>>>>>
>>>>> I'm doing a custom service that <implements> an existing service
>> in
>>>>> OFBiz, and I need to trim away 
>>>>> the extra input fields before putting them to the existing
>> service.
>>>>> Jonathon
>>>>>
>>
> 

Re: Removing fields from a map in Minilang clear-field

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

Send the code snippet that you're working on and I'll tweak it.

--- Jonathon -- Improov <jo...@improov.com> wrote:

> Chris,
> 
> Never mind the conjecture. Your recommendation works! Thanks! And the
> title is possibly 
> irrelevant, since I can't find any reason now to change <clear-field>
> after reading your 
> recommendation.
> 
> A question here about <iterate-map>, small digression. You can ignore
> it and ask for a new thread 
> if you want.
> 
> I was doing it via <iterate-map>, <if>, <field-to-field>, so that I
> could simply copy over from 
> map "parameters" those fields that are not in my own service.
> 
> Using <set> instead of <field-to-field> doesn't work, because I
> couldn't get the fields' types 
> (String, Double, etc) from <iterate-map>.
> 
> There's a warning about <field-to-field> being deprecated. Is there a
> need to enhance 
> <iterate-map> to include "field type" in it's results?
> 
> Jonathon
> 
> Chris Howe wrote:
> > sorry about the conjecture on screens/java...didn't read the title
> :-)
> > 
> > --- Chris Howe <cj...@yahoo.com> wrote:
> > 
> >> I'm not quite sure I'm following you as to which has the extra
> >> fields,
> >> your input map or the interface.
> >>
> >> I'm thinking your input map has the extra fields otherwise the
> extra
> >> fields in the interface would be optional, or you would likely end
> up
> >> with inconsistent result from the interface.
> >>
> >> So, assuming it's your input map and you would only be coming
> across
> >> this situation in simple-method because the screens->service picks
> >> the
> >> fields from context and java->service has you specify the map
> >> specifically.
> >>
> >>
> >> So, if you're running this from simple-methods...you're solution,
> I
> >> believe, is the following
> >>
> >> <set-service-fields map-name="myInputMap" service-name="myService"
> >> to-map-name="inputMap"/>
> >> <call-service service-name="myService" in-map-name="inputMap"/>
> >>
> >> Does that help?
> >>
> >> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>
> >>> I can't find any usage of ContextAccessor.remove(MethodContext)
> in
> >>> Minilang's source codes at 
> >>> src/org/ofbiz/minilang/method/envops .
> >>>
> >>> Shall I add an option to <clear-field> that will trigger a
> >>> ContextAccessor.remove() rather than a 
> >>> ContextAccessor.put() that merely replaces a field with null?
> >>>
> >>> I'm doing a custom service that <implements> an existing service
> in
> >>> OFBiz, and I need to trim away 
> >>> the extra input fields before putting them to the existing
> service.
> >>>
> >>> Jonathon
> >>>
> >>
> > 
> 
> 

Re: Removing fields from a map in Minilang clear-field

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

Chris,

Never mind the conjecture. Your recommendation works! Thanks! And the title is possibly 
irrelevant, since I can't find any reason now to change <clear-field> after reading your 
recommendation.

A question here about <iterate-map>, small digression. You can ignore it and ask for a new thread 
if you want.

I was doing it via <iterate-map>, <if>, <field-to-field>, so that I could simply copy over from 
map "parameters" those fields that are not in my own service.

Using <set> instead of <field-to-field> doesn't work, because I couldn't get the fields' types 
(String, Double, etc) from <iterate-map>.

There's a warning about <field-to-field> being deprecated. Is there a need to enhance 
<iterate-map> to include "field type" in it's results?

Jonathon

Chris Howe wrote:
> sorry about the conjecture on screens/java...didn't read the title :-)
> 
> --- Chris Howe <cj...@yahoo.com> wrote:
> 
>> I'm not quite sure I'm following you as to which has the extra
>> fields,
>> your input map or the interface.
>>
>> I'm thinking your input map has the extra fields otherwise the extra
>> fields in the interface would be optional, or you would likely end up
>> with inconsistent result from the interface.
>>
>> So, assuming it's your input map and you would only be coming across
>> this situation in simple-method because the screens->service picks
>> the
>> fields from context and java->service has you specify the map
>> specifically.
>>
>>
>> So, if you're running this from simple-methods...you're solution, I
>> believe, is the following
>>
>> <set-service-fields map-name="myInputMap" service-name="myService"
>> to-map-name="inputMap"/>
>> <call-service service-name="myService" in-map-name="inputMap"/>
>>
>> Does that help?
>>
>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>
>>> I can't find any usage of ContextAccessor.remove(MethodContext) in
>>> Minilang's source codes at 
>>> src/org/ofbiz/minilang/method/envops .
>>>
>>> Shall I add an option to <clear-field> that will trigger a
>>> ContextAccessor.remove() rather than a 
>>> ContextAccessor.put() that merely replaces a field with null?
>>>
>>> I'm doing a custom service that <implements> an existing service in
>>> OFBiz, and I need to trim away 
>>> the extra input fields before putting them to the existing service.
>>>
>>> Jonathon
>>>
>>
> 

Re: Removing fields from a map in Minilang clear-field

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

sorry about the conjecture on screens/java...didn't read the title :-)

--- Chris Howe <cj...@yahoo.com> wrote:

> I'm not quite sure I'm following you as to which has the extra
> fields,
> your input map or the interface.
> 
> I'm thinking your input map has the extra fields otherwise the extra
> fields in the interface would be optional, or you would likely end up
> with inconsistent result from the interface.
> 
> So, assuming it's your input map and you would only be coming across
> this situation in simple-method because the screens->service picks
> the
> fields from context and java->service has you specify the map
> specifically.
> 
> 
> So, if you're running this from simple-methods...you're solution, I
> believe, is the following
> 
> <set-service-fields map-name="myInputMap" service-name="myService"
> to-map-name="inputMap"/>
> <call-service service-name="myService" in-map-name="inputMap"/>
> 
> Does that help?
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
> > I can't find any usage of ContextAccessor.remove(MethodContext) in
> > Minilang's source codes at 
> > src/org/ofbiz/minilang/method/envops .
> > 
> > Shall I add an option to <clear-field> that will trigger a
> > ContextAccessor.remove() rather than a 
> > ContextAccessor.put() that merely replaces a field with null?
> > 
> > I'm doing a custom service that <implements> an existing service in
> > OFBiz, and I need to trim away 
> > the extra input fields before putting them to the existing service.
> > 
> > Jonathon
> > 
> 
> 

Re: Removing fields from a map in Minilang clear-field

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

I'm not quite sure I'm following you as to which has the extra fields,
your input map or the interface.

I'm thinking your input map has the extra fields otherwise the extra
fields in the interface would be optional, or you would likely end up
with inconsistent result from the interface.

So, assuming it's your input map and you would only be coming across
this situation in simple-method because the screens->service picks the
fields from context and java->service has you specify the map
specifically.


So, if you're running this from simple-methods...you're solution, I
believe, is the following

<set-service-fields map-name="myInputMap" service-name="myService"
to-map-name="inputMap"/>
<call-service service-name="myService" in-map-name="inputMap"/>

Does that help?

--- Jonathon -- Improov <jo...@improov.com> wrote:

> I can't find any usage of ContextAccessor.remove(MethodContext) in
> Minilang's source codes at 
> src/org/ofbiz/minilang/method/envops .
> 
> Shall I add an option to <clear-field> that will trigger a
> ContextAccessor.remove() rather than a 
> ContextAccessor.put() that merely replaces a field with null?
> 
> I'm doing a custom service that <implements> an existing service in
> OFBiz, and I need to trim away 
> the extra input fields before putting them to the existing service.
> 
> Jonathon
>