On 11/8/06, lumin8 <[EMAIL PROTECTED]> wrote:
I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application.
However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application. At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile. The ActionService web service client support might be a good pattern to start with.
Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules. What I mean is you:
* Can't get a list of all the books in a Bible.
* Given a book name, can't get the number of chapters in the book.
* Given a book name and chapter, can't get the number of verses in that chapter.
If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi.
So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata. As versifications are different in some translations, you can't necessarily use the same information for all translations.
In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like VerseKey that can take any verse reference with a variety of abbreviations and return it in OSIS notation.
I'll try to clean up the module and send it to you so you can start experimenting with it.
In His Service,
-Bill
Bill,
Yes exactly. Sounds like you are doing some great work with this.
I'm trying to figure out how I can help - at the least I could package
it as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.
I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application.
However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application. At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile. The ActionService web service client support might be a good pattern to start with.
Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules. What I mean is you:
* Can't get a list of all the books in a Bible.
* Given a book name, can't get the number of chapters in the book.
* Given a book name and chapter, can't get the number of verses in that chapter.
If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi.
So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata. As versifications are different in some translations, you can't necessarily use the same information for all translations.
In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like VerseKey that can take any verse reference with a variety of abbreviations and return it in OSIS notation.
Let me know if I can help with anything else.
I'll try to clean up the module and send it to you so you can start experimenting with it.
In His Service,
-Bill
-=nathan
On 11/7/06, Bill Burton < [EMAIL PROTECTED]> wrote:
> Hello,
>
> 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.
>
> 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).
>
> Using this Ruby to Sword flatapi interface you can output verses as follows
> (I'm doing this from memory so it's not exact):
>
> include Sword
> # SWMgr_new(FMT_HTML)
> Manager.new (Sword::FMT_HTML) do |mgr|
> module = mgr.get_module("KJV")
> # iteration using Sword API's under the covers to verseKey and renderText
> module.each_verse_render("Psalm 133:1-3") do |verse, text|
> puts "#{verse} #{text}" # verse reference and text
> end
> end # performs an implicit SWMgr_delete
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> God is merciful,
> -Bill
>
> On 11/7/06, lumin8 < [EMAIL PROTECTED]> wrote:
> >
> > > I'll leave the question alone as to the value of a relational database
> > > for this data over using the SWORD API.
> >
> >
> > 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.
> >
> > 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?
> >
> > By the way, I have tried and use many of the Sword front ends and highly
> respect the work you all are doing.
> >
>
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
