--- On Sun, 1/31/10, David E Jones <d...@me.com> wrote:
> 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: Sunday, January 31, 2010, 12:12 AM
> 
> On Jan 31, 2010, at 2:00 AM, Adrian Crum wrote:
> 
> > --- On Sat, 1/30/10, David E Jones <d...@me.com>
> wrote:
> >> On Jan 30, 2010, at 8:30 PM, Adrian Crum wrote:
> >>> 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...
> > 
> > Maybe it would help to step back a little and compare
> OFBiz back in the day when it was just David and Andrew, and
> what it is today. Back then using a Map for passing
> parameters was a cool idea. I don't know what the motivation
> was to use a Map to pass parameters when you designed the
> service engine, but at the time I'm sure the two of you knew
> that you weren't supposed to write to it.
> > 
> > Today, things are different. We have a lot of
> contributors. Many of those contributors might not know
> everything they need to know about the framework. So, the
> framework needs to protect itself from inexperienced or lazy
> developers. That was the moral of the story.
> 
> Have you ever considered running for public office?

Getting paid at a higher rate than the private sector for doing less work has 
its appeal...




      

Reply via email to