Forum: Ruby on Rails Simply Helpful - Is it being used?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ea94dbb5d740e9d4adc6200f9c563452?d=identicon&s=25 Yitzhak Bar Geva (yitzhakbg)
on 2007-03-11 20:04
(Received via mailing list)
There is a reference in "Agile Web Development with Rails", 2nd
edition (footnote on page 483) to the effect that "Simply Helpful",
which is to facilitate integration of models, REST and form_for, will
likely end up in core Rails.
However, I have seen woefully little reaction to it and I was
wondering if it is worth using in my new application.
Any advice would be warmly appreciated.
Thanks
Bce1d1b7c3ec7b577dcb42e254899e6b?d=identicon&s=25 Michael Schuerig (Guest)
on 2007-03-11 20:39
(Received via mailing list)
On Sunday 11 March 2007, yitzhakbg wrote:
> There is a reference in "Agile Web Development with Rails", 2nd
> edition (footnote on page 483) to the effect that "Simply Helpful",
> which is to facilitate integration of models, REST and form_for, will
> likely end up in core Rails.
> However, I have seen woefully little reaction to it and I was
> wondering if it is worth using in my new application.
> Any advice would be warmly appreciated.

Yes, use it. I don't see any drawback. In recent versions there is a new
way to create URLs for objects that is very helpful if you're
generically working with resources, namely polymorphic_url(@object).

Michael

--
Michael Schuerig
mailto:michael@schuerig.de
http://www.schuerig.de/michael/
D8db435093f3593e86f613d04c26e711?d=identicon&s=25 patrick.henry.ewing@gmail.com (Guest)
on 2007-03-11 21:08
(Received via mailing list)
> > However, I have seen woefully little reaction to it and I was
> > wondering if it is worth using in my new application.

I use it on every project now, it really feels like part of Rails.
The url helpers, and methods like dom_id and dom_class DRY up your
views a lot and make AJAX effects simpler to employ, as you get a set
of conventions for referencing DOM elements.

-Patrick Ewing
Ea94dbb5d740e9d4adc6200f9c563452?d=identicon&s=25 Yitzhak Bar Geva (yitzhakbg)
on 2007-03-11 22:32
(Received via mailing list)
Thanks very much
Ea94dbb5d740e9d4adc6200f9c563452?d=identicon&s=25 Yitzhak Bar Geva (yitzhakbg)
on 2007-03-11 22:35
(Received via mailing list)
Is there a tutorial?
855c677aca7319a44da19fb583b9f320?d=identicon&s=25 Nicolas Cavigneaux (Guest)
on 2007-03-12 11:25
(Received via mailing list)
Le 11 mars 07 à 20:38, Michael Schuerig a écrit :

> Yes, use it. I don't see any drawback.

It doesn't handle nested resources :(
--
Nicolas Cavigneaux
http://www.bounga.org
http://www.cavigneaux.net
E3640176765dae2465d33ef6eb114691?d=identicon&s=25 Bala Paranj (Guest)
on 2007-03-12 15:26
(Received via mailing list)
Here is my experience with it: I developed on application with Rails
1.2.2without Simply_Helper plugin. I wrote lot of tests and once my
application
was ready to be released I refactored my code to use Simply Helpful
plugin.
All my tests passed (unit, functional, integration and Selenium) and I
was
confident that what I was doing was working.

Suddenly for some reason when I installed some plugin the tests began to
fail due to Simply Helpful. I removed the simply helpful tags and
everything
now works fine. I still have not found out what went wrong with the
Simply
Helpful when other plugins are installed.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-12 15:55
(Received via mailing list)
Hi --

On 3/11/07, yitzhakbg <yitzhakbg@gmail.com> wrote:
>
> There is a reference in "Agile Web Development with Rails", 2nd
> edition (footnote on page 483) to the effect that "Simply Helpful",
> which is to facilitate integration of models, REST and form_for, will
> likely end up in core Rails.
> However, I have seen woefully little reaction to it and I was
> wondering if it is worth using in my new application.

I think it is indeed used quite widely.  I have a bit of a stumbling
block with the form helper stuff, because I strongly dislike this
idiom:

  def new
     @user = User.new
  end

