Dynamic scaffold_resource

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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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 <drernieopendarwin.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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 <timinfosauce.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 <drernieopendarwin.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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 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


--~--~---------~--~----~------------~-------~--~----~
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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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 <aldursysgmail.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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-res
ource-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_resourc
e/

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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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/1
8578
http://pastie.caboo.se/1
8579

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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.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-coregooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribegooglegroups.com
For more options, visit this group at http:
//groups.google.com/group/rubyonrails-core
-~----------~----~----~----~------~----~------~--~---