hobofields 0.7.5 → 0.8

data/test/hobofields_api.rdoctest

@@ -9,6 +9,7 @@ In order for the API examples to run we need a connection to a database. You can
     >> Dependencies.load_paths << '.'
     >> Dependencies.mechanism = :require
     >> require 'activerecord'
+    >> require 'action_controller'
     >> require 'hobofields'
     >> mysql_database = "hobofields_doctest"
     >> system("mysqladmin create #{mysql_database}") or raise "could not create database"
@@ -35,7 +36,7 @@ The migration generator uses this information to create a migration. The followi
 
 	>> up, down = HoboFields::MigrationGenerator.run
 	>> ActiveRecord::Migration.class_eval up
-	
+
 We're now ready to start demonstrating the API
 
 ## The Basics
@@ -49,7 +50,7 @@ Field values are returned as the type you specify.
 	>> a = Advert.new :body => "This is the body"
 	>> a.body.class
 	=> HoboFields::Text
-	
+
 This also works after a round-trip to the database
 
 	>> a.save
@@ -57,35 +58,35 @@ This also works after a round-trip to the database
 	>> b.body.class
 	=> HoboFields::Text
 
-HoboFields::Text is a simple subclass of string. It's a "wrapper type", by which we mean you pass the underlying value to the constructor. 
+HoboFields::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::Text.new("hello")
 	=> "hello"
 	>> t.class
 	=> HoboFields::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::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. 
+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::Text::COLUMN_TYPE
 	=> :text
-	
+
 The full set of available symbolic names is
-  
+
  * `:integer`
  * `:big_integer`
  * `:float`
@@ -104,9 +105,9 @@ 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
@@ -115,7 +116,7 @@ Returns the type (i.e. class) declared for a given field or attribute
 	=> String
 	>> Advert.attr_type :body
 	=> HoboFields::Text
-	
+
 ### `Model.column`
 
 A shorthand for accessing column metadata
@@ -136,9 +137,9 @@ In your HoboFields models you can also give type information to "virtual fields"
 	end
 	>> a = Advert.new
 	>> a.my_attr = "hello"
-	>> a.my_attr.class 
+	>> a.my_attr.class
 	=> HoboFields::Text
-	
+
 
 ## Field validations
 
@@ -148,7 +149,7 @@ HoboFields gives you some shorthands for declaring some common validations right
 
 The `:required` argument to a field gives a `validates_presence_of`:
 
-	>> 
+	>>
 	class Advert
 	  fields do
 	    title :string, :required
@@ -162,13 +163,13 @@ The `:required` argument to a field gives a `validates_presence_of`:
 	>> 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
@@ -182,9 +183,9 @@ The `:unique` argument in a field declaration gives `validates_uniqueness_of`:
 	>> a.title = "Sambo"
 	>> a.save
 	=> true
-	
+
 Let's get back to the basic Advert class with no validations before we continue:
-   
+
 	>> Dependencies.remove_constant "Advert"
 	>>
 	class Advert < ActiveRecord::Base
@@ -195,7 +196,7 @@ Let's get back to the basic Advert class with no validations before we continue:
 	  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:
@@ -205,9 +206,9 @@ Rich types can define there own validations by a `#validate` method. It should r
 	=> HoboFields::EmailAddress
 	>> a.contact_address.validate
 	=> "is not valid"
-	
+
 But normally that method would be called for us during validation:
-	
+
 	>> a.valid?
 	=> false
 	>> a.errors.full_messages
@@ -215,9 +216,9 @@ But normally that method would be called for us during validation:
 	>> 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.
@@ -226,7 +227,7 @@ 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!"
@@ -241,7 +242,7 @@ To have them validated use `validate_virtual_field`:
 	end
 	>> a.valid?
 	=> false
-	
+
 ## Cleanup
 
     >> system  "mysqladmin --force drop #{mysql_database}"

data/test/migration_generator.rdoctest

@@ -8,10 +8,11 @@ Firstly, in order to test the migration generator outside of a full Rails stack,
     >> require 'activesupport'
     >> Dependencies.load_paths << '.'
     >> Dependencies.mechanism = :require
