Unexpected Consequences

[jeremyevans]

Google Group Post: https://groups.google.com/g/ruby-forme/c/CpC0tiIjjgk
Google Group Date: Tue, 20 May 2014 16:50:03 -0700
Google Group Sender: [email protected]

Oo! This one’s strange. Probably my fault, somehow, but . . . strange.

mainform = Forme.form(ord, {:action=>'savechanges'}, {:labeler=>:explicit, :inputs_wrapper=>:table, :wrapper=>:trtd}) do |f|
f.input(:id, :type=>:hidden, :label=>nil)
...
f.input(:note, :size=>60, :type=>:textarea)
f.subform(:items, {:grid=>true, :legend=>nil, :labels=>["#", "SKU", "Name", "Price Ea.", "Shp.", "Disc.", "Tax"]}) do
f.input(:quantity, :size=>6)
...
f.input(:salestax, :size=>8)
f.tag(:td) << "Delete?"
f.input(:goaway, :name=>"Delete",:no_hidden => true, :type=>:checkbox)
end
f.button(:value=>'Save Changes')
end.to_s.as_xml

I’m trying to add the checkbox at the end of each row to delete items from the order. What I’m getting with the above code is
…Delete?<input type=checkbox…..

I’d rather have Delete? but I can’t figure out how to get both the input and the word “Delete” in the same table cell. I tried :label=“Delete,” but because it’s a grid, labels are being suppressed.

That’s not the strange thing, though. No, it has to do with what I used as the first parameter in order to get the checkbox to appear. The first symbol I used was, because it seemed obvious, “:delete”, as in

f.input(:delete, :name=“Delete”, :no_hidden=>true, :type=>:checkbox)

The first time I tried that, I said “Oh, drat, I did something wrong. Now the table’s not being out put at all!”

No, what had actually happened is that the database rows that were populating the models for the form…had been deleted. I didn’t submit the form; just loading the page with the form deleted the records from the database. Yikes?

Because it’s live data, I’ve hesitated to lock down the conditions. I’ll work on it more if you can’t reproduce it.

[jeremyevans]

Google Group Date: Tue, 20 May 2014 18:10:03 -0700
Google Group Sender: [email protected]

On Tuesday, May 20, 2014 4:50:03 PM UTC-7, Dave Howell wrote:

Oo! This one’s strange. Probably my fault, somehow, but . . . strange.

mainform = Forme.form(ord, {:action=>'savechanges'},
{:labeler=>:explicit, :inputs_wrapper=>:table, :wrapper=>:trtd}) do |f|
f.input(:id, :type=>:hidden, :label=>nil)
...
f.input(:note, :size=>60, :type=>:textarea)
f.subform(:items, {:grid=>true, :legend=>nil, :labels=>["#",
"SKU", "Name", "Price Ea.", "Shp.", "Disc.", "Tax"]}) do
f.input(:quantity, :size=>6)
...
f.input(:salestax, :size=>8)
f.tag(:td) << "Delete?"
f.input(:goaway, :name=>"Delete",:no_hidden => true,
:type=>:checkbox)
end
f.button(:value=>'Save Changes')
end.to_s.as_xml

I’m trying to add the checkbox at the end of each row to delete items from
the order. What I’m getting with the above code is
…Delete?<input type=checkbox…..

I’d rather have Delete? but I can’t
figure out how to get both the input and the word “Delete” in the same
table cell. I tried :label=“Delete,” but because it’s a grid, labels are
being suppressed.

You probably want to use a label for the checkbox:

f.input(:goaway, :name=>"Delete",:no_hidden => true, :type=>:checkbox,
:label=>'Delete?', :labeler=>:default)

That’s not the strange thing, though. No, it has to do with what I used as
the first parameter in order to get the checkbox to appear. The first
symbol I used was, because it seemed obvious, “:delete”, as in

    f.input(:delete, :name=“Delete”, :no_hidden=>true, 

:type=>:checkbox)

The first time I tried that, I said “Oh, drat, I did something wrong. Now
the table’s not being out put at all!”

No, what had actually happened is that the database rows that were
populating the models for the form…had been deleted. I didn’t submit the
form; just loading the page with the form deleted the records from the
database. Yikes?

Because it’s live data, I’ve hesitated to lock down the conditions. I’ll
work on it more if you can’t reproduce it.

This is expected. To get the value for the input, it's calling the delete
method on the obj, which deletes it from the database. You can add a
:value option so that it doesn't attempt to call the method to get the
value.

I recommend that you don't develop against a production database. :)

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Tue, 20 May 2014 18:28:58 -0700
Google Group Sender: [email protected]

On May 20, 2014, at 18:10 , Jeremy Evans [email protected] wrote:

You probably want to use a label for the checkbox:

f.input(:goaway, :name=>"Delete",:no_hidden => true, :type=>:checkbox, :label=>'Delete?', :labeler=>:default)

That didn’t actually work too well. I’ll need to the input or otherwise do something to keep it from linebreaking.
[ ]
Delete?

This is expected. To get the value for the input, it's calling the delete method on the obj, which deletes it from the database. You can add a :value option so that it doesn't attempt to call the method to get the value.

Well, it was pretty obvious why it did what it did once it did it. I would suggest that, although it might have been expected, it’s not desirable? Is there some way to have Forme treat models as read-only while building the form?

I recommend that you don't develop against a production database. :)

