hobo_fields 1.3.0.RC

data/lib/hobo_fields/types/textile_string.rb

@@ -0,0 +1,22 @@
+require 'redcloth'
+
+module HoboFields
+  module Types
+    class TextileString < HoboFields::Types::Text
+
+      include SanitizeHtml
+
+      def to_html(xmldoctype = true)
+        if blank?
+          ""
+        else
+          textilized = RedCloth.new(self, [ :hard_breaks ])
+          textilized.hard_breaks = true if textilized.respond_to?("hard_breaks=")
+          HoboFields::SanitizeHtml.sanitize(textilized.to_html)
+        end
+      end
+
+      HoboFields.register_type(:textile, self)
+    end
+  end
+end

data/lib/hobo_fields.rb

@@ -0,0 +1,94 @@
+require 'hobo_support'
+
+ActiveSupport::Dependencies.autoload_paths |= [ File.dirname(__FILE__) ]
+
+module Hobo
+  # Empty class to represent the boolean type.
+  class Boolean; end
+end
+
+module HoboFields
+
+  VERSION = File.read(File.expand_path('../../VERSION', __FILE__)).strip
+
+  extend self
+
+  PLAIN_TYPES = {
+    :boolean       => Hobo::Boolean,
+    :date          => Date,
+    :datetime      => ActiveSupport::TimeWithZone,
+    :time          => Time,
+    :integer       => Integer,
+    :decimal       => BigDecimal,
+    :float         => Float,
+    :string        => String
+  }
+
+  ALIAS_TYPES = {
+    Fixnum => "integer",
+    Bignum => "integer"
+  }
+
+  # Provide a lookup for these rather than loading them all preemptively
+
+  STANDARD_TYPES = {
+    :raw_html      => "RawHtmlString",
+    :html          => "HtmlString",
+    :raw_markdown  => "RawMarkdownString",
+    :markdown      => "MarkdownString",
+    :textile       => "TextileString",
+    :password      => "PasswordString",
+    :text          => "Text",
+    :email_address => "EmailAddress",
+    :serialized    => "SerializedObject"
+  }
+
+  @field_types   = PLAIN_TYPES.with_indifferent_access
+  @never_wrap_types = Set.new([NilClass, Hobo::Boolean, TrueClass, FalseClass])
+  attr_reader :field_types
+
+  def to_class(type)
+    if type.is_one_of?(Symbol, String)
+      type = type.to_sym
+      field_types[type] || standard_class(type)
+    else
+      type # assume it's already a class
+    end
+  end
+
+  def to_name(type)
+    field_types.key(type) || ALIAS_TYPES[type]
+  end
+
+  def can_wrap?(type, val)
+    col_type = type::COLUMN_TYPE
+    return false if val.blank? && (col_type == :integer || col_type == :float || col_type == :decimal)
+    klass = Object.instance_method(:class).bind(val).call # Make sure we get the *real* class
+    init_method = type.instance_method(:initialize)
+    [-1,1].include?(init_method.arity) &&
+      init_method.owner != Object.instance_method(:initialize).owner &&
+      !@never_wrap_types.any? { |c| klass <= c }
+  end
+
+  def never_wrap(type)
+    @never_wrap_types << type
+  end
+
+  def register_type(name, klass)
+    field_types[name] = klass
+  end
+
+  def plain_type?(type_name)
+    type_name.in?(PLAIN_TYPES)
+  end
+
+  def standard_class(name)
+    class_name = STANDARD_TYPES[name]
+    "HoboFields::Types::#{class_name}".constantize if class_name
+  end
+
+end
+
+require 'hobo_fields/railtie'
+
+

data/test/api.rdoctest

