Rails - Jul 2005 - The rails_product generator (Productize your app)

This announcement follows the "Productize your application" thread in
the [REUSE] section last week. [1]

== Two new generators:

Productizing your application is now as easy as running the  
"rails_product <app_name>" command to create a new application  
(instead of the usual "rails" command).  In addition, there is a site
generator gem which in a single command will allow you to create a  
new site within your Productized Rails Application: "./script/ 
generate site <site_name>".

(Does my enthusiasm sound like DHH''s?  If you think you see hype,  
translate it as excitement on my part :)

== Gems available at:

http://inquirylabs.com/productize/rails_product-0.5.gem
http://inquirylabs.com/productize/site_generator-0.5.gem
(Soon to be available at RubyForge.org.)

== Installation and Usage Instructions on the wiki

http://wiki.rubyonrails.com/rails/show/RailsProductGenerator

== New Features and Updates

Terminology: I''ve settled on the following terminology to distinguish  
between what I was calling the "generic" application and the
"site-
specific" applications.  Instead, I will refer to these as the "base  
application" and the "second-tier applications", respectively.  I
use
"base application" in the same way that we talk about a "base
class".

There are several new features that are not available by the  
"Productize your application" instructions last week:

- Routes are now supported in second-tier applications.  This means  
you can either add to or replace routes in the base application with  
routes in your second-tier (site-specific) applications.
- Files are now shared resources.  You can put your images and  
javascripts (etc.) in the base public/ folder and your second-tier  
applications will now load them by default if there are no second- 
tier files to load instead. (Apache & WEBrick only at this point).
- An example Apache configuration file is included (config/apache/ 
vhost.example.conf).
- Pages are now cached in the second-tier public/ folders so that  
they don''t overwrite each other.
- Controllers that exist in the second tier but not the base are now  
loaded properly. (Previously failed to load controllers if they did  
not exist in the base application)
- Models can now exist in the second tier even if they are not in the  
base (EXPERIMENTAL).
- Migrations with major / minor numbers are now supported.  This  
means you can have migrations for the entire set of second-tier  
applications, and still add custom per-site (second-tier) migrations.  
(EXPERIMENTAL).  See http://dev.rubyonrails.com/ticket/1818

Duane Johnson
(canadaduane)

[1] http://article.gmane.org/gmane.comp.lang.ruby.rails/14513

Duane Johnson wrote:
> This announcement follows the "Productize your application"
thread in
> the [REUSE] section last week. [1]
> 
> == Two new generators:
> 
> Productizing your application is now as easy as running the  
> "rails_product <app_name>" command to create a new
application  (instead
> of the usual "rails" command).  In addition, there is a site 
generator
> gem which in a single command will allow you to create a  new site 
> within your Productized Rails Application: "./script/ generate site 
> <site_name>".
> 
> (Does my enthusiasm sound like DHH''s?  If you think you see hype,
> translate it as excitement on my part :)
> 
> == Gems available at:
> 
> http://inquirylabs.com/productize/rails_product-0.5.gem
> http://inquirylabs.com/productize/site_generator-0.5.gem
> (Soon to be available at RubyForge.org.)
> 
> == Installation and Usage Instructions on the wiki
> 
> http://wiki.rubyonrails.com/rails/show/RailsProductGenerator
> 
> == New Features and Updates
> 
> Terminology: I''ve settled on the following terminology to
distinguish
> between what I was calling the "generic" application and the
"site-
> specific" applications.  Instead, I will refer to these as the
"base
> application" and the "second-tier applications",
respectively.  I use
> "base application" in the same way that we talk about a
"base class".
> 
> There are several new features that are not available by the  
> "Productize your application" instructions last week:
> 
> - Routes are now supported in second-tier applications.  This means  you 
> can either add to or replace routes in the base application with  routes 
> in your second-tier (site-specific) applications.
> - Files are now shared resources.  You can put your images and  
> javascripts (etc.) in the base public/ folder and your second-tier  
> applications will now load them by default if there are no second- tier 
> files to load instead. (Apache & WEBrick only at this point).
> - An example Apache configuration file is included (config/apache/ 
> vhost.example.conf).
> - Pages are now cached in the second-tier public/ folders so that  they 
> don''t overwrite each other.
> - Controllers that exist in the second tier but not the base are now  
> loaded properly. (Previously failed to load controllers if they did  not 
> exist in the base application)
> - Models can now exist in the second tier even if they are not in the  
> base (EXPERIMENTAL).
> - Migrations with major / minor numbers are now supported.  This  means 
> you can have migrations for the entire set of second-tier  applications, 
> and still add custom per-site (second-tier) migrations.  
> (EXPERIMENTAL).  See http://dev.rubyonrails.com/ticket/1818
> 
> Duane Johnson
> (canadaduane)
> 
> [1] http://article.gmane.org/gmane.comp.lang.ruby.rails/14513
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> (Does my enthusiasm sound like DHH''s?  If you think you see hype, 
> translate it as excitement on my part :)
And so you should be excited. It''s awesome work here you''ve
done Duane!