You say that, but actually, I think I’d be worse off if I didn’t. I’m trying to modify some record. I need some new code for that. At some point along the way, I do get the record modified, but I’m not satisfied with the code. I move to a new record, and keep working. If I weren’t using my production data, when I was all done, I’m fairly certain I would not remember every record I would have to re-modify ‘for real’. If I were spending more time developing and less time using, I would at some point create a development replica.

I do however, recognize the danger, and certainly don’t hold anybody else responsible, even if it’s not my bug that makes something bad happen. :) I also happen to have an extremely robust backup system.

[jeremyevans]

Google Group Date: Tue, 20 May 2014 18:47:54 -0700
Google Group Sender: [email protected]

On Tuesday, May 20, 2014 6:28:58 PM UTC-7, Dave Howell wrote:

On May 20, 2014, at 18:10 , Jeremy Evans wrote:

You probably want to use a label for the checkbox:

f.input(:goaway, :name=>"Delete",:no_hidden => true,
:type=>:checkbox, :label=>'Delete?', :labeler=>:default)

That didn’t actually work too well. I’ll need to the input or
otherwise do something to keep it from linebreaking.
[ ]
Delete?

Is that actually generating bad html, or is the browser styling just not
what you want? If the html is fine, you can probably fix the styling via
CSS (white-space: nowrap or something similar).

This is expected. To get the value for the input, it's calling the
delete method on the obj, which deletes it from the database. You can add
a :value option so that it doesn't attempt to call the method to get the
value.

Well, it was pretty obvious why it did what it did once it did it. I would
suggest that, although it might have been expected, it’s not desirable? Is
there some way to have Forme treat models as read-only while building the
form?

I don't think it's a good idea to attempt to protect against such misuse.
For the same reason that rm is not in interactive mode by default.

I recommend that you don't develop against a production database. :)

You say that, but actually, I think I’d be worse off if I didn’t. I’m
trying to modify some record. I need some new code for that. At some point
along the way, I do get the record modified, but I’m not satisfied with the
code. I move to a new record, and keep working. If I weren’t using my
production data, when I was all done, I’m fairly certain I would not
remember every record I would have to re-modify ‘for real’. If I were
spending more time developing and less time using, I would at some point
create a development replica.

I do however, recognize the danger, and certainly don’t hold anybody else
responsible, even if it’s not my bug that makes something bad happen. :) I
also happen to have an extremely robust backup system.

As long as you are OK restoring from backup, and nobody else cares what
happens to the data, it's probably fine.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Tue, 20 May 2014 19:02:42 -0700
Google Group Sender: [email protected]

On May 20, 2014, at 18:47 , Jeremy Evans [email protected] wrote:

I don't think it's a good idea to attempt to protect against such misuse. For the same reason that rm is not in interactive mode by default.

You don’t? Nor would I have called it “misuse.” You don’t have a protected namespace, so you’re asking a programmer to be aware of every method that the model has, not just the ones they actually use. I’m not suggesting that Forme be festooned with guardrails, but since Forme itself shouldn’t ever be changing the data (it’s building a form that should return changes), that doesn’t seem too outlandish to me.

As long as you are OK restoring from backup, and nobody else cares what happens to the data, it's probably fine.

I”ve never actually had to do that. Well, so far. :)

[jeremyevans]

Google Group Date: Tue, 20 May 2014 19:42:05 -0700
Google Group Sender: [email protected]

On Tuesday, May 20, 2014 7:02:42 PM UTC-7, Dave Howell wrote:

On May 20, 2014, at 18:47 , Jeremy Evans wrote:

I don't think it's a good idea to attempt to protect against such
misuse. For the same reason that rm is not in interactive mode by default.

You don’t? Nor would I have called it “misuse.” You don’t have a protected
namespace, so you’re asking a programmer to be aware of every method that
the model has, not just the ones they actually use. I’m not suggesting that
Forme be festooned with guardrails, but since Forme itself shouldn’t ever
be changing the data (it’s building a form that should return changes),
that doesn’t seem too outlandish to me.

I don't. Forme calls methods to get the values for the form inputs. It
cannot know which methods return data and which methods make database
modifications, or at least, it can't know all methods that make database
modifications. Users don't need to be aware of every method a model has,
only the ones they are using for form inputs. I don't think that is
unreasonable.

Some people may think it's better to protect against some known "bad"
methods, even if other "bad" methods are allowed. I believe that leads to
a false sense of security.

One simple way to work around this issue, freeze the instance:

Forme.form(obj.freeze, ...)

Of course, that won't prevent all database modifications (e.g.
f.input(:remove_all_order_items, ...)). If you want that to happen
automatically, override #forme_config for your model class(es) to freeze
the object in addition to calling super.

As long as you are OK restoring from backup, and nobody else cares what
happens to the data, it's probably fine.

I”ve never actually had to do that. Well, so far. :)

Backups you don't test are unlikely to actually be working. :)

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Tue, 20 May 2014 21:56:03 -0700
Google Group Sender: [email protected]

On May 20, 2014, at 19:42 , Jeremy Evans [email protected] wrote:

Backups you don't test are unlikely to actually be working. :)

Ugh.

Now, I never said I hadn’t tested it. What I said was I haven’t had to restore from backup in order to repair damage to my database from running development code against it. Although I really should try to find some time to test the current recovery protocols. Hmm.