where you create an AR instance and then discard it, for the sole
purpose of querying it as to whether or not it's a new object.[1]  But
don't listen to me; I'm in the minority on this :-)  And the general
idea of integrating stuff and making it less repetitive I think is
very sound, of course.


David

[1]
http://dablog.rubypal.com/2006/12/23/more-a-than-r...

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
E3640176765dae2465d33ef6eb114691?d=identicon&s=25 Bala Paranj (Guest)
on 2007-03-12 16:21
(Received via mailing list)
I wondered why new had that line of code. I commented out the line that
creates an empty object in the new method. Still all my tests pass and
everything seems fine. So what would the test look like for new method
that
creates the object that is discarded?
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 Jeremy Kemper (Guest)
on 2007-03-12 16:39
(Received via mailing list)
On 3/12/07, David A. Black <dblack@wobblini.net> wrote:
> don't listen to me; I'm in the minority on this :-)  And the general
> idea of integrating stuff and making it less repetitive I think is
> very sound, of course.

I'm not sure why you dislike it. The solution you propose in the blog
entry (User.proto) is essentially what User.new provides: a
prototypical, blank-slate user.

There's nothing overkill about this. A new User is no more or less
than what's needed to show a new user.

I think that whether you use a singleton or a new instance per request
should be a question of implementation rather than idiom.

Best,
jeremy
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-12 16:55
(Received via mailing list)
Hi --

On 3/12/07, Jeremy Kemper <jeremy@bitsweat.net> wrote:
> > where you create an AR instance and then discard it, for the sole
> than what's needed to show a new user.
>
> I think that whether you use a singleton or a new instance per request
> should be a question of implementation rather than idiom.

Maybe.  I don't have a slam-dunk technical argument against it; it
just strikes me as kind of loose, in the sense that, although
AR::B.new does not create a database record, the whole apparatus
exists as a way to persist instances to a database, so deciding up
front to create an instance that has zero chance of being persisted
seems to me contrary to the semantic thrust of the system.

As I said, I'm in the minority :-)  I understand the reasoning behind
it, and I imagine I'll get used to seeing it, but it doesn't sit well
with me.  I'd actually say it's more an idiom thing than an
implementation thing: even if proto (or some other better name) were
an alias of new, it would be more expressive of the status of this
particular instance as a kind of dead-end/stand-in object of
reference.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
B09a3f6cdc4797532647d2d264b5df49?d=identicon&s=25 Jodi Showers (jshow)
on 2007-03-12 17:06
(Received via mailing list)
On 12-Mar-07, at 11:54 AM, David A. Black wrote:

>>>   def new
>> I'm not sure why you dislike it. The solution you propose in the blog
> Maybe.  I don't have a slam-dunk technical argument against it; it
> an alias of new, it would be more expressive of the status of this
> particular instance as a kind of dead-end/stand-in object of
> reference.
>
>
> David


David, I tend to agree - it strikes me my disturbance lies in the
tightly coupling of the 'Model to AR.

If rails models were independent of storage, then Model.new would sit
better with me.

Given the above, it is not implementation - but a symptom of the
current Model implementation as ActiveRecord. I'll bet dollars to
donuts that we'll see a separation down the road.

The Model as means storage rears it's head in my tests as well - I
want to test my Models - not AR; and mocking AR is not a solution
that sits right with me.

cheers,
Jodi
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 Jeremy Kemper (Guest)
on 2007-03-12 17:55
(Received via mailing list)
On 3/12/07, David A. Black <dblack@wobblini.net> wrote:
> Maybe.  I don't have a slam-dunk technical argument against it; it
> just strikes me as kind of loose, in the sense that, although
> AR::B.new does not create a database record, the whole apparatus
> exists as a way to persist instances to a database, so deciding up
> front to create an instance that has zero chance of being persisted
> seems to me contrary to the semantic thrust of the system.

Ah, but it does. The create action has the corresponding
  user.attributes = params[:user]
  user.save

So imagine we're Seaside: the new and create actions just happen to be
punctuated by a request+response:
  GET /users/new   user = User.new
  POST /users      user.update_attributes params[:user]

