Instant Management Frontend with the Scaffolding Extensions

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 B.
http://www.recentrambles.com

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

On 3/1/06, Charlie B. [email protected] wrote:

[email protected]
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

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” :wink:

-Derrick S.

Jeremy
> Please contact me if you have any questions

Where is the screencast?
:slight_smile:

Alain

On 3/1/06, Alain R. [email protected] 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 S. [email protected] 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