<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 19, 2008, at 1:40 PM, Greg Hellings wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Sat, Apr 19, 2008 at 12:20 PM, DM Smith <<a href="mailto:dmsmith555@yahoo.com">dmsmith555@yahoo.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite"> On Apr 19, 2008, at 12:43 PM, Greg Hellings wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Sat, Apr 19, 2008 at 8:42 AM, DM Smith <<a href="mailto:dmsmith555@yahoo.com">dmsmith555@yahoo.com</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Apr 19, 2008, at 5:22 AM, Greg Hellings wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">For more details see my post on jsword-devel:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="http://www.crosswire.org/pipermail/jsword-devel/2008-April/">http://www.crosswire.org/pipermail/jsword-devel/2008-April/</a><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">002453.html<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I read through it. It seems most of the problem you're encountering<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is with client-side XSL transformations. I don't know what exactly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">you're doing with the XML on the client side. My version is just<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">sending the output of getRawText(user_key) across the wire. I'd like<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to send the transformed HTML, but I get a NullPointerExcepion when I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">invoke ConverterFactory.getConverter() from my servlet. When I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">iterate over the Converters that it recognizes, the only one is the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ConfigurableSwingConverter, but even trying to retrieve that Converter<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">throws the exception on line 55 of ConverterFactory.java.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Try including the bibledesktop*.jar. It is in there.<br></blockquote><br>All of those are included, and the class exists within the project (I<br>can instantiate the SAX Converter directly - though I don't know the<br>URI that it's looking for). It just seems that ConverterFactory isn't<br>picking up on its existence for some reason.</blockquote><div><br></div>That's odd.</div><div>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.</div><div>Essentially that's all that the ConverterFactory is doing in a round about way.</div><div><br><blockquote type="cite"><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"> If I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">understood more of how to pull the pure XML from the module and where<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">to find the XSLT, I could do the transformation client-side with GWT's<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">built-in XSL processor, as it would only make sense for me to be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">displaying HTML and not RawText in a browser window.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> See o.c.jsword.bridge.DwrBridge and o.c.jsword.examples.APIExample<br></blockquote><blockquote type="cite"> for, well, examples.<br></blockquote><br>APIExamples has been my crutch throughout the whole project. It's the<br>code from getStyledText() in the examples that I'm using to try and<br>convert to HTML on the server side. However, the above<br>ConverterFactory error appears to be the only thing hampering my<br>efforts. I'll take a look at DwrBridge.</blockquote><div><br></div>DwrBridge expects client side xslt.</div><div><br></div><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There are still some rough edges with the interface - primarily it<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">doesn't properly detect the books that are in a module at any given<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">moment. It does detect chapters-in-book and verses-in-chapter,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">though. For now, you just have to assume that if you get to the<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">verse<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">display and there is no text (and no error box), then that module<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">must<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">not support that verse/book. There are also additional GUI tweaks<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">that will be needed to smooth the functioning of it, but this is<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">just<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a quickly hobbled together patch-up.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">One of the things that I think that is needed in JSword is that the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">global key list actually reflect the content of the module. For<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Bibles<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">and commentaries, it assumes Gen-Rev. I'll probably do the same thing<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I did for dictionaries there too.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I had tried that method (get the global key list, then try the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">.contains() method) and to my surprise, it told me that all of the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Bible was available in the LXX. I likewise tried catching exceptions<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">from the .getKey() method, but that seems to only throw them if the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Key doesn't exist in the Bible at all, rather than if it doesn't exist<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">in this module. However, having each Bible support the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">.booksInModule() as well as its own implementation of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">.chaptersInBook() and ..versesInChapter() would allow for ease of use<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">if alternate versification ever pops up. Currently the BibleInfo<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">class works fine for the latter two, but I can't figure out any way to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">narrow down the books available. It sounds like this is a "ToDo" on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">your list, though.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> Books available can be done *today* by checking chapter 1, verse 1 of<br></blockquote><blockquote type="cite"> each book.<br></blockquote><br>I must not be checking them correctly. I've done it by (1) calling<br>getGlobalKeyList() and then checking "<book> 1:1" for all 66 books and<br>seeing if they're in the returned global key list and (2) calling<br>getKey() on "<book> 1:1" and catching exceptions - if an exception<br>occurs then I assume the book is not in the module and if none occurs<br>I add the book name to the list of valid books. However, both of the<br>above methods return all 66 books as valid regardless of which module<br>I'm using. I couldn't find any examples of how to check it. What is<br>the correct method?<br></blockquote></div><br><div>The global key list is a guess. It is not based upon the content of the module. It is merely "Gen-Rev".</div><div><br></div><div>To check if a verse is actually present you need something like the following:</div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">Key key = book.getKey("Gen.1.1");</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">String raw = book.getRawText(key);</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; ">boolean hasVerse = (raw.length() > 0);<br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Monaco; "><br></div></div></body></html>