Regarding User's narrow persistence destiny, I heartily disagree! User
models a real entity in the problem domain-- its characteristics and
behavior-- and Active Record is used to persist it, not the other way
around.


> As I said, I'm in the minority :-)  I understand the reasoning behind
> it, and I imagine I'll get used to seeing it, but it doesn't sit well
> with me.  I'd actually say it's more an idiom thing than an
> implementation thing: even if proto (or some other better name) were
> an alias of new, it would be more expressive of the status of this
> particular instance as a kind of dead-end/stand-in object of
> reference.

I hope I've persuaded you ;-)  Seen in another light, there is no dead
end or special status for this instance.

Best,
jeremy
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-12 18:19
(Received via mailing list)
Hi --

On 3/12/07, Jeremy Kemper <jeremy@bitsweat.net> wrote:
>   user.attributes = params[:user]
>   user.save

But that user isn't the same instance as the @user from the new
action. Somewhere in create you instantiate User again.

> So imagine we're Seaside: the new and create actions just happen to be
> punctuated by a request+response:
>   GET /users/new   user = User.new
>   POST /users      user.update_attributes params[:user]

OK... but we're not :-)  The separation, and the need to instantiate
the class twice, are very palpable to me in the Rails scenario.  If
the semantics were as above, then the situation might be different;
but it's hard to project that into the current semantics.

In fact, that might be exactly what bothers me about it. The idea is
that you have a new instance, and someone fills out some fields for
it, and you save it -- but that idea is very much *not* manifested in
the actual code.

Take, by way of comparison and contrast, the instance variable sharing
between controller and view. That's a case where the sameness of the
objects (@var and @var) is a deception -- but it's you, the
programmer, who are deceived, so that you have a seamless virtual
scope for instance variables even though 'self' has changed.

In the User.new case, I think the problem is that it sort of wants to
be like that, but there's no deception: you actually have to program
the two instances and you can see graphically in your code that they
have no relation to each other.

> Regarding User's narrow persistence destiny, I heartily disagree! User
> models a real entity in the problem domain-- its characteristics and
> behavior-- and Active Record is used to persist it, not the other way
> around.

It's sort of both, though, in the sense that the object is not a
completely database-innocent (so to speak) object which happens to be
sent along to an AR subsystem to be persisted. It's already bitten the
database apple; it encapsulates knowledge of the database, and knows
how to persist itself.

I do know what you mean, though, and I've tried to view it that way.
It doesn't totally work for me; it still feels like pressing an AR
object into service outside of its sweet spot.

> > As I said, I'm in the minority :-)  I understand the reasoning behind
> > it, and I imagine I'll get used to seeing it, but it doesn't sit well
> > with me.  I'd actually say it's more an idiom thing than an
> > implementation thing: even if proto (or some other better name) were
> > an alias of new, it would be more expressive of the status of this
> > particular instance as a kind of dead-end/stand-in object of
> > reference.
>
> I hope I've persuaded you ;-)  Seen in another light, there is no dead
> end or special status for this instance.

I'm afraid I'm still a disbeliever :-)  But that's OK -- not everyone
has to like every idiom, and it's very interesting to talk and think
about this particular one, I find.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 Jeremy Kemper (Guest)
on 2007-03-12 18:26
(Received via mailing list)
On 3/12/07, Jodi Showers <jodi@nnovation.ca> wrote:
> David, I tend to agree - it strikes me my disturbance lies in the
> tightly coupling of the 'Model to AR.
>
> If rails models were independent of storage, then Model.new would sit
> better with me.

I think Active Record succeeds because of this dependence.

Why beat around the bush when you're almost always working with a
SQL-speaking relational database?

By assuming that object instance <-> table row, that attributes of
instances <-> fields of that row, and that associations among
instances <-> foreign-key relations among tables, we're able to shrug
off the heavy burden of arbitrariness in favor a simple, elegant
correspondence whose power is derived from its *avoidance* of a
generic, indirect mapping. Delightful!

By no means does this rule out loading your AR classes with behavior
modeling your domain. On the contrary, I've admired many an app whose
domain is richly expressed by its AR classes.


