So I''ve RESTified a couple controllers, now, using the latest stuff in Edge and they don''t feel very-DRY. I realize that after they get more complicated they will need to be able to be stand-alone, but they are currently pretty wet. I considered working on an abstract REST controller, but then realized that dynamic scaffolding was almost all I needed. I just want to be able to not have to repeat myself until the controller diverges from the norm. Now perhaps an abstract controller might be able to be figured out in such a way to allow for better TDD, but I think basically a copy of the current generated tests for scaffold_resource could just be dropped in test for those who want to do TDD, and the scaffolding could use updating if everything is supposed to move towards REST/CRUD. I submitted a couple tiny patches to active_record_helper.rb form() to add options[:url] and options[:method] so that the ARH form could at least be called in the current REST style (since the scaffolding uses that form(), which was hard-coded to an old-style url :action =>), but wanted to ask here before proceeding further. Am I completely off base here? If I want a dynamic scaffold_resource :model should I proceed and submit the patch? Should I just update the current scaffolding to use the new REST style, or make it scaffold_resource? What are the odds of this sort of thing getting applied? More likely given the push to REST, and since this would add another minor nudge? Should I make any other tiny patches needed to core, and then just make the rest a plug-in? Tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Hi Tim, On Oct 16, 2006, at 9:16 AM, Tim Connor wrote:> Am I completely off base here? If I want a dynamic scaffold_resource > :model should I proceed and submit the patch? Should I just update > the > current scaffolding to use the new REST style, or make it > scaffold_resource? What are the odds of this sort of thing getting > applied? More likely given the push to REST, and since this would add > another minor nudge? Should I make any other tiny patches needed to > core, and then just make the rest a plug-in?I for one would dearly love to see the default scaffold implementation (both dynamic and generated) move towards REST. Of course, I think it would be important to still have a way to access the old-style scaffold, perhaps with a parameter to script/generate and :scaffold. Would that be technically feasible for you to implement? DHH, what''s the policy on changing default behavior in Rails 1.2? Absolutely forbidden, or only if there''s a really big win? -- Ernie P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
I was so excited to get going that I started on a plug-in, but if it''s likely it will actually make it in, then I''ll just code against trunk (just barely started). Or should I do it as a plug-in to make it usable until it makes it in? I''d definitely love to give this a shot, though. It might be easier to me to make a separate scaffold_resource call to match the generator, and so I can avoid having to deal with the suffix for multiple models issue (since a REST controller won''t have that). I''m pretty good at figuring stuff out, so it might not be completely beyond my abilities to implement this, but those two patches were my first, so my ruby-fu might be lacking some. If I can get pointers here or there on the trickier parts (for instance I am currently having to use @scaffold_edit_model_path.call in the view templates, and really can''t quite figure out any way to get the named route to work dynamically in the controller code, such as in the :verify line) it''d help. Of course, I don''t develop with-out version control, so maybe I''ll have to set it up as a plug-in first, anyways, so I can commit as I go? Oh, one of my immediate questions, where are the tests for the scaffolding code? If I do a plug-in I''ll obviously be doing my own, but it''d be Tim On 10/16/06, Dr. Ernie Prabhakar <drernie@opendarwin.org> wrote:> > Hi Tim, > > On Oct 16, 2006, at 9:16 AM, Tim Connor wrote: > > Am I completely off base here? If I want a dynamic scaffold_resource > > :model should I proceed and submit the patch? Should I just update > > the > > current scaffolding to use the new REST style, or make it > > scaffold_resource? What are the odds of this sort of thing getting > > applied? More likely given the push to REST, and since this would add > > another minor nudge? Should I make any other tiny patches needed to > > core, and then just make the rest a plug-in? > > I for one would dearly love to see the default scaffold > implementation (both dynamic and generated) move towards REST. Of > course, I think it would be important to still have a way to access > the old-style scaffold, perhaps with a parameter to script/generate > and :scaffold. Would that be technically feasible for you to implement? > > DHH, what''s the policy on changing default behavior in Rails 1.2? > Absolutely forbidden, or only if there''s a really big win? > > -- Ernie P. > > > > >-- ..do you know why George Bush is so pissed off at Arabs? They brought us algebra. --Kurt Vonnegut --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Actually, I answered most of my questions myself. I''ll just try and whip out a plugin for this, at least far enough to have something showable, and then ask for comments. Tim On 10/16/06, Tim Connor <tim@infosauce.com> wrote:> I was so excited to get going that I started on a plug-in, but if it''s > likely it will actually make it in, then I''ll just code against trunk > (just barely started). Or should I do it as a plug-in to make it > usable until it makes it in? I''d definitely love to give this a shot, > though. It might be easier to me to make a separate scaffold_resource > call to match the generator, and so I can avoid having to deal with > the suffix for multiple models issue (since a REST controller won''t > have that). > > I''m pretty good at figuring stuff out, so it might not be completely > beyond my abilities to implement this, but those two patches were my > first, so my ruby-fu might be lacking some. If I can get pointers > here or there on the trickier parts (for instance I am currently > having to use @scaffold_edit_model_path.call in the view templates, > and really can''t quite figure out any way to get the named route to > work dynamically in the controller code, such as in the :verify line) > it''d help. > > Of course, I don''t develop with-out version control, so maybe I''ll > have to set it up as a plug-in first, anyways, so I can commit as I > go? > > Oh, one of my immediate questions, where are the tests for the > scaffolding code? If I do a plug-in I''ll obviously be doing my own, > but it''d be > > Tim > > On 10/16/06, Dr. Ernie Prabhakar <drernie@opendarwin.org> wrote: > > > > Hi Tim, > > > > On Oct 16, 2006, at 9:16 AM, Tim Connor wrote: > > > Am I completely off base here? If I want a dynamic scaffold_resource > > > :model should I proceed and submit the patch? Should I just update > > > the > > > current scaffolding to use the new REST style, or make it > > > scaffold_resource? What are the odds of this sort of thing getting > > > applied? More likely given the push to REST, and since this would add > > > another minor nudge? Should I make any other tiny patches needed to > > > core, and then just make the rest a plug-in? > > > > I for one would dearly love to see the default scaffold > > implementation (both dynamic and generated) move towards REST. Of > > course, I think it would be important to still have a way to access > > the old-style scaffold, perhaps with a parameter to script/generate > > and :scaffold. Would that be technically feasible for you to implement? > > > > DHH, what''s the policy on changing default behavior in Rails 1.2? > > Absolutely forbidden, or only if there''s a really big win? > > > > -- Ernie P. > > > > > > > > > > > > > -- > ..do you know why George Bush is so pissed off at Arabs? > They brought us algebra. --Kurt Vonnegut >-- ..do you know why George Bush is so pissed off at Arabs? They brought us algebra. --Kurt Vonnegut --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Tim Connor wrote:> Oh, one of my immediate questions, where are the tests for the > scaffolding code? If I do a plug-in I''ll obviously be doing my own, > but it''d beThe generator test code is unloved, and the ''railties'' test suite fails on trunk at the moment. I think it would be a useful exercise to get the generator test suite up to scratch, but I''m loathed to dive in without some sort of strategic steer from the core committers about where the generators are going. There are a lot of ''railties'' patches outstanding on Trac at the moment. Core team - what do you want done? NeilW --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Dynamic scaffolding lives outside of railties - it''s in the actionpack/actioncontroller itself. Wether having the generated scaffold and the dynamic scaffold so separate is DRY is something I have no clue about, since I haven''t look at the generator code, and it could be one of those cases were trying to abstract them gets messy enough that it''s worse than having them wet. I''m done with the big chunk of coding. In the next couple days, I''ll put it up for review and then ask again how to proceed from there. I had been working on doing TDD, but since this was new enough, and I was copying and modifying a bunch of existing code that I needed to lear, I didn''t right my tests yet, so I''ll be doing the docs and testing after the initial development. I am also planning on trying to add a scaffold_resource_tests to run the basic REST tests that the generator gives us, if it doesn''t prove to tricky. Ideally I''d like to let that function like the scaffold code - if you manually create a test it doesn''t run the default one. Tim On 10/17/06, Neil Wilson <aldursys@gmail.com> wrote:> > > Tim Connor wrote: > > Oh, one of my immediate questions, where are the tests for the > > scaffolding code? If I do a plug-in I''ll obviously be doing my own, > > but it''d be > > The generator test code is unloved, and the ''railties'' test suite fails > on trunk at the moment. > > I think it would be a useful exercise to get the generator test suite > up to scratch, but I''m loathed to dive in without some sort of > strategic steer from the core committers about where the generators are > going. > > There are a lot of ''railties'' patches outstanding on Trac at the > moment. > > Core team - what do you want done? > > NeilW > > > > >-- ..do you know why George Bush is so pissed off at Arabs? They brought us algebra. --Kurt Vonnegut --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
So Alpha is out. Details at: http://www.timocracy.com/articles/2006/10/17/8-dynamic-scaffold-resource-rails-plugin-is-officially-alpha or for those who like to cut to the chase: http://trac.infosauce.org/wiki/DynamicScaffoldResource (read here for notes on installing, first) and http://svn.infosauce.org/rails/dynamic_scaffold_resource/ Now, I''ll dive into 0.2 - testing and documenting. I am only working on my first Rails project (I guess that makes the plugin my second ruby project) as a developer (having previously managed a number of them), so I am sure my ruby is not quite up to snuff, yet. Thus, please, please take a look and feel free to critque and recommend. If anyone wants to help I''ll hand out a subversion login, keeping in mind you implicitely hand over copyright so that I can copyleft it (or whatever need be done so I can release it to RoR unencumbered, if it ever makes it that far). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
OK, I definitely need some help, now, getting the tests running. I''ve been plundering the ActionPack tests heavily, but can''t quite get it right. http://pastie.caboo.se/18578 http://pastie.caboo.se/18579 I''m getting the "No url can be generated for this hash" error that indicates I haven''t quite gotten the routing working in the test, and I''ve tried every different way I can think of, so far. BTW, I committed, in case anyone wants to do an ''svn co'' and give me a pointer. Thanks, Tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Again I finally managed to answer my own question - by taking a look at how the simply_resful plguin did it (since they obviously had to handle this). Basically, I''m just depending on the path all the path all the way up to the /config/environment.rb file and processing that. That seems to work, so I guess I''ll stick with that RAILS_ENV = "test" require File.expand_path(File.join(File.dirname(__FILE__), ''../../../../config/environment.rb'')) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
> DHH, what''s the policy on changing default behavior in Rails 1.2? > Absolutely forbidden, or only if there''s a really big win?The ship has sailed on making these kind of changes for Rails 1.2. We''re in final crunch mode for release. Plugins are a good way to play with this first in any case. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
If I do good can I eventually get a biscuit - aka get it into core (where someone with mad chops might clean it up), somewhere post 1.2? ;) My only problem with the plugin is it definitely requires the tiny patches from tickets 6412 and 6413, and I''d rather not have to overwrite the whole ActiveRecordHelper.form() function in my plugin. While I understand these sort of things being a low priority right now, anyone have better idea how I should do that? Make a patchfile for the two of them and include it with the plug-in? That sort of feels user-unfriendly and might limit it to the hard-core. Maybe have an option to overwrite by default, but include the patch as an alternative? On a separate note - testing that matches (except I changed test_should_show_resourcename to test_should_get_show, to be consistent with the other test_should_get_action tests) the tests created by the generator script is almost done. After that I''ll ask for review/criticism while I work on the docs. What then? Make a ticket patch and point it at my plug-in? Tim On 10/19/06, DHH <david.heinemeier@gmail.com> wrote:> > > DHH, what''s the policy on changing default behavior in Rails 1.2? > > Absolutely forbidden, or only if there''s a really big win? > > The ship has sailed on making these kind of changes for Rails 1.2. > We''re in final crunch mode for release. Plugins are a good way to play > with this first in any case. > > > > >-- ..do you know why George Bush is so pissed off at Arabs? They brought us algebra. --Kurt Vonnegut --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Okay stable (http://svn.infosauce.org/rails/dynamic_scaffold_resource/branches/stable) is now at 0.2 (tests done) and ready to be ripped to shreds. ;) Aside from whatever ya''ll might suggest it''s just documenting it and figuring out what to do about making the patch a breeze, now. Anyone, who expressed an interest in this, please take a look and comment at will. Yes, the ''include DynamicScaffoldResourceTestHelper'' (runs all the tests for a given resource) is a bit hokey as any model validation will kill it, but it was a first stab at the concept, and it was almost as easy to just write those tests abstracted a little, since I needed them anyway for the plugin itself. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Dynamic Scaffold Resource is ready to go, pending your feedback: http://www.timocracy.com/articles/2006/10/25/35-dynamic-scaffold-resource-rails-plugin-at-final-prerelease Those few that expressed an interest please chime up with any comments you have. And if any core members would care to tell me how to improve it to make it more likley to be included, that would be delightful. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---
Project moved to Google Code http://code.google.com/p/dynamic-scaffold-resource/ Subversion history preserved, but clean checkouts required, as the repo UID is changed, and the dynamic-scaffold-resource stuff is now in the root of the repo. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core -~----------~----~----~----~------~----~------~--~---