--- On Sat, 1/30/10, David E Jones <d...@me.com> wrote:
> From: David E Jones <d...@me.com>
> Subject: Re: svn commit: r904921 - in
> /ofbiz/trunk/framework/base/src/org/ofbiz/base: test/BaseUnitTests.java
> util/string/UelUtil.java
> To: dev@ofbiz.apache.org
> Date: Saturday, January 30, 2010, 7:02 PM
>
> On Jan 30, 2010, at 8:30 PM, Adrian Crum wrote:
>
> > --- On Sat, 1/30/10, David E Jones <d...@me.com>
> wrote:
> >> From: David E Jones <d...@me.com>
> >> Subject: Re: svn commit: r904921 - in
> /ofbiz/trunk/framework/base/src/org/ofbiz/base:
> test/BaseUnitTests.java util/string/UelUtil.java
> >> To: dev@ofbiz.apache.org
> >> Date: Saturday, January 30, 2010, 5:37 PM
> >>
> >> On Jan 30, 2010, at 7:28 PM, Adam Heath wrote:
> >>>
> >>> When I originally came up with the read-only
> generics
> >> for service
> >>> engine calls, I tried to make the maps
> writable.
> >> But upon modifying
> >>> the entire stack, I discovered it wasn't
> >> possible. The service engine
> >>> made copies in some cases, so the underlying
> service
> >> implementations
> >>> weren't able to send data back at all to the
> original
> >> caller. To
> >>> encapsulate this, I made the map read only, by
> using
> >> the ? extends syntax.
> >>
> >> Maybe this is not the best way to look at it. The
> point is
> >> not that you can't change the context, it is just
> that any
> >> changes to the context are local to the service
> itself.
> >>
> >> If I had the service engine to design again I'd
> consider
> >> having it be more like the screen widget with the
> >> hierarchical context, and with the context as the
> local
> >> variable space (for all services except those
> written in
> >> plain Java where you can't inject into the
> variable space on
> >> the stack (not that I know of anyway... maybe
> there is a way
> >> and that would be cool).
> >
> > When I first got involved with OFBiz, I would write to
> the service context Map because I didn't know any better.
> Then when I got to know OFBiz better, I still wrote to the
> service context Map because I was lazy. Now I always copy
> the service context Map into a local Map if I want to change
> things.
> >
> > The moral of the story is: developers shouldn't be
> allowed to write to the service context Map. If a service
> needs a Map for local storage, then it should create one.
>
> That's kind of interesting.
>
> What got me thinking is that the normal practice for Java
> service is to create a local variable for pretty much
> everything in the context anyway (ie like: String partyId =
> (String) context.get("partyId");), and there are things like
> that all over the place.
>
> As far as not being to write to the context... why not?
> Sometimes it's handy to use the current context as the basis
> for calling another service. There are certainly other ways
> to go about that... but...
In those cases you can use ModelService to create a new Map for the new service
based on the Map from the current service.
Even mini-lang has a set-service-fields element to do that.
