Dynamic scaffolding as a concept was popularized by Rails, but hasn''t been recommended since shortly after it was included with Rails. On the surface, dynamic scaffolding seems like a good fit with Rails philosophy. It''s simple to use and is very DRY (much more so than generated scaffolding). However, dynamic scaffolding is currently deprecated and will be removed in Rails 2.0 (though you''ll be able to get it with a plugin). What is wrong with dynamic scaffolding? Well, here are some criticisms of it: 1) It doesn''t do X (e.g. associations, search) This is a problem not with the concept of dynamic scaffolding, but with Rails very basic implementation of it. Dynamic scaffolding in theory can automatically generate any code that you would type in manually, if the dynamic scaffolding code itself is modified to support it. In many cases, it is more work to modify the scaffolding code than it is to manually code what you want. This is true in most cases where the modifications you would want to make would only affect a single model or action. However, if you want to add a similar action for many different models, modifying the dynamic scaffolding code may be easier, and the possibility for reuse is a lot higher. I''ve found that pretty much everything I''ve wanted to use scaffolding for, I''ve been able to modify the scaffolding code to dynamically produce the output I want. Just because scaffolding currently doesn''t do something you want doesn''t mean that it can''t. 2) It''s too magical Yes, it is magical, possibly more so than most of Rails. However, it automatically generates much more code than most of the magic features in Rails, so of course it will appear more magical. Of course, Rails is open source and anyone can look behind then magic if they so choose (that''s how I got started hacking Rails internals). Looking at how the magic features in scaffolding work is a good way to learn how Rails uses Ruby''s metaprogramming techniques. 3) It makes things appear too easy True, but if used correctly, things actually are much easier. If you want a simple admin interface to a 50 model database, you are probably much better off using some advanced scaffolding than creating individual forms for all models. Not only is it simpler to create the forms using scaffolding, it is probably easier to maintain them. 4) It causes "scaffold withdrawal" "Scaffold withdrawal" being the "cold, clammy realization that scaffolding can''t cut it forever and we don''t know what to do next" [0]. Certainly, even in the best case, scaffolding is not going to solve all of your problems (though I have a production intranet application where I work that is 80-90% scaffolded code). But even in the best case scenario, scaffolding won''t solve all of your problems, and developers using scaffolding should realize that (I think most do). 5) It shouldn''t be in core I agree with this. Plugins were added to Rails after scaffolding, which is probably why scaffolding wasn''t a plugin in the first place. Moving it to a plugin, similar to what was done with pagination, was the right move. If you find the tedious process of creating form after similar form unrewarding, try one of the advanced scaffolding packages and see if they can work for you: - Scaffolding Extensions [1] - Streamlined [2] - ActiveScaffold [3] - Auto-Admin [4] I haven''t tried any but the first (which I wrote), but hopefully the developers of the other scaffolding plugins can chime in with their thoughts. Also, if you are a user of any of the above plugins, please reply and state your reasons for using the plugin and your experiences with it. Jeremy [0] http://www.slash7.com/articles/2005/12/07/the-fall-from-scaffolding [1] http://wiki.rubyonrails.org/rails/pages/Scaffolding+Extensions+Plugin [2] http://www.streamlinedframework.org/ [3] http://www.activescaffold.com/ [4] http://code.trebex.net/auto-admin -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
MichaelLatta
2007-Jun-13 00:21 UTC
Re: In Defense of Dynamic Scaffolding ("scaffold :model")
I have been using Active Scaffold for some time now (2-3 months). I am very happy with the default UI and behavior in most ways. As we discussed in the BOF at RailsConf 2007 there will always be a 5-10% gap between any user''s needs and a generic framework like AS or Rails for that matter. I have found Active Scaffold very amenable to adaptation. It provides many hooks for easy customization, and is open source for those less common cases. Using ruby to apply patches to an open source framework makes that last 1% so much easier than any other environment! There are even starting to be plug-ins to AS indicating there is enough function there to be worth extending in a general way. I chose Active Scaffold in part because it was the first one I came across, but also because it keeps coming out better in evaluations I do. I did not like the Streamlined UI behavior at all. The UI did not feel good to me. I did not use Hobo because I do not want to learn yet another tag language. I have not looked at the other 2 you mention, but I am getting vested enough in AS that I will probably not change it out for the current project, and even later projects will most likely use it as I have developed a good working relationship with the code and would not want to invest that time again without a big pay off. Michael Jeremy Evans wrote:> Dynamic scaffolding as a concept was popularized by Rails, but hasn''t > been recommended since shortly after it was included with Rails. On the > surface, dynamic scaffolding seems like a good fit with Rails > philosophy. It''s simple to use and is very DRY (much more so than > generated scaffolding). However, dynamic scaffolding is currently > deprecated and will be removed in Rails 2.0 (though you''ll be able to > get it with a plugin). > > What is wrong with dynamic scaffolding? Well, here are some criticisms > of it: > > 1) It doesn''t do X (e.g. associations, search) > > This is a problem not with the concept of dynamic scaffolding, but with > Rails very basic implementation of it. Dynamic scaffolding in theory > can automatically generate any code that you would type in manually, if > the dynamic scaffolding code itself is modified to support it. In many > cases, it is more work to modify the scaffolding code than it is to > manually code what you want. This is true in most cases where the > modifications you would want to make would only affect a single model or > action. However, if you want to add a similar action for many different > models, modifying the dynamic scaffolding code may be easier, and the > possibility for reuse is a lot higher. > > I''ve found that pretty much everything I''ve wanted to use scaffolding > for, I''ve been able to modify the scaffolding code to dynamically > produce the output I want. Just because scaffolding currently doesn''t > do something you want doesn''t mean that it can''t. > > 2) It''s too magical > > Yes, it is magical, possibly more so than most of Rails. However, it > automatically generates much more code than most of the magic features > in Rails, so of course it will appear more magical. Of course, Rails is > open source and anyone can look behind then magic if they so choose > (that''s how I got started hacking Rails internals). Looking at how the > magic features in scaffolding work is a good way to learn how Rails uses > Ruby''s metaprogramming techniques. > > 3) It makes things appear too easy > > True, but if used correctly, things actually are much easier. If you > want a simple admin interface to a 50 model database, you are probably > much better off using some advanced scaffolding than creating individual > forms for all models. Not only is it simpler to create the forms using > scaffolding, it is probably easier to maintain them. > > 4) It causes "scaffold withdrawal" > > "Scaffold withdrawal" being the "cold, clammy realization that > scaffolding can''t cut it forever and we don''t know what to do next" [0]. > Certainly, even in the best case, scaffolding is not going to solve all > of your problems (though I have a production intranet application where > I work that is 80-90% scaffolded code). But even in the best case > scenario, scaffolding won''t solve all of your problems, and developers > using scaffolding should realize that (I think most do). > > 5) It shouldn''t be in core > > I agree with this. Plugins were added to Rails after scaffolding, which > is probably why scaffolding wasn''t a plugin in the first place. Moving > it to a plugin, similar to what was done with pagination, was the right > move. > > If you find the tedious process of creating form after similar form > unrewarding, try one of the advanced scaffolding packages and see if > they can work for you: > > - Scaffolding Extensions [1] > - Streamlined [2] > - ActiveScaffold [3] > - Auto-Admin [4] > > I haven''t tried any but the first (which I wrote), but hopefully the > developers of the other scaffolding plugins can chime in with their > thoughts. Also, if you are a user of any of the above plugins, please > reply and state your reasons for using the plugin and your experiences > with it. > > Jeremy > > [0] http://www.slash7.com/articles/2005/12/07/the-fall-from-scaffolding > [1] > http://wiki.rubyonrails.org/rails/pages/Scaffolding+Extensions+Plugin > [2] http://www.streamlinedframework.org/ > [3] http://www.activescaffold.com/ > [4] http://code.trebex.net/auto-admin > > -- > Posted via http://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---