RFM Roadmap (2011)

[wbr]

First, I want to say how much I love RFM and how much I appreciate all
of the hard work that has gone into it. Our business relies heavily on
Ruby scripts and applications that talk to Filemaker using RFM.

Over the last few years, I've written a good deal of code that uses
the metadata features of RFM. Unfortunately, those features have been
broken in the latest releases of RFM. I've been smoothly sailing along
with lardawge-rfm 1.4.0, adding in my own patches and enhancements as
needed. But I need to move on to the current version of RFM, and more
importantly, I need to be able to tell customers that the latest
version is stable and works "as advertised". I'd like to be able to
say (with a straight face) that RFM is actively maintained & developed
and that Ruby, Rails, Sinatra, etc are an excellent choice of
technologies to extend the functionality of Filemaker.

I'm not sure how to best apply my efforts to the greater good, but I
see 3 general options:

1. Contribute to the current lardawge-rfm project
2. Take over some or all of the rfm project as my own
3. Develop my own rfm project and stop bothering everyone else

My immediate goals are to fix the following issues:
- server.db.all
- db.layout.all
- db.script.all
- layout.field_controls
- layout.value_lists
- inaccurate description of the server setting :user_account
as :username, on the main README
- incorporate the pull request for :timeout server setting

The metadata fixes and README are done, and I'm just about to merge
the :timeout feature. Future goals include fleshing out the specs,
adding some missing filemaker errors, and continuing to cleanup and
refine the general body of code. However, the very next thing I want
to do is merge my ActiveModel implementation of RFM. I use it on most
of my projects, and it just feels like part of RFM to me. It's nothing
fancy, and it doesn't change the way RFM works. But it lets you create
basic models that behave like ActiveRecord.

# Set server config
Rfm::Base.config {
:host => 'myservername',
:account_name => 'user',
:password => 'pw',
:port => 8080,
:ssl => false
}

# Define a model
class Person < Rfm::Base
config :layout=>'person'
end

# Create, find, edit records with your model
p = Person.new(:name=>'bill', :occupation=>'developer')
p.save

p = Person.find(:name=>'bill')
p.occupation = 'chef'
p.save

# Run callbacks & validations on your model
class Person
before_save :do_something_here
after_validate :do_something_else
validates_existence_of :name
end


So… This is where I'm headed, and I'm wondering what Larry, the other
developers, and everyone else thinks about it?

If anyone wants to try out the code I'm working on, which includes the
above mentioned fixes (but not the ActiveModel implementation), it's
on rubygems.org and github as ginjo-rfm. The code starts up where
lardawge-rfm left off.

# 1.4.2.pre3
gem install ginjo-rfm --pre

# Master
github.com/ginjo/rfm

# In your app
gem 'ginjo-rfm'
require 'rfm'

[wbr]

Well... awfully quiet in here... hope I'm not stepping on any toes by
messing with RFM :)

Here's where I am with ginjo-rfm:

* Github (https://github.com/ginjo/rfm)

- Branch "fixes" contains basic fixes and is compatible with lardawge-
rfm. This branch of rfm is still lardawge-rfm. You should be able to
merge this into lardawge-rfm with minimal effort. Fixes start here
before merging into Master and Modeling.

- Branch "modeling" contains an Rfm::Base class adding ActiveModel
functionality, slated for ginjo-rfm 1.5.

- Master branch is leading to ginjo-rfm 1.4.2, which will bring bug
fixes and reinstating of metadata functionality.

* Rubygems (https://rubygems.org/gems/ginjo-rfm)

I'm currently using the latest ginjo-rfm-1.4.2.pre gem on my
development machines, and it's working well for me. The field_controls
and value_lists functions appear to be working as before, and several
bugs in the record model appear to have been fixed.

* ValueListItem. One minor feature enhancement is the ValueListItem.
This represents one item of a value list. It is subclassed from string
and should behave just as the older RFM value list items. The one
feature enhancement I've added is support for value lists that contain
both item "value" and item "display". You can get both of these values
now from the new ValueListItem class:

list = my_layout.value_lists
-> {:states=>['AL', 'AK', ...], :countries=>[...]}

item = list[:states][0]
-> 'AL'

item.value -> 'AL'
item.display -> 'Alabama'

* Database, layout, and script meta. I've begun to reinstate the
functions that return a list of databases, layouts, and scripts from a
specified Filemaker Server. The data comes back, but there's a
recursion happening somewhere that I'm still trying to get my head
around. I'm calling this a bug unless someone points out that it's
working exactly as it should.

I'm happy to hear from anyone with an opinion on this stuff, positive
or negative. Especially from the current developer and maintainers.
Also note that this is my first foray into open-source gem
development. Please pipe up if you think I'm about to take the train
off a cliff.

Thanks,
Bill

[wbr]

I've released ginjo-rfm 1.4.2 to rubygems. Ginjo-rfm 1.4.2 fixes the
issues mentioned in my previous posts and should be compatible with
any code that uses lardawge-rfm. Some hightlights:

* Re-instated meta functions: field_controls, value_lists, server
databases, database layouts, database scripts.

* Merged Tim Ting's server timeout feature {:timeout=>60}

* Fixed bugs in Record class: getters, setters, save.

* Added valuelist functions to support dual valuelist items - value vs
display.

* Added a few more specs.

Install:

#bash
gem install ginjo-rfm

In your code:

#ruby
require 'rubygems'
require 'rfm'

Using bundler and/or Rails >=3.0

#gemfile
gem 'ginjo-rfm'

For Larry and any others interested in pulling these changes into
their repos, I'm maintaining several branches on github.

* The 'fixes' branch contains patches & fixes to basic functionality
and should be mergeable with lardawge-rfm (it's still essentially the
lardawge-rfm gem). I'll continue to put fixes that are compatible with
lardawge-rfm into this branch.

* The 'master' branch is ginjo-rfm and merges 'fixes'. Master will
lead the current release of ginjo-rfm. The latest builds and upcoming
patches to ginjo-rfm will be here.

* The 'edge' branch will contain everything I'm working on for the
next major or minor release of ginjo-rfm.

Speaking of edge, I've been working on version 1.5.0 which brings
alternative XML parsers and ActiveModel compatibility to ginjo-rfm.
[Check it out on github](https://github.com/ginjo/rfm).

#gemfile:
gem 'ginjo-rfm', :git=>'git://github.com/ginjo/
rfm.git', :branch=>'edge'

I'm a little short on documentation for the new features. If you want
to try something out and can't get it going, feel free to post here.
Also, Larry's rdoc, Sixfriedrice, and the README's are still great
resources for all things rfm.


-Bill

[wbr]

For anyone interested, I've released ginjo-rfm 1.4.4. I'm running it
on several of my Rails apps, and it's working great. From the
changelog:

* Fixed bug when creating empty value list.

* Additional fixes for Rfm::VERSION.

* Fixed Record getter/setter issue (miss-matched case was producing
errors).

* Other minor fixes and cleanup.

* Added tests to rspec.

* Documentation cleanup.

Would be happy to hear from anyone using this - is it working? bugging
out? crashing? Or feel free to hit the issue tracker on github
https://github.com/ginjo/rfm/issues.

Meanwhile, I'm running the prerelease version of ginjo-rfm 2.0 (or
should it be 1.5?) on some of my Rails 3 apps. ActiveModel
compatibility and multiple XML parsers are the two highlights. I will
also be adding a Layout#query method, which allows complex Filemaker
queries (multiple find requests with combination of and/or logic).
This upcoming version should be mostly backward compatible with
previous versions of rfm (ginjo, lardawge, original SFR), at least as
far as the basic functions go. Things may change a bit are under the
hood. I'm working on streamlining the relationship between the main
models - Server, Database, Layout, Restultset, Record - so that you
can reach the objects and metadata that you want, from anywhere.

-Bill

[wbr]

Hmm... Well, I don't know if anyone's listening, but I'm just gonna
keep posting with updates. I've been putting a lot of work into rfm,
and I hope that others can benefit from it as much as I have.

I've pushed ginjo-rfm 2.0.pre31 to rubygems.org. It's mostly
compatible with previous version of Rfm, but there are a lot of
changes under the hood to accommodate data modeling and alternative
xml parsers - thus the bump in major version number. See the
instructions on the rubygems page to install pre-release versions.

https://rubygems.org/gems/ginjo-rfm/versions/2.0.pre31

Documentation is still a little thin, but there should be enough to
get you started.

http://rubydoc.info/github/ginjo/rfm/frames

As always, I'm happy to get feedback, good or bad, here or on the
issue tracker.

https://github.com/ginjo/rfm/issues


Cheers,
Bill

[Stephen Cremin]

I'm also using RFM with a production application, that's been online for 18 months, frozen on the 1.4.1.2 lardawge-rfm gem.

I'm thrilled to hear that someone has kicked life back into RFM (and the list) and will check out your gem in the coming days.

Keep posting your updates.

Stephen

Bill

--
You received this message because you are subscribed to the Google Groups "RFM Community" group.
To post to this group, send email to rfmcom...@googlegroups.com.
To unsubscribe from this group, send email to rfmcommunity...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rfmcommunity?hl=en.

[wbr]

Ok, ginjo-rfm 2.0.0 has been released to gemcutter/rubygems.

https://rubygems.org/gems/ginjo-rfm

There is one possible issue which isn't really a bug but more like
fallout from the practice of ActiveSupport not including certain
required gems in their dependencies. i18n is a gem that is required by
ActiveSupport::XmlMini, but i18n isn't included in ActiveSupport's
runtime dependencies. If you are using a version of ActiveSupport that
requires i18n, and your ruby can't find i18n in the load path, you
will get an exception. The solution is to gem install i18n and/or gem
'i18n' in your Gemfile. But this won't be necessary for everyone.

If you load ActiveModel, i18n should be handled automatically.
If you're running ActiveSupport 2.3.5, i18n will not be required.
If you're running ActiveSupport 3.1.3 without ActiveModel, you will
need to manually handle i18n.


Bill

[Chong-Yee Khoo]

Thank you Bill, for keeping rfm alive!

I am not currently using rfm but plan to do so in the next few weeks/
months. I look forward to using it.

Regards,

Chong-Yee

[wbr]

Glad to hear it. Hope it's working well for everyone who's using it.
If not, please speak up here or file a bug report on github.

One thing I'm curious about is how performance has been for people
using the various XML backends. In my experience, ginjo-rfm 2.0.0 with
the ox gem is rip-roaring fast. But I haven't benchmarked it against
any version of rfm 1.4.x with nokogiri in a real-world situation.

Bill