@@ -0,0 +1,244 @@
+# HoboFields API
+
+In order for the API examples to run we need to load the rails generators of our testapp:
+{.hidden}
+
+    doctest: prepare testapp environment
+    doctest_require: 'prepare_testapp'
+{.hidden}
+
+## Example Models
+
+Let's define some example models that we can use to demonstrate the API. With HoboFields we can use the 'hobo:model' generator like so:
+
+    $ rails generate hobo:model advert title:string body:text contact_address:email_address
+
+    >> Rails::Generators.invoke 'hobo:model', %w(advert title:string body:text contact_address:email_address)
+{.hidden}
+
+This will generate the test, fixture and a model file like this:
+
+    class Advert < ActiveRecord::Base
+      fields do
+        title :string
+        body :text
+        contact_address :email_address
+      end
+
+    end
+
+(Note: `:email_address` is an example of a "Rich Type" provided by HoboFields -- more on those later)
+
+The migration generator uses this information to create a migration. The following creates and runs the migration so we're ready to go.
+
+    $ rails generate hobo:migration -n -m
+
+    >> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+    >> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+{.hidden}
+
+We're now ready to start demonstrating the API
+
+## The Basics
+
+The main feature of HoboFields, aside from the migration generator, is the ability to declare rich types for your fields. For example, you can declare that a field is an email address, and the field will be automatically validated for correct email address syntax.
+
+### Field Types
+
+Field values are returned as the type you specify.
+
+        >> a = Advert.new :body => "This is the body"
+        >> a.body.class
+        => HoboFields::Types::Text
+
+This also works after a round-trip to the database
+
+        >> a.save
+        >> b = Advert.find(a.id)
+        >> b.body.class
+        => HoboFields::Types::Text
+
+HoboFields::Types::Text is a simple subclass of string. It's a "wrapper type", by which we mean you pass the underlying value to the constructor.
+
+        >> t = HoboFields::Types::Text.new("hello")
+        => "hello"
+        >> t.class
+        => HoboFields::Types::Text
+
+If you define your own rich types, they need to support a one argument constructor in the same way.
+
+Although the body of our advert is really just a string, it's very useful that it has a different type. For example, the view layer in Hobo Rapid would use this information to render a `<textarea>` rather than an `<input type='text'>` in an Advert form.
+
+
+## Names vs. Classes
+
+In the `fields do ... end` block you can give the field-type either as a name (symbol) or a class. For example, we could have said
+
+        body HoboFields::Types::Text
+
+Obviously the symbol form is a nicer:
+
+        body :text
+
+If you provide a class it must define the `COLUMN_TYPE` constant. This instructs the migration generator to create the appropriate underlying database column type. It should be a symbol that is a valid column type in a Rails migration.
+
+        >> HoboFields::Types::Text::COLUMN_TYPE
+        => :text
+
+The full set of available symbolic names is
+
+ * `:integer`
+ * `:float`
+ * `:decimal`
+ * `:string`
+ * `:text`
+ * `:boolean`
+ * `:date`
+ * `:datetime`
+ * `:html`
+ * `:textile`
+ * `:markdown`
+ * `:password`
+ * `:email_address`
+
+You can add your own types too. More on that later.
+
+
+## Model extensions
+
+HoboFields adds a few features to your models.
+
+### `Model.attr_type`
+
+Returns the type (i.e. class) declared for a given field or attribute
+
+        >> Advert.attr_type :title
+        => String
+        >> Advert.attr_type :body
+        => HoboFields::Types::Text
+
+### `Model.column`
+
+A shorthand for accessing column metadata
+
+        >> col = Advert.column :title
+        >> col.name
+        => "title"
+        >> col.klass
+        >> String
+
+### `Model.attr_accessor` with types
+
+In your HoboFields models you can also give type information to "virtual fields" (i.e. regular Ruby attributes)
+
+        >>
+         class Advert
+           attr_accessor :my_attr, :type => :text
+         end
+        >> a = Advert.new
+        >> a.my_attr = "hello"
+        >> a.my_attr.class
+        => HoboFields::Types::Text
+
+
+## Field validations
+
+HoboFields gives you some shorthands for declaring some common validations right in the field declaration
+
+### Required fields
+
+The `:required` argument to a field gives a `validates_presence_of`:
+
+        >>
+         class Advert
+           fields do
+             title :string, :required
+           end
+         end
+        >> a = Advert.new
+        >> a.valid?
+        => false
+        >> a.errors.full_messages
+        => ["Title can't be blank"]
+        >> a.title = "Jimbo"
+        >> a.save
+        => true
+
+
+### Unique fields
+
+The `:unique` argument in a field declaration gives `validates_uniqueness_of`:
+
+        >>
+         class Advert < ActiveRecord::Base
+           fields do
+             title :string, :unique
+           end
+         end
+        >> a = Advert.new :title => "Jimbo"
+        >> a.valid?
+        => false
+        >> a.errors.full_messages
+        => ["Title has already been taken"]
+        >> a.title = "Sambo"
+        >> a.save
+        => true
+
+Let's get back to the basic Advert class with no validations before we continue:
+
+        >> ActiveSupport::Dependencies.remove_constant "Advert"
+        >>
+         class Advert < ActiveRecord::Base
+           fields do
+             title           :string
+             body            :text
+                  contact_address :email_address
+           end
+         end
+
+
+### Type specific validations
+
+Rich types can define there own validations by a `#validate` method. It should return an error message if the value is invalid, otherwise nil. We can call that method directly to show how it works:
+
+        >> a = Advert.new :contact_address => "not really an email address"
+        >> a.contact_address.class
+        => HoboFields::Types::EmailAddress
+        >> a.contact_address.validate
+        => "is invalid"
+
+But normally that method would be called for us during validation:
+
+        >> a.valid?
+        => false
+        >> a.errors.full_messages
+        => ["Contact address is invalid"]
+        >> a.contact_address = "me@me.com"
+        >> a.valid?
+        => true
+
+You can add this capability to your own rich types just by defining `#validate`
+
+### Validating virtual fields
+
+You can set the type of a virtual field to a rich type, e.g.
+
+        >>
+         class Advert
+           attr_accessor :alternative_email, :type => :email_address
+         end
+
+By default, virtual fields are not subject to validation.
+
+        >> a = Advert.new :alternative_email => "woot!"
+        >> a.valid?
+        => true
+
+To have them validated use `validate_virtual_field`:
+
+        >>
+         class Advert
+           validate_virtual_field :alternative_email
+         end
+        >> a.valid?
+        => false

