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

[Chris Burrell]

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.

I guess if we were to do that we would want to provide a default provider
that people don't need to worry about, but also later provide some that are
geared towards different needs as people write them.

If we were already using Guice or Spring, I'd suggest adding it to that, but
in the meantime we can just provide a setter and encapsulate our statics
into this config object.

I'm guessing the interface would have to provide the concept of
settings/user, which imply some refactoring, since as a developer I'd want
to be able to query this. I can see two ways of doing this.
1- Threading through and overloading the method signatures with the
username/id as a parameter for a method.
2- Somehow making a request to JSword "transactional" or having a "request
scope" Any part of JSword could query the current scope for the current
user, etc. That provides us perhaps with more flexibility going forward.
Perhaps this is achievable with AOP/annotations. Perhaps again Guice can
help http://code.google.com/p/google-guice/wiki/Scopes being a small library
with a small footprint (according to me!)

Some suggestions.
Sorry about the mailing list (feel free to copy this back the sword-devel to
keep the flow)
Chris





On 16 July 2010 19:24, DM Smith <dmsmith at crosswire.org> wrote:

> On 07/16/2010 12:41 PM, Chris Burrell wrote:
>
>> Hi all
>>
>> The documentation of Key.getName()  suggests that getName() will return
>> the short name, such as Mat 1:1 but in fact, when I was just using it out of
>> the box, I got Matthew 1:1 instead!
>>
>>            Books.installed().getBook(version).getKey(reference).getName();
>>
> Well, the documentation doesn't match. That's a bug either in the docs or
> in the implementation. But you saw that :-P
>
>
>
>> But I've found, that we have to set BibleInfo.setFullBookName(false);
>> first, for this to end up in short names.
>>
> The other setting that gets in the way is
> PassageUtil.setPersistentNaming(boolean persistentNaming), which will
> preserve whatever the verse was parsed from.
>
>
>  Not being completely familiar with the whole JSword framework, does this
>> have other implications given this is a static assignment? In particular for
>> concurrency/multi user environment for example?
>>
> You are right that global statics are generally an issue for
> concurrency/multi-user code.
>
> JSword and BibleDesktop have a bunch of global statics. These are part of
> the preferences mechanism. They are exposed in BibleDesktop under Options
> (Preferences on the Mac).
>
> Those that are part of the jsword.jar or the jsword-common.jar may be
> problematic for you. BibleDesktop has some that won't bother you.
>
> It probably would be good to figure out a better mechanism to handle
> preferences or to avoid statics.
>
>
>
>> Does this affect the passage lookup mechanism too? for the title tag for
>> example? or is taken straight from the Sword module, and therefore this
>> wouldn't affect it...?
>>
>
> It affects the title tag that the filters and xslt generates. Some of the
> book names are taken straight from the Sword module and are left as is.
>
> Can you suggest a better mechanism?
>
>
>  Just wondering...
>>
>> The interface in question is Key.java.
>>
>
> By the way sword-devel is not the appropriate place to discuss JSword.
> jsword-devel is. :)
>
> In Him,
> DM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20100716/b9d9a4bf/attachment.html>