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