data/test/doc-only.rdoctest

@@ -0,0 +1,96 @@
+# HoboFields
+
+## Introduction
+
+Welcome to HoboFields -- a spin-off from the Hobo project (Hobo not required!).
+
+**HoboFields writes your Rails migrations for you! Your migration writing days are over!**
+
+All we ask is that you declare your fields in the model. It's still perfectly DRY because you're not having to repeat that in the migration -- HoboFields does that for you. In fact, you'll come to love having them there.
+
+It still has all the benefits of writing your own migrations, for example if you want to add some special code to migrate your old data, you can just edit the generated migration.
+
+## Example
+
+First off, if you're using the migration generator outside of Hobo, do remember the `--skip-migration` option when generating your models:
+
+        $ rails generate model blog_post --skip-migration
+
+Now edit your model as follows:
+
+    class BlogPost < ActiveRecord::Base
+      fields do
+        title :string
+        body  :text
+        timestamps
+      end
+    end
+{: .ruby}
+
+
+Then, simply run
+
+        $ rails generate hobo:migration
+
+And voila
+
+        ---------- Up Migration ----------
+        create_table :blog_posts do |t|
+          t.string   :title
+          t.text     :body
+          t.datetime :created_at
+          t.datetime :updated_at
+        end
+        ----------------------------------
+
+        ---------- Down Migration --------
+        drop_table :blog_posts
+        ----------------------------------
+{: .ruby}
+
+The migration generator has created a migration to change from the schema that is currently in your database, to the schema that your models need. That's really all there is to it. You are now free to simply hack away on your app and run the migration generator every time the database needs to play catch-up.
+
+Note that the migration generator is interactive -- it can't tell the difference between renaming something vs. adding one thing and removing another, so sometimes it will ask you to clarify. It's a bit picky about what it makes you type in response, because we really don't want you to lose data when someone's amazing twitter distracts you at the wrong moment.
+
+## Installing
+
+The simplest and recommended way to install HoboFields is as a gem:
+
+        $ gem install hobo_fields
+
+The source lives on GitHub as part of the main Hobo repo:
+
+ - [http://github.com/tablatom/hobo](http://github.com/tablatom/hobo)
+
+To use hobo_fields as a plugin is not as simple as it should be.  You
+will have to clone `git://github.com/tablatom/hobo` and then copy the
+`hobo_fields` subdirectory into `/vendors/plugins`
+
+## Rich Types
+
+In addition to the migration generator, HoboFields provides a Rich-Type mechanism that allows you to declare your fields using higher level concepts like "email-address" or "markdown text". This can give you both automatic validations, and automatic rendering of those values in the UI (this works particularly well if you use the rest of Hobo).
+
+Read more:
+
+ - [HoboFields Rich Types](/manual/hobo_fields/rich_types)
+
+## API
+
+HoboFields provides various API methods. Read more:
+
+ - [HoboFields API](/manual/hobo_fields/hobo_fields_api)
+
+## Migration Generator Details
+
+The migration generator doctests provide a lot more detail. They're not really that great as documentation because doctests run in a single irb session, and that doesn't fit well with the concept of a generator. Skip these unless you're really keen to see the details of the migration generator in action
+
+ - [Migration Generator Details](/manual/hobo_fields/migration_generator)
+
+## About Doctests
+
+HoboFields is documented and tested using *doctests*. This is an idea that comes from Python that we've been experimenting with for Hobo. Whenever you see code-blocks that start "`>>`", read them as IRB sessions. The `rdoctest` tool extracts these and runs them to verify they behave as advertised.
+
+Doctests are a great way to get both documentation and tests from the same source. We're still experimenting with exactly how this all works though, so if the docs seem strange in places, please bear with us!
+
+You may download rubydoctest via [github](http://www.github.com/tablatom/rubydoctest)
+

data/test/generators.rdoctest

@@ -0,0 +1,53 @@
+doctest: prepare testapp environment
+doctest_require: 'prepare_testapp'
+
+doctest: generate hobo:model
+>> Rails::Generators.invoke 'hobo:model', %w(alpha/beta one:string two:integer)
+
+
+doctest: model file exists
+>> File.exist? 'app/models/alpha/beta.rb'
+=> true
+
+doctest: model content matches
+>> File.read 'app/models/alpha/beta.rb'
+=> "class Alpha::Beta < ActiveRecord::Base\n\n  fields do\n    one :string\n    two :integer\n  end\n\nend\n"
+
+doctest: module file exists
+>> File.exist? 'app/models/alpha.rb'
+=> true
+
+doctest: module content matches
+>> File.read 'app/models/alpha.rb'
+=> "module Alpha\n  def self.table_name_prefix\n    'alpha_'\n  end\nend\n"
+
+
+doctest: test file exists
+>> File.exist? 'test/unit/alpha/beta_test.rb'
+=> true
+
+doctest: test content matches
+>> File.read 'test/unit/alpha/beta_test.rb'
+=> "require 'test_helper'\n\nclass Alpha::BetaTest < ActiveSupport::TestCase\n  # Replace this with your real tests.\n  test \"the truth\" do\n    assert true\n  end\nend\n"
+
+
+doctest: fixture file exists
+>> File.exist? 'test/fixtures/alpha/betas.yml'
+=> true
+
+
+doctest: generate hobo:migration
+>> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+
+doctest: schema.rb file exists
+>> File.exist? 'db/schema.rb'
+=> true
+
+doctest: db file exists
+>> File.exist? 'db/development.sqlite3'
+=> true
+
+doctest: Alpha::Beta class exists
+>> Alpha::Beta
+=> Alpha::Beta(id: integer, one: string, two: integer)
+

data/test/interactive_primary_key.rdoctest

@@ -0,0 +1,54 @@
+-*- indent-tabs-mode:nil; -*-
+
+# HoboFields - Migration Generator
+
+Our test requires to prepare the testapp:
+{.hidden}
+
+    doctest_require: 'prepare_testapp'
+
+{.hidden}
+
+And requires also that you enter the right choice when prompted. OK we're ready to get going.
+
+## Alternate Primary Keys
+
+### create
+   doctest: create table with custom primary_key
+   >>
+    class Foo < ActiveRecord::Base
+      fields do
+      end
+      set_primary_key "foo_id"
+    end
+   >> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+   >> Foo.primary_key
+   => 'foo_id'
+
+### migrate from
+   doctest: rename from custom primary_key
+   >>
+    class Foo < ActiveRecord::Base
+      set_primary_key "id"
+    end
+   >> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+   >> Foo.primary_key
+   => 'id'
+
+### migrate to
+
+   doctest: rename to custom primary_key
+   >>
+    class Foo < ActiveRecord::Base
+      set_primary_key "foo_id"
+    end
+   >> Rails::Generators.invoke 'hobo:migration', %w(-n -m)
+   >> Foo.primary_key
+   => 'foo_id'
+
+### ensure it doesn't cause further migrations
+
+   doctest: check no further migrations
+   >> up, down = Generators::Hobo::Migration::Migrator.run
+   >> up
+   => ""