Inline...
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 8/31/2014 10:36 AM, Jacopo Cappellato wrote:
Thank you Adrian,
please see inline:
On Aug 31, 2014, at 10:50 AM, Adrian Crum <adrian.c...@sandglass-software.com>
wrote:
Currently, the service engine classes are a bit muddled. GenericDispatcher (the
default LocalDispatcher implementation) and DispatchContext have feature envy.
Some functionality in DispatchContext belongs in ServiceDispatcher.
I would like to clean this up a bit and provide better separation of concerns. The
service engine API will not change - the work will be done "under the hood."
My hope is to get the code to a point where DispatchContext becomes less
integral to its neighbors, and it becomes more of a single-use lightweight
container. Again, this will not change the API at all.
I think it would help the other committers to provide feedback if you could (in
just a few sentences) summarize the following:
a) what is the original concern of DispatchContext and of GenericDispatcher
I replied to this in another post.
b) where do you see that this concerns are not well implemented in the code
c) if you would like to modify #a, quickly describe the new purposes of the
classes in your vision
DispatchContext becomes a lightweight container for objects that a
service implementation needs. Instead of relatively-constant instances
being kept inside a GenericDispatcher, a new instance is created
on-the-fly whenever a service is invoked.
d) what are the methods/fields that you would like to move from DispatchContext
It's the other way around. I want to remove the DispatchContext
reference from GenericDispatcher.
Thanks
Jacopo
PS: in general I also see a lot of code that should be cleaned in
DispatchContext; for example, the initialization of the static map in the
constructor, the method getAllServiceNames() that should be static, bad
thread-safe implementation, probably the modelServiceMapByModel should not even
be there...
Exactly. From my perspective, that code should be in ServiceDispatcher.
However, it will open up the possibility to improve the API. For example,
instead of this service implementation:
public static Map<String, Object> myService(DispatchContext dctx, Map<String,
Object> context) {
Locale locale = (Locale) context.get("locale");
...
we could have:
public static Map<String, Object> myService(DispatchContext dctx) {
Locale locale = dctx.getParameter("locale");
...
What do you think?
--
Adrian Crum
Sandglass Software
www.sandglass-software.com