-    
+
 And we'll require:
 
     >> require 'activerecord'
+    >> require 'action_controller'
     >> require 'hobofields'
 
 We also need to get ActiveRecord set up with a database connection
@@ -36,12 +37,12 @@ The migration generator works by:
 Normally you would run the migration generator as a regular Rails generator. You would type
 
     $ script/generator hobo_migration
-    
-in your Rails app, and the migration file would be created in `db/migrate`. 
 
-In order to demonstrate the generator in this doctest script however, we'll be using the Ruby API instead. The method `HoboFields::MigrationGenerator.run` returns a pair of strings -- the up migration and the down migration. 
+in your Rails app, and the migration file would be created in `db/migrate`.
 
-At the moment the database is empty and no ActiveRecord models exist, so the generator is going to tell us there is nothing to do. 
+In order to demonstrate the generator in this doctest script however, we'll be using the Ruby API instead. The method `HoboFields::MigrationGenerator.run` returns a pair of strings -- the up migration and the down migration.
+
+At the moment the database is empty and no ActiveRecord models exist, so the generator is going to tell us there is nothing to do.
 
     >> HoboFields::MigrationGenerator.run
     => ["", ""]
@@ -59,8 +60,8 @@ The migration generator only takes into account classes that use HoboFields, i.e
 ### Create the table
 
 Here we see a simple `create_table` migration along with the `drop_table` down migration
-    
-    >> 
+
+    >>
     class Advert < ActiveRecord::Base
       fields do
         name :string
@@ -74,20 +75,20 @@ Here we see a simple `create_table` migration along with the `drop_table` down m
     end
     >> down
     => "drop_table :adverts"
-    
+
 Normally we would run the generated migration with `rake db:create`. We can achieve the same effect directly in Ruby like this:
 
     >> ActiveRecord::Migration.class_eval up
     >> Advert.columns.*.name
     => ["id", "name"]
-    
+
 We'll define a method to make that easier next time
 
     >>
     def migrate(renames={})
       up, down = HoboFields::MigrationGenerator.run(renames)
       puts up
-      ActiveRecord::Migration.class_eval(up)  
+      ActiveRecord::Migration.class_eval(up)
       ActiveRecord::Base.send(:subclasses).each { |model| model.reset_column_information }
       [up, down]
     end
@@ -134,7 +135,7 @@ If we remove a field from the model, the migration generator removes the databas
     => "remove_column :adverts, :published_at"
     >> down
     => "add_column :adverts, :published_at, :datetime"
-    
+
 ### Rename a field
 
 Here we rename the `name` field to `title`. By default the generator sees this as removing `name` and adding `title`.
@@ -157,7 +158,7 @@ Here we rename the `name` field to `title`. By default the generator sees this a
     remove_column :adverts, :title
     add_column :adverts, :name, :string
     >>
-    
+
 When run as a generator, the migration-generator won't make this assumption. Instead it will prompt for user input to resolve the ambiguity. When using the Ruby API, we can ask for a rename instead of an add + drop by passing in a hash:
 
     >> up, down = HoboFields::MigrationGenerator.run(:adverts => { :name => :title })
@@ -165,12 +166,12 @@ When run as a generator, the migration-generator won't make this assumption. Ins
     => "rename_column :adverts, :name, :title"
     >> down
     => "rename_column :adverts, :title, :name"
-    
+
 Let's apply that change to the database
 
     >> migrate
-    
-    
+
+
 ### Change a type
 
     >> Advert.attr_type :title
@@ -184,13 +185,13 @@ Let's apply that change to the database
     end
     >> up, down = HoboFields::MigrationGenerator.run
     >> up
-    => "change_column :adverts, :title, :text"
+    => "change_column :adverts, :title, :text, :limit => nil"
     >> down
     => "change_column :adverts, :title, :string"
-    
-    
+
+
 ### Add a default
-    
+
     >>
     class Advert
       fields do
