[jsword-devel] Key issues
Brian Fernandes
infernalproteus at gmail.com
Mon May 12 14:36:24 MST 2008
I'm upgrading FireBible to handle Genbooks, Dictionaries, Glossaries and
probably Daily Devotionals too, but I'm running into a few issues with keys.
First, a little background on how FB works:
When you select a Bible, Book and Chapter in the FB interface, that
selection is converted into a URL (e.g. bible://gen.1). The URL is then
"loaded", as if you had typed it into the address bar yourself and
pressed enter. Firefox then passes that URL onto FB's "bible" protocol
handler. The protocol handler picks up the active
Bible(org.cw.js.book.Book) from the combo box in the UI and then calls
book.getKey("gen.1") to get a key. This key is then used to retrieve the
data to be displayed.
Problem 1:
The problem with this approach, is the fact that the URL does not
contain the bible(book) name/Id. For example, if you bookmark the link
bible://gen.1 when viewing the ESV bible, the next time you open the
bookmark, if you have the ACV bible selected in the combo you will see
ACV text instead of ESV.
This also causes an issue with the history. For example, if you open
Gen.1 in ESV, then select ACV and go to Exo.5 and click back, you will
see Gen.1 in ACV, not in ESV.
In custom software I could keep track of the bibles myself and set the
bible accordingly on back / forward, but here I'm trying let Firefox
take care of all the heavy lifting. By using the URL approach outlined
above, I have free History support (except for this problem) from
Firefox to the same extent as regular HTTP URLs in different tabs and
windows. It is still possible for me to override back / forward behavior
but it is non trivial and could be avoided if I could include the book
Id in the URL instead. My protocol would then retrieve the book from the
URL instead of the UI.
I can do something custom here but wanted to know if there have already
been any discussions on this subject and if there already is a format
for including the book Id in bible URLs.
Problem 2:
I'm trying to use the same URL approach with Gen books. When the user
selects a particular node in the Gen book tree, I convert that key into
a URL and attempt to load that. Besides running into Problem 1 again
(since the book Id is not part of the URL), I have an additional
"textual uniqueness" problem. If you look at "Sermons on Gospel Themes
by Charles G. Finney" you will notice that there are several "pages"
titled "REMARKS", consequently, "REMARKS" is also the Key name for all
these pages.
Given a Gen book and a URL like "bible://REMARKS/" the first page tiled
REMARKS is retrieved, not necessarily the REMARKS page you selected.
This is easy to fix if I use the original Key object that was selected,
but with my URL approach, passing an object along is out of the question
(note that these URLs should ideally be usable across Firefox sessions,
if you restart the browser, it should still bring up the same content;
so having the protocol handler look up some info external to the URL
will only work for a given session).
My solution here was to create a custom URL which could contain the key
names for all the ancestors of the desired key, delimited by an
acceptable character (may be difficult to find one). The protocol
handler would then break up the URL and regenerate the desired Key.
Again, has any work been done in this area or does JSword have the
ability to generate a textually unique key (something that would include
the ancestral path?).
Any suggestions on how to deal with these issues in a standards
compliant way are welcome (or perhaps we need to extend the existing
standard :)),
Brian.
P.S. I just found a bug in BD 1.0.7 where Gen books pages have the same
names.
1) Select the any "REMARKS" page (A). Observe text.
2) Select another "REMARKS" page (B) without selecting anything else in
between. Observe that text is not updated as expected.
3) Select any other page with a different name and then select B again.
Observe that text has now been updated (this should have happened at
step 2).
More information about the jsword-devel
mailing list