[jsword-devel] [sword-devel] Web Front-end for JSword (iPhone targeted)

[DM Smith]

On Apr 19, 2008, at 1:40 PM, Greg Hellings wrote:

> On Sat, Apr 19, 2008 at 12:20 PM, DM Smith <dmsmith555 at yahoo.com>  
> wrote:
>>
>> On Apr 19, 2008, at 12:43 PM, Greg Hellings wrote:
>>
>>> On Sat, Apr 19, 2008 at 8:42 AM, DM Smith <dmsmith555 at yahoo.com>
>>> wrote:
>>>> On Apr 19, 2008, at 5:22 AM, Greg Hellings wrote:
>>>>
>>>>>
>>>> For more details see my post on jsword-devel:
>>>>
>>>> http://www.crosswire.org/pipermail/jsword-devel/2008-April/
>>>> 002453.html
>>>
>>> I read through it.  It seems most of the problem you're encountering
>>> is with client-side XSL transformations.  I don't know what exactly
>>> you're doing with the XML on the client side.  My version is just
>>> sending the output of getRawText(user_key) across the wire.  I'd  
>>> like
>>> to send the transformed HTML, but I get a NullPointerExcepion when I
>>> invoke ConverterFactory.getConverter() from my servlet.  When I
>>> iterate over the Converters that it recognizes, the only one is the
>>> ConfigurableSwingConverter, but even trying to retrieve that  
>>> Converter
>>> throws the exception on line 55 of ConverterFactory.java.
>>
>> Try including the bibledesktop*.jar. It is in there.
>
> All of those are included, and the class exists within the project (I
> can instantiate the SAX Converter directly - though I don't know the
> URI that it's looking for).  It just seems that ConverterFactory isn't
> picking up on its existence for some reason.

That's odd.
Then use the APIExample's example of searchAndShow. It gives how you  
can supply your own stylesheet, but it uses BibleDesktop's simple.xsl.  
Note, this needs to be tweaked to produce appropriate output for the  
web.
Essentially that's all that the ConverterFactory is doing in a round  
about way.

>
>
>>
>>
>>> If I
>>> understood more of how to pull the pure XML from the module and  
>>> where
>>> to find the XSLT, I could do the transformation client-side with  
>>> GWT's
>>> built-in XSL processor, as it would only make sense for me to be
>>> displaying HTML and not RawText in a browser window.
>>
>> See o.c.jsword.bridge.DwrBridge and o.c.jsword.examples.APIExample
>> for, well, examples.
>
> APIExamples has been my crutch throughout the whole project.  It's the
> code from getStyledText() in the examples that I'm using to try and
> convert to HTML on the server side.  However, the above
> ConverterFactory error appears to be the only thing hampering my
> efforts.  I'll take a look at DwrBridge.

DwrBridge expects client side xslt.

>>>>> There are still some rough edges with the interface - primarily it
>>>>> doesn't properly detect the books that are in a module at any  
>>>>> given
>>>>> moment.  It does detect chapters-in-book and verses-in-chapter,
>>>>> though.  For now, you just have to assume that if you get to the
>>>>> verse
>>>>> display and there is no text (and no error box), then that module
>>>>> must
>>>>> not support that verse/book.  There are also additional GUI tweaks
>>>>> that will be needed to smooth the functioning of it, but this is
>>>>> just
>>>>> a quickly hobbled together patch-up.
>>>>
>>>>
>>>> One of the things that I think that is needed in JSword is that the
>>>> global key list actually reflect the content of the module. For
>>>> Bibles
>>>> and commentaries, it assumes Gen-Rev. I'll probably do the same  
>>>> thing
>>>> I did for dictionaries there too.
>>>
>>> I had tried that method (get the global key list, then try the
>>> .contains() method) and to my surprise, it told me that all of the
>>> Bible was available in the LXX.  I likewise tried catching  
>>> exceptions
>>> from the .getKey() method, but that seems to only throw them if the
>>> Key doesn't exist in the Bible at all, rather than if it doesn't  
>>> exist
>>> in this module.  However, having each Bible support the
>>> .booksInModule() as well as its own implementation of
>>> .chaptersInBook() and .versesInChapter() would allow for ease of use
>>> if alternate versification ever pops up.  Currently the BibleInfo
>>> class works fine for the latter two, but I can't figure out any  
>>> way to
>>> narrow down the books available.  It sounds like this is a "ToDo" on
>>> your list, though.
>>
>> Books available can be done *today* by checking chapter 1, verse 1 of
>> each book.
>
> I must not be checking them correctly.  I've done it by (1) calling
> getGlobalKeyList() and then checking "<book> 1:1" for all 66 books and
> seeing if they're in the returned global key list and (2) calling
> getKey() on "<book> 1:1" and catching exceptions - if an exception
> occurs then I assume the book is not in the module and if none occurs
> I add the book name to the list of valid books.  However, both of the
> above methods return all 66 books as valid regardless of which module
> I'm using.  I couldn't find any examples of how to check it.  What is
> the correct method?

The global key list is a guess. It is not based upon the content of  
the module. It is merely "Gen-Rev".

To check if a verse is actually present you need something like the  
following:
Key key = book.getKey("Gen.1.1");
String raw = book.getRawText(key);
boolean hasVerse =  (raw.length() > 0);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20080419/298de7e4/attachment-0001.html