> Given the above, it is not implementation - but a symptom of the
> current Model implementation as ActiveRecord. I'll bet dollars to
> donuts that we'll see a separation down the road.

I encourage you to reexamine your odds-making ;-)


> The Model as means storage rears it's head in my tests as well - I
> want to test my Models - not AR; and mocking AR is not a solution
> that sits right with me.

Whether you subclass AR::Base or include SomePersistenceStrategy,
you're going to have to stub it out for tests one way or another. I've
been very happy with Mocha for quick, natural mocks and stubs.

Best,
jeremy
24d2f8804e6bb4b7ea6bd11e0a586470?d=identicon&s=25 Jeremy Kemper (Guest)
on 2007-03-12 18:55
(Received via mailing list)
On 3/12/07, David A. Black <dblack@wobblini.net> wrote:
> > > front to create an instance that has zero chance of being persisted
> > > seems to me contrary to the semantic thrust of the system.
> >
> > Ah, but it does. The create action has the corresponding
> >   user.attributes = params[:user]
> >   user.save
>
> But that user isn't the same instance as the @user from the new
> action. Somewhere in create you instantiate User again.

I see what you're saying, but don't understand why the User.new used
to build the edit form being the identical instance to the one saved
is important.

Their equivalence is enough for me. Perhaps it helps to think of a new
instance as a value object (equality by attributes) rather than an
entity (equality by id.)


> > So imagine we're Seaside: the new and create actions just happen to be
> > punctuated by a request+response:
> >   GET /users/new   user = User.new
> >   POST /users      user.update_attributes params[:user]
>
> OK... but we're not :-)  The separation, and the need to instantiate
> the class twice, are very palpable to me in the Rails scenario.  If
> the semantics were as above, then the situation might be different;
> but it's hard to project that into the current semantics.

I think they *are* as above ;-)


>
> In the User.new case, I think the problem is that it sort of wants to
> be like that, but there's no deception: you actually have to program
> the two instances and you can see graphically in your code that they
> have no relation to each other.

How would it feel to marshal the instance between requests?

GET /users/new   session[:user] = User.new
POST /users      session[:user].update_attributes params[:user]

Then the code can be collapsed to a sensible linear flow with the
intervening request as params[:user] = $interweb.gets


>
> I do know what you mean, though, and I've tried to view it that way.
> It doesn't totally work for me; it still feels like pressing an AR
> object into service outside of its sweet spot.

But it's not going to hell for that sweet bite of knowledge!  It's
free to live a happy object life despite driving a database to work.

Too many metaphors, I know ;-)


>
> I'm afraid I'm still a disbeliever :-)  But that's OK -- not everyone
> has to like every idiom, and it's very interesting to talk and think
> about this particular one, I find.

Agreed!

Best,
jeremy
E3640176765dae2465d33ef6eb114691?d=identicon&s=25 Bala Paranj (Guest)
on 2007-03-12 20:21
(Received via mailing list)
Resolved the simply helpful problem, if I have the line: @user =
User.createin the new method, I am able to use simply helpful plugin
without any
problems.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-12 20:40
(Received via mailing list)
Hi --

On 3/12/07, Bala Paranj <bcparanj@gmail.com> wrote:
> Resolved the simply helpful problem, if I have the line: @user = User.create
> in the new method, I am able to use simply helpful plugin without any
> problems.

That's not a good idea, as it will add a record to the users table
whether or not the creation form gets submitted.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
888e0536d537efdd327f3a1c39335e4c?d=identicon&s=25 Christos Zisopoulos (Guest)
on 2007-03-12 23:55
(Received via mailing list)
David,

On 12 Mar 2007, at 14:54, David A. Black wrote:

[snip]

I think it is indeed used quite widely.  I have a bit of a stumbling
block with the form helper stuff, because I strongly dislike this
idiom:

  def new
     @user = User.new
  end

where you create an AR instance and then discard it, for the sole
purpose of querying it as to whether or not it's a new object.[1]  But
don't listen to me; I'm in the minority on this :-)  And the general
idea of integrating stuff and making it less repetitive I think is
very sound, of course.