- tim

Oh man, you da man!

+10

This has seriously somehow go into Rails, or at least be supported. As a 
matter of fact, when Rails-0.5 came out back in the day (and we were 
like 6 ppl in the #channel) this was the main thing I was complaining 
about. But since DHH didn''t have any "use" for such a setup
it was a
lost cause argueing.

The whole Rails structure (directories and everything) is really only 
meant for a single app/site per code base. This goes a long way for 
people that want to keep it DRY "between" their applications.

You got every reason to be proud ;)

In my book, this is a killer feature. I am thrilled. Thx.

Sasa

PS: Now only some good l10n is missing for me.

Very cool indeed! This could be a great solution for deploying managed
apps to many users, eg. a managed Typo that uses a central code base
whilst still allowing specific users to make modifications. I like!

-- 

Ben Myles
RailsAppHosting
(www.railsapphosting.com)

Very cool...

Is it possible to productize an existing app with a "rails_product ."?
 I would assume so, since it seems like just a wrapper for the rails
command with some extra stuff.  What files do we need to let it
overwrite in that case?

On Jul 25, 2005, at 7:30 PM, Pat Maddox wrote:
> Very cool...
>
> Is it possible to productize an existing app with a "rails_product
."?
>  I would assume so, since it seems like just a wrapper for the rails
> command with some extra stuff.  What files do we need to let it
> overwrite in that case?
Yes, that should work as you expect it to.  The "Implementation  
Details" section of http://wiki.rubyonrails.com/rails/show/ 
RailsProductGenerator has some useful information.  For others who  
might be trying this, here''s a list of new files you''ll get,
followed
by a list of pre-existing but essential files that must be  
overwritten (careful!):

== New files & directories:

* sites/
* sites/Rakefile
* config/apache/
* config/apache/vhost.example.com
* lib/productize.rb

== Modified files (you''ll need to overwrite these):

* Rakefile (optional - removes the ''migrate'' task since the
base app
has no db)
* README (optional - installation instructions etc.)
* CHANGELOG (optional)
* database.yml (IMPORTANT - back yours up first, or be prepared to  
fill details back in)
* public/.htaccess (IMPORTANT for Apache to share base app resources  
with second tier apps)
* config/environment.rb (IMPORTANT - three lines of code added)
* script/server (IMPORTANT for WEBrick to share base app resources  
with second tier apps)

== There are no other files that need to be overwritten
e.g. app/controllers/application.rb, log/production.log, script/*,  
public/dispatch.* etc.

Good luck! :)

Duane Johnson
(canadaduane)




_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Just a note about the Wiki page:

$ gem install site_generator-0.5.gem

did not work for me, however

$ gem install site_generator

worked as expected.

I changed the Wiki page to this effect.

Thanks for a great generator, Duane!

Matt

On Jul 25, 2005, at 10:00 PM, Duane Johnson wrote:
>
> On Jul 25, 2005, at 7:30 PM, Pat Maddox wrote:
>
>> Very cool...
>>
>> Is it possible to productize an existing app with a  
>> "rails_product ."?
>>  I would assume so, since it seems like just a wrapper for the rails
>> command with some extra stuff.  What files do we need to let it
>> overwrite in that case?
>
> Yes, that should work as you expect it to.  The "Implementation  
> Details" section of http://wiki.rubyonrails.com/rails/show/ 
> RailsProductGenerator has some useful information.  For others who  
> might be trying this, here''s a list of new files you''ll
get,
> followed by a list of pre-existing but essential files that must be  
> overwritten (careful!):
>
> == New files & directories:
>
> * sites/
> * sites/Rakefile
> * config/apache/
> * config/apache/vhost.example.com
> * lib/productize.rb
>
> == Modified files (you''ll need to overwrite these):
>
> * Rakefile (optional - removes the ''migrate'' task since
the base
> app has no db)
> * README (optional - installation instructions etc.)
> * CHANGELOG (optional)
> * database.yml (IMPORTANT - back yours up first, or be prepared to  
> fill details back in)
> * public/.htaccess (IMPORTANT for Apache to share base app  
> resources with second tier apps)
> * config/environment.rb (IMPORTANT - three lines of code added)
> * script/server (IMPORTANT for WEBrick to share base app resources  
> with second tier apps)
>
> == There are no other files that need to be overwritten
> e.g. app/controllers/application.rb, log/production.log, script/*,  
> public/dispatch.* etc.
>
> Good luck! :)
>
> Duane Johnson
> (canadaduane)
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Matt Pelletier
pelletierm-A1PILTyJ15gXhy9q4Lf3Ug@public.gmane.org




_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

What''s the best way to run unit tests on this?  Right now I''m
just
setting the $SITE environment variable and then running the tests from
the 1st tier, but a couple sites already have new models...which I can
easily test by hand, but I''d like to just be able to run rake and run
all the unit tests for all my sites.  Do you already have that built
in, and I''m just being stupid, or is that not implemented yet?

Regardless, this is really cool so far, thanks for the work.

Pat