@@ -200,11 +201,41 @@ Let's apply that change to the database
     end
     >> up, down = migrate
     >> up
-    => 'change_column :adverts, :title, :string, :default => "Untitled"'
+    => 'change_column :adverts, :title, :string, :default => "Untitled", :limit => 255'
     >> down
     => "change_column :adverts, :title, :string"
+    
+    
+### Limits
+
+    >>
+    class Advert
+      fields do
+        price :integer, :limit => 4
+      end
+    end
+    >> up, down = HoboFields::MigrationGenerator.run
+    >> up
+    "add_column :advert, :integer, :limit => 4"
 
 
+Note that limit on a decimal column is ignored (use :scale and :precision)
+    
+    >>
+    class Advert
+      fields do
+        price :decimal, :limit => 4
+      end
+    end
+    >> up, down = HoboFields::MigrationGenerator.run
+    >> up
+    => "add_column :adverts, :price, :decimal"
+
+Cleanup
+
+    >> Advert.field_specs.delete :price
+    
+
 ### Foreign Keys
 
 HoboFields extends the `belongs_to` macro so that it also declares the foreign-key field.
@@ -218,13 +249,13 @@ HoboFields extends the `belongs_to` macro so that it also declares the foreign-k
 	=> 'add_column :adverts, :category_id, :integer'
 	>> down
 	=> 'remove_column :adverts, :category_id'
-	
+
 Cleanup:
 
 	>> Advert.field_specs.delete(:category_id)
-	
+
 If you specify a custom foreign key, the migration generator observes that:
-    
+
 	>>
 	class Advert
 	  belongs_to :category, :foreign_key => "c_id"
@@ -234,12 +265,12 @@ If you specify a custom foreign key, the migration generator observes that:
 	=> 'add_column :adverts, :c_id, :integer'
 	>> down
 	=> 'remove_column :adverts, :c_id'
-	
+
 Cleanup:
 
 	>> Advert.field_specs.delete(:c_id)
-	
-	
+
+
 ### Timestamps
 
 `updated_at` and `created_at` can be declared with the shorthand `timestamps`
@@ -252,7 +283,7 @@ Cleanup:
 	end
 	>> up, down = HoboFields::MigrationGenerator.run
 	>> up
-	=>"" 
+	=>""
 	add_column :adverts, :created_at, :datetime
 	add_column :adverts, :updated_at, :datetime
 	>> down
@@ -260,13 +291,13 @@ Cleanup:
 	remove_column :adverts, :created_at
 	remove_column :adverts, :updated_at
 	>>
-	
+
 Cleanup:
 
 	>> Advert.field_specs.delete(:updated_at)
 	>> Advert.field_specs.delete(:created_at)
 
-    
+
 ### Rename a table
 
 The migration generator respects the `set_table_name` declaration, although as before, we need to explicitly tell the generator that we want a rename rather than a create and a drop.
@@ -284,7 +315,7 @@ The migration generator respects the `set_table_name` declaration, although as b
     => "rename_table :adverts, :ads"
     >> down
     => "rename_table :ads, :adverts"
-    
+
 Set the table name back to what it should be and confirm we're in sync:
 
     >> class Advert; set_table_name "adverts"; end
@@ -296,7 +327,7 @@ Set the table name back to what it should be and confirm we're in sync:
 If you delete a model, the migration generator will create a `drop_table` migration. Unfortunately there's no way to fully remove the Advert class we've defined from the doctest session, but we can tell the migration generator to ignore it.
 
     >> HoboFields::MigrationGenerator.ignore_models = [ :advert ]
-    
+
 Dropping tables is where the automatic down-migration really comes in handy:
 
     >> up, down = HoboFields::MigrationGenerator.run
@@ -309,7 +340,7 @@ Dropping tables is where the automatic down-migration really comes in handy:
       t.string "title", :default => "Untitled"
     end
 	>>
-    
+
 ### Rename a table
 
 As with renaming columns, we have to tell the migration generator about the rename. Here we create a new class 'Advertisement'. Remember 'Advert' is being ignored so it's as if we renamed the definition in our models directory.