If it bothers you so much, you could maybe fiddle a bit with
'form_for' to accept this in the view:

 <% form_for(Person) ... %>

Then, the helper can call 'new' or it could interrogate Person in some
other way in order to discover its attributes and deal with the form
creation.

-christos
888e0536d537efdd327f3a1c39335e4c?d=identicon&s=25 Christos Zisopoulos (Guest)
on 2007-03-13 00:20
(Received via mailing list)
...ahem, I am assuming here that you have an 'edit' and a 'new' view
and thus...

 <% form_for Person %> /* new.rhtml */
 <% form_for @person %> /* in edit.rhtml */

If that is not the case in your apps, as it usally is in mine, then
ignore my suggestion; it would be of no help in your quest for a more
'likeable idiom'

-christos
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-13 00:35
(Received via mailing list)
Hi --

On 3/12/07, Christos Zisopoulos <fetaphunk@gmail.com> wrote:
>
> ...ahem, I am assuming here that you have an 'edit' and a 'new' view
> and thus...
>
>  <% form_for Person %> /* new.rhtml */
>  <% form_for @person %> /* in edit.rhtml */
>
> If that is not the case in your apps, as it usally is in mine, then
> ignore my suggestion; it would be of no help in your quest for a more
> 'likeable idiom'

The thing is, what SimplyHelpful does is it lets you use only one form:

  <% form_for @person ... %>

and it decides what the form action is by querying @person as to
whether or not it is a new record.  The crux of it is:

              html_options = if object.new_record?
                { :class  => dom_class(object, :new),  :id =>
dom_id(object), :method => :post }
              else
                { :class  => dom_class(object, :edit), :id =>
dom_id(object, :edit), :method => :put }
              end

So it's an alternative to having two forms (or two master forms that
share partials, or using variables to store the action names, or
whatever).


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
888e0536d537efdd327f3a1c39335e4c?d=identicon&s=25 Christos Zisopoulos (Guest)
on 2007-03-13 01:34
(Received via mailing list)
On 12 Mar, 23:34, "David A. Black" <dbl...@wobblini.net> wrote:

> The thing is, what SimplyHelpful does is it lets you use only one form:
>
>   <% form_for @person ... %>
>
> and it decides what the form action is by querying @person as to
> whether or not it is a new record.

Yes, I was aware of that. In most of my apps the 'new' form looks
nothing like the 'edit' form, hence my suggestion.


>               html_options = if object.new_record?

I guess you could monkey patch the above with something like:

  html_options = if object.respond_to?('new')

as a (probably incorrect?) way to catch if you have an instantiated
object, and then

 def new
  @person = Person
 end

But then 'new' becomes even more 'unlikeable'. Hmm...

-christos
4715ae8a9ac5152600ccd3012267ab6b?d=identicon&s=25 James Stewart (Guest)
on 2007-03-13 02:55
(Received via mailing list)
On Mar 12, 2007, at 3:20 PM, Bala Paranj wrote:
> Resolved the simply helpful problem, if I have the line: @user =
> User.create in the new method, I am able to use simply helpful
> plugin without any problems.

Are you sure that's a good idea? It may well be creating a lot of
empty entries in your database (if a user requests a form and then
doesn't complete it). And even if that never happens,  it will be
invoking any validations in your User model.

Whatever the conceptual rights or wrongs of using User.new in the new
method, it has a lot less performance implications than using create.

James.

--
James Stewart
http://jystewart.net/process/
E3640176765dae2465d33ef6eb114691?d=identicon&s=25 bcparanj@gmail.com (Guest)
on 2007-03-19 07:01
(Received via mailing list)
Sorry, I meant this:

def new
 @user = User.new
end

not create.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 David A. Black (Guest)
on 2007-03-19 12:59
(Received via mailing list)
Hi --

On 3/19/07, bcparanj@gmail.com <bcparanj@gmail.com> wrote:
>
> Sorry, I meant this:
>
> def new
>  @user = User.new
> end
>
> not create.

Scroll back about 12 messages in this thread for some discussion of
this idiom :-)


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)
This topic is locked and can not be replied to.