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?
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?
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
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.
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.
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.
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).
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.
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
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.
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?
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.
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.
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.