@@ -326,11 +357,11 @@ As with renaming columns, we have to tell the migration generator about the rena
     => "rename_table :adverts, :advertisements"
     >> down
     => "rename_table :advertisements, :adverts"
-    
+
 Now that we've seen the renaming we'll switch the 'ignore' setting to ignore that 'Advertisements' class.
-    
+
     >> HoboFields::MigrationGenerator.ignore_models = [ :advertisement ]
-    
+
 ## STI
 
 ### Adding an STI subclass
@@ -345,14 +376,14 @@ Adding a subclass should introduce the 'type' column and no other changes
 	=> "add_column :adverts, :type, :string"
 	>> down
 	=> "remove_column :adverts, :type"
-	
+
 Cleanup
 
 	>> Advert.field_specs.delete(:type)
 
 
 ## Coping with multiple changes
-    
+
 The migration generator is designed to create complete migrations even if many changes to the models have taken place.
 
 First let's confirm we're in a known state. One model, 'Advert', with a string 'title' and text 'body':
@@ -363,7 +394,7 @@ First let's confirm we're in a known state. One model, 'Advert', with a string '
     => ["id", "body", "title"]
     >> HoboFields::MigrationGenerator.run
     => ["", ""]
-    
+
 
 ### Rename a column and change the default
 
@@ -379,16 +410,16 @@ First let's confirm we're in a known state. One model, 'Advert', with a string '
     >> up
     =>""
     rename_column :adverts, :title, :name
-    change_column :adverts, :name, :string, :default => "No Name"
+    change_column :adverts, :name, :string, :default => "No Name", :limit => 255
     >> down
     =>""
     rename_column :adverts, :name, :title
     change_column :adverts, :title, :string, :default => "Untitled"
     >>
-    
-    
+
+
 ### Rename a table and add a column
-    
+
     >> HoboFields::MigrationGenerator.ignore_models << :advert
     class Ad < ActiveRecord::Base
       fields do
@@ -401,9 +432,10 @@ First let's confirm we're in a known state. One model, 'Advert', with a string '
     >> up
     =>""
     rename_table :adverts, :ads
-    
+
     add_column :ads, :created_at, :datetime
     >>
+    
 
 ## Cleanup
 

data/test/rich_types.rdoctest

@@ -1,21 +1,21 @@
 # HoboFields -- Rich Types
 
 This doctest describes the rich types bundles with HoboFields, and the process by which you can create and register your own types.
-	
+
 	>> require 'rubygems'
 	>> require 'activesupport'
 	>> Dependencies.load_paths << '.'
 	>> Dependencies.mechanism = :require
 	>> require 'activerecord'
 	>> require 'hobofields'
-	
+
 
 ## `to_html` method
 
 The rich types provide a `to_html` method. If you are using the full Hobo stack you don't need to be aware of this unless you're defining your own rich types -- the `<view>` tag uses `to_html` to render a rich type. If you are not using DRYML and Rapid, you can simply call `to_html` in your views, e.g.
-	
+
 	<div class="post-body"><%= @post.body.to_html %></div>
-	
+
 If you ever decide to change from, say, plain text to markdown formatted, your view won't need to change.
 
 ## Defining your own Rich Type
@@ -24,25 +24,25 @@ Defining a rich type is very simple. We'll show an example here before we go thr
 
 This class defines the methods `to_html` to customize the way the type is rendered, and `validate` to provide a custom validation. It also defined the `COLUMN_TYPE` constant to tell the migration generator what underlying type should represent these values in the database.
 
-	# Loud text always renderd in caps. 
-	# It's rude to shout too much so it's not allowed to be 
+	# Loud text always renderd in caps.
+	# It's rude to shout too much so it's not allowed to be
 	# longer than 100 characters
 	class LoudText < String
-	
+
       COLUMN_TYPE = :string
 
 	  HoboFields.register_type(:loud, self)
-	
+
 	  def validate
 	    "is too long (you shouldn't shout that much)" if length > 100
 	  end
