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