Actually I was planning on using the ExecutionContext instead of the
DispatchContext. We could have a DispatchContext interface that
extends the ExecutionContext one if we can get that to make it easier
to update services written Java (ie just require something like the
Eclipse organize imports to get things working again).
-David
On Aug 10, 2009, at 4:13 PM, Adrian Crum wrote:
It seems to me that DispatchContext plays a similar role as
ExecutionContext - as far as being a container of artifacts used by
services. I'm thinking DispatchContext could decorate an
ExecutionContext instance, and then the service engine wouldn't need
to have another object to pass around.
-Adrian
Adrian Crum wrote:
I'm bumping this because I might have some time this weekend to help.
David - I would like to work on converting some of the frequently
used lower-level concrete classes to interfaces. You didn't reply
when I suggested it before. Do you have any objections?
Also, if that conversion is done, it could be done in the trunk -
negating the need for a branch. In other words, once the higher
level code is using interfaces, you can muck around with the
implementations all you want.
-Adrian
--- On Fri, 7/17/09, Adrian Crum <[email protected]> wrote:
From: Adrian Crum <[email protected]>
Subject: Re: svn commit: r795024 [1/6] - in /ofbiz/branches/
executioncontext20090716: ./ applications/content/src/org/ofbiz/
content/content/ applications/order/src/org/ofbiz/order/order/
applications/party/src/org/ofbiz/party/party/ applications/product/
src/org/ofb...
To: [email protected]
Date: Friday, July 17, 2009, 5:07 PM
--- On Fri, 7/17/09, David E Jones <[email protected]>
wrote:
There is a basic reason for this, and it's because I'm
lazy
and also not sure how many of these "lower level"
objects we
even want interfaces for.
My preference would be to change all of it to interfaces.
Higher level code should interact with interfaces - not
concrete classes (dependency inversion).
Keep in mind you're not alone in this effort - I'm
available to help.
-Adrian