Removing fields from a map in Minilang clear-field
Locked
 
|
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 |
|
|
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 > |
|
|
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 > > > > |
|
|
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 >>> >> > |
|
|
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 > >>> > >> > > > > |
|
|
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 >>>>> >> > |
|
|
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 > >>>>> > >> > > > > |
|
|
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 > > >>>>> > > >> > > > > > > > > > |
|
|
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 >>>>>>>> >>> >> > |
Re: Removing fields from a map in Minilang clear-field
|
|
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 >>>>>>>>> >>>> >>> >> |
|
|
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 >>>>>>>>>> >>>>> >>>> >>> > > |
How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field
|
|
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 >>>>>>>>>>> >>>>>> >>>>> >>>> >> >> |
|
|
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 >>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> > > |
|
|
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 > >>>>>>>> > >>> > >> > > > |
|
|
> 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 === > |
Re: How to add custom extentions to existing services WAS Re: Removing fields from a map in Minilang clear-field
|
|
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 > |
|
|
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 >> > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |