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
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
d) what are the methods/fields that you would like to move from DispatchContext
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...
>
> 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
