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

[DM Smith]

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:
>>
>>> I've thrown together a quick AJAX-based front-end for JSword.  I'm
>>> aiming to make it look and work nice for iPhone users.  We'll see if
>>> it works out.  Right now it works fine in Safari on the desktop, and
>>> also in the iPhone simulator.  In the simulator the display of
>>> non-ASCII characters seems to fail (specifically the WLC and AraSVD
>>> modules with Hebrew and Arabic).  I don't know if that's the same on
>>> the devices, as I don't have access to one at this time, however,  
>>> they
>>> work fine in desktop Safari.
>>
>> Super. Great start!
>>
>> I'm doing the same. :) But I'm not trying to actually create a  
>> product.
>>
>> My goal is to create *a* working tutorial for Safari, IE and Firefox.
>> Right now, it does not work on Safari. I haven't tried it on IE.
>
> I get essentially the same error in IE7 as I got in Safari "
> 'undefined' is not an object."

Hmm. More work to do. :)

>  Then again, my own page has IE7 issues
> it seems, the CSS for :hover doesn't appear to be supported in IE7 or
> Mozilla, while it works fine in Safari.  Likely this is because the
> items are not actually links, and the :hover style is, I believe,
> targeted at anchor tags specifically.  However, that styling is aimed
> at just making it more obvious to desktop users - iPhone has no
> concept of mouseover/hover.

This can be solved with a small piece of JavaScript that adds a class  
style on mouse enter and removes it on mouse out.
See: http://www.alistapart.com/articles/dropdowns
You'll need to adapt their code.

>
>
>>
>> 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.

>  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.


>
>
>>
>>
>>>
>>>
>>> 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.