Rails - Mar 2006 - Instant Management Frontend with the Scaffolding Extensions Plugin

I''ve updated the Scaffolding Extensions Plugin[1] recently to add a
couple new features:

1) Scaffold all models and associations with one command
2) Show all associated objects on the edit page

Example of usage:

In an existing Rails application, create a controller (i.e.
"script/generate controller crud"), and modify so it looks like:

  class CrudController < ApplicationController
    scaffold_all_models
  end

Then go to the index page for the controller (e.g.
http://website/crud). You''ll see a link to a management page for each
of your models. Each management page has links to create, delete,
edit, show, search, and merge pages for the model.  The edit pages
will show all associated objects with working links to edit those
objects (since every model and association is scaffolded).  Add a
before_filter to the controller to handle authentication and some
configuration code to each model (if necessary) and voila, Instant
Management Frontend.

I''d like to thank Scott Weaver for giving me the idea to add the
associated objects to the edit page and coming up with a working
prototype that I could test.

Please contact me if you have any questions or comments about the plugin.

Enjoy,
Jeremy

[1] http://wiki.rubyonrails.com/rails/pages/Scaffolding+Extensions+Plugin

I''m just curious why we have 3 different options of doing very similar
things.  I have a small app that I want to make into one of these, but
I"m not sure why I should choose one or the other.  For those of you
that have written one, why did you choose one over another?  Which one
is easier? 


Charlie Bowman
http://www.recentrambles.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060301/e069f9dd/attachment.html

This might help:
http://rails-engines.org/wiki/pages/Components+vs.+Plugins+vs.+Engines

On 3/1/06, Charlie Bowman <charlie@castlebranch.com>
wrote:
>
>            I''m just curious why we have 3 different options of
doing very similar things.  I have a small app that I want to make into one of
these, but I"m not sure why I should choose one or the other.  For those of
you that have written one, why did you choose one over another?  Which one is
easier?
>
>
>
>
>   Charlie Bowman
>  http://www.recentrambles.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>


--
* J *
  ~

Charlie

You''ve just hijacked a thread. People who are not interested in the 
"Scaffolding .." thread you are "parasiting" will miss  your
message.
Please post a new message next time.

Alain

Jeremy
    > Please contact me if you have any questions


Where is the screencast?
:)

Alain

Really it''s just granularity.

* Plugins are for hacking.  Or at least that''s how I think of them.   
Don''t like the way something works in rails?... write a plugin and  
change it!  Most often plugins will patch ActiveRecord to give it  
some extra functionality, or provide a set of rather generic helper  
methods, etc.  I expect that I will use this behavior in other  
applications, and now I can just drop a folder in my plugins  
directory to have that behavior available.

* Generators write code for you.  They actually modify your  
application by inserting code.  This means they are great for  
smaller, quick start sort of things.  They can be complex, but  
ultimately they are meant to be run once and never again for the life  
of that application.  Contrast that with a plugin, which can easily  
be added/removed/updated without changing your code base.

* Engines are really just a special case of plugins.  They are full- 
fledged, standalone rails applications.  These puppies could run on  
their own.  They have an entire rails application hierarchy  
internally.  They are plugins, but plugins that do more than hack.


So yeah, they all do the same thing.  Which is right for your  
situation....well, .... "it depends" ;)

-Derrick Spell


On Mar 1, 2006, at 3:08 PM, Charlie Bowman wrote:
> I''m just curious why we have 3 different options of doing very  
> similar things.  I have a small app that I want to make into one of  
> these, but I"m not sure why I should choose one or the other.  For  
> those of you that have written one, why did you choose one over  
> another?  Which one is easier?
>
>
> Charlie Bowman
> http://www.recentrambles.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060301/28332426/attachment.html

On 3/1/06, Alain Ravet <arav2132@biz.tiscali.be>
wrote:
> Jeremy
>     > Please contact me if you have any questions
>
> Where is the screencast?
I''ll be happy to host one if someone else can create it. 
Unfortunately, I don''t have any experience with creating them. I
don''t
even like watching them (I watched one of the Rails screencasts and
found it boring); I prefer tutorials or just playing around with the
code.

On 3/1/06, Derrick Spell <derrickspell@cdmplus.com>
wrote:
> Really it''s just granularity.
>
> * Engines are really just a special case of plugins.  They are
full-fledged, standalone rails applications.  These puppies could run on their
own.  They have an entire rails application hierarchy internally.  They are
plugins, but plugins that do more than hack.
They don''t need to be fully-fledged applications - really just
occasions where you have a coherent bundle views, controllers and
models which are (or can be) loosley coupled with the rest of your
application, and you want to share that lump of functionality between
rails apps.

That said, they might be (some recent wiki stuff demonstrates that).
But really engines are just plugins taken a bit further than, as
Derrick says, a way of hacking the Rails framework.

- james