-	
-	  def to_html
+
+	  def to_html(xmldoctype = true)
 	    upcase
 	  end
-	
+
 	end
-	
+
 That's all there is to it. Defining `to_html` and `validate` are optional, defining `COLUMN_TYPE` and calling `HoboFields.register_type` are not.
 
 
@@ -77,13 +77,13 @@ Provides validation of correct email address format.
 	>> require 'bluecloth'
 	>> markdown = HoboFields::MarkdownString.new %(
 	# This is a heading
-	
+
 	And text can be *emphasised*
 	)
 	>> markdown.to_html
 	=>""
 	<h1>This is a heading</h1>
-	
+
 	<p>And text can be <em>emphasised</em></p>
 	>>
 
@@ -105,7 +105,7 @@ Provides validation of correct email address format.
 `HoboFields::Text` provides a `to_html` method with HTML escaping and conversion of newlines to `<br />` tags.
 
 	>> text = HoboFields::Text.new %(Tom & Jerry
-	
+
 	Cat & Mouse)
 	>> text.to_html
 	=>""
@@ -125,7 +125,7 @@ Provides validation of correct email address format.
 
 	>> ArticleStatus = HoboFields::EnumString.for(:draft, :approved, :published)
 	=> ArticleStatus
-	
+
 Note that, like all dynamically created classes in Ruby, the class is anonymous until assigned to a constant:
 
 	>> klass = HoboFields::EnumString.for(:draft, :approved, :published)
@@ -133,14 +133,14 @@ Note that, like all dynamically created classes in Ruby, the class is anonymous
 	>> AritcleStatus = klass
 	>> ArticleStatus
 	=> ArticleStatus
-	
+
 The values in the enum are available as class constants:
 
 	>> ArticleStatus::DRAFT
 	=> "draft"
 	>> ArticleStatus::DRAFT.class
 	=> ArticleStatus
-	
+
 There are also instance methods to check for each of the values:
 
 	>> a = ArticleStatus::APPROVED
@@ -148,29 +148,29 @@ There are also instance methods to check for each of the values:
 	=> false
 	>> a.is_approved?
 	=> true
-	
+
 They can be constructed from strings:
 
 	>> a = ArticleStatus.new("approved")
 	>> a.is_approved?
 	=> true
-	
+
 Equality is string equality, with symbols first converted to strings:
 
 	>> a == "approved"
 	=> true
 	>> a == :approved
 	=> true
-	
-	
+
+
 Note that every enum you create is a subclass of HoboFields::EnumString:
 
 	>> a.is_a?(HoboFields::EnumString)
 	=> true
-	
-	
+
+
 ### Using EnumString in your models
-	
+
 `HoboFields::EnumString` extends the field declaration DSL with a shorthand for creating enum types:
 
 	>>
@@ -193,7 +193,7 @@ Sometimes it's nice to have a proper type name. Here's one way you might go abou
 	end
 	>> Article.attr_type :status
 	=> Article::Status
-	
+
 
 
 

data/test/test_generator_helper.rb

@@ -0,0 +1,29 @@
+begin
+  require File.dirname(__FILE__) + '/test_helper'
+rescue LoadError
+  require 'test/unit'
+end
+require 'fileutils'
+
+# Must set before requiring generator libs.
+TMP_ROOT = File.dirname(__FILE__) + "/tmp" unless defined?(TMP_ROOT)
+PROJECT_NAME = "myproject" unless defined?(PROJECT_NAME)
+app_root = File.join(TMP_ROOT, PROJECT_NAME)
+if defined?(APP_ROOT)
+  APP_ROOT.replace(app_root)
+else
+  APP_ROOT = app_root
+end
+if defined?(RAILS_ROOT)
+  RAILS_ROOT.replace(app_root)
+else
+  RAILS_ROOT = app_root
+end
+
+begin
+  require 'rubigen'
+rescue LoadError
+  require 'rubygems'
+  require 'rubigen'
+end
+require 'rubigen/helpers/generator_test_helper'