Hello,<br><br>I see. You want the module information in a database because it's then trivial to program a web application using Ruby on Rails ActiveRecord object relational mapping support. RoR also supports other logic in controllers such as web services clients so it's entirely possible to write an application that calls Sword without using a database but the scaffolding code generator won't be able to help much if at all.
<br><br>It just so happens I've been working on a Ruby interface to Sword with a longer term goal of writing a Ruby on Rails application to access it. Initially, I couldn't figure out how to build anything with SWIG--there's no README in the bindings/swig directory. Then it happened I discovered Ruby can load shared libraries and DLL's and dynamically bind to them on the fly using the dynamic loader (DL) module. So I started to write a Sword interface to the C flatapi in bindings/flatapi.cpp. In the process, I found a few minor bugs with the flatapi but have created patches to fix them (which I'll submit soon).
<br><br>Using this Ruby to Sword flatapi interface you can output verses as follows (I'm doing this from memory so it's not exact):<br><br><div style="margin-left: 40px;">include Sword<br># SWMgr_new(FMT_HTML)<br>Manager.new
(Sword::FMT_HTML) do |mgr|<br><div style="margin-left: 40px;">module = mgr.get_module("KJV")<br># iteration using Sword API's under the covers to verseKey and renderText<br>module.each_verse_render("Psalm 133:1-3") do |verse, text|
<br><div style="margin-left: 40px;">puts "#{verse} #{text}" # verse reference and text<br></div>end<br></div>end # performs an implicit SWMgr_delete<br></div><br>So far, I've implemented about two-thirds of the Sword C flatapi. However, the one issue I'm just starting to address is how to call these API's within a multi-threaded multi-user environment such as a web application. Because the SWMgr_new/newEx and SWModule_* functions have state, it looks like a new Manager object will have to be created per user which means establishing a session and then saving the Manager instance in the session. So I have to refactor the code to allow multiple instances of a Manager class without loading the shared library every time.
<br><br>But then last night I was about to send an email to this list asking how to build the SWIG interface but I looked at it one more time and discovered how to do it. With some more investigation I was then able to generate SWIG bindings for Ruby and build the interface to Sword. So far I've been able to access some of the methods from the SWMgr and SWModule classes but can't output a verse because the binding of set_key to
SWModule.SetKey is incorrect. This may be a bug in the way SWIG generated the binding but I don't know yet.<br><br>The nice thing about the Ruby dynamic loader interface to Sword is there's nothing extra to build which makes it much easier to install as compared with the SWIG version. However, the C flatapi on which it's based limits one to getting and setting global options, iterating over modules and rendering verses. The SWIG interface to the C++ API's is much more complete but has to be built. I don't know yet if the Sword C++ API's also have state which is important to know for a web application.
<br><br>Right now, I'm developing on RedHat ES 3 but plan to test the DL version on Windows against an installed BibleCS. My time is limited but I'll try to get this binding in reasonable shape soon so it can be used with Ruby on Rails. Building the SWIG version on Windows is not an option for me at this time due to lack of tools and a dead machine.
<br><br>God is merciful,<br>-Bill<br><br><div><span class="gmail_quote">On 11/7/06, <b class="gmail_sendername">lumin8</b> <<a href="mailto:lumi.n8@gmail.com">lumi.n8@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I'll leave the question alone as to the value of a relational database<br>for this data over using the SWORD API.
</blockquote></span><div><br>Actually, I am interested in this question if you have time / desire to enlighten me. I think I can manage the chunk of code you gave me (thanks), but I have never compiled a program in my life. I have been building web applications for about 7 years with PHP, and now Ruby for the last year and a half.
<br><br>I am willing to learn the Sword API if I need to, but I can build web applications very quickly with Ruby on Rails. The rest of my data (user info, notes, user generated translations, a wiki like interface for commentary) will all be in a relational database. Would there be speed benefits from using the Sword API over the indexing provided by mysql or postgre? What about application development time? In the Rails framework, I hardly even have to write SQL, if I used the Sword API I would have to learn a bit about c++ and bindings to Ruby... I am willing, but what is the advantage?
<br><br>By the way, I have tried and use many of the Sword front ends and highly respect the work you all are doing.<br></div>
</blockquote></div><br>