[jsword-devel] [sword-devel] JSword documentation correction required?

[Chris Burrell]

I'm all for the DI for the Configuration management, but in order to
minimize the impact to the various different interfaces, I think we probably
want to have the idea that each method is aware of its context (user,
user-config, ...). Not sure how we would do this with simple
getters/setters/etc.

All I'm thinking at the moment, is somehow annotate those methods that start
a "request" (they will need interface changes), and then allowing any other
method to query the current state of the request by calling a
"getMeTheCurrentContext". What I want to avoid is having to rewrite most of
the method signatures across JSword to be passing down the current
config/user/etc.

Any ideas welcome...
Chris

On 19 July 2010 09:17, Tonny Kohar <tonny.kohar at gmail.com> wrote:

> Hi,
>
> On Sat, Jul 17, 2010 at 3:11 AM, Chris Burrell <chris at burrell.me.uk>
> wrote:
> > Hi DM
> > Well my suggestion would be to adopt a IOC/dependency injection. Perhaps
> a
> > "config provider" object can be inserted into those places that need
> access
> > to those statics. We can somehow insert a default provider with default
> > config if no user config provider is found.
> > The JSword code would ask the config provider for the various settings.
> > JSword could also alter the config provider on any changes.
> > If the provider is defined as an interface, it gives the people the
> option
> > to write their own Configuration Provider mechanism, and inject/set it at
> > runtime. Some might want to carry state and persist it elsewhere, some
> might
> > want it geared towards concurrency usage, etc.
>
> +1
>
> Yes using concept dependency injection is good. However, if possible
> please don't use like annotation or non-standard/complex setup. Just
> use simple java constructs like service provider with default/abstract
> implementation which can be easily inherited/overriden.
>
> Cheers
> Tonny Kohar
> --
> Alkitab Bible Study
> http://www.kiyut.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20100720/4d2740ef/attachment.html>