Removing fields from a map in Minilang clear-field

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing fields from a map in Minilang clear-field

jonwimp
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
Reply | Threaded
Open this post in threaded view
|

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

cjhowe
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 <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

cjhowe

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

--- Chris Howe <[hidden email]> 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 <[hidden email]> 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
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

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

--- Jonathon -- Improov <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

cjhowe
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>>>
> >>
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

cjhowe
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> > >>>>>
> > >>
> > >
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

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

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>
>>>>
>>>
>>


Reply | Threaded
Open this post in threaded view
|

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

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>>
>>>>>
>>>>
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>


Reply | Threaded
Open this post in threaded view
|

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

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

Reply | Threaded
Open this post in threaded view
|

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

cjhowe
In reply to this post by jonwimp
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ===

Reply | Threaded
Open this post in threaded view
|

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

jonwimp
 > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 ===
>

Reply | Threaded
Open this post in threaded view
|

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

Jacopo Cappellato
In reply to this post by jonwimp
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
>



Reply | Threaded
Open this post in threaded view
|

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

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