Forum: Ruby on Rails Observing few fields in a form - Best Practise?

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.
Vinay (Guest)
on 2008-10-11 08:34
(Received via mailing list)
Hi,

im looking to build a page similar to a shopping cart page. When you
change the 'price' or 'quantity' fields, the total is calculated and
displayed.
There are other fields in the form which have no relation to this
action. So i guess observe_form is not required. Can someone tell me
what the best practise is for this?
Erol F. (Guest)
on 2008-10-11 09:12
(Received via mailing list)
On Oct 11, 12:33 pm, Vinay <removed_email_address@domain.invalid> wrote:
> Hi,
>
> im looking to build a page similar to a shopping cart page. When you
> change the 'price' or 'quantity' fields, the total is calculated and
> displayed.
> There are other fields in the form which have no relation to this
> action. So i guess observe_form is not required. Can someone tell me
> what the best practise is for this?

Javascript on the client-side will give you the fastest response, as
well as save you some bandwidth.
Xavier N. (Guest)
on 2008-10-11 12:16
(Received via mailing list)
On Sat, Oct 11, 2008 at 6:33 AM, Vinay <removed_email_address@domain.invalid>
wrote:

> im looking to build a page similar to a shopping cart page. When you
> change the 'price' or 'quantity' fields, the total is calculated and
> displayed.
> There are other fields in the form which have no relation to this
> action. So i guess observe_form is not required. Can someone tell me
> what the best practise is for this?

In the server you certainly have code to compute the total of the
cart. It probably works with :decimal numbers that are guaranteed to
add and subtract as expected.

Depending on the details of the application, my first approach would
be to just send the entire form to the server and let that code
compute what is needed. I do that myself in a commercial online
invocing application.

Alternatively you duplicate the server code in JavaScript (that's
duplication because you'll still needed on the server). I'd only do
that if there's a strong reason that justifies it.
Vinay (Guest)
on 2008-10-11 12:58
(Received via mailing list)
thank you both for your replies!
So if we consider an invoicing application itself, what you say is
that i need to observe the fields rate, quantity, tax, etc (say)
independently, and then send in the whole form when even one field is
changed? If we take an invoice example, there are going to be fields
like invoice number, recipient, created on etc which are hardly
necessary for this calculation right?
This was what led me to wonder if there was an observer that watches a
specific set of fields and performs a particular action when any one
of them is changed and passes all the values in these fields as
parameters. It just seems like something Rails would/should have.
If you think sending in the whole form is the best way to do this,
then how can i do that? I should use one observe field per input
field, and? i dont know the syntax to pass the whole form with the
url.
Xavier N. (Guest)
on 2008-10-11 20:58
(Received via mailing list)
On Sat, Oct 11, 2008 at 10:57 AM, Vinay <removed_email_address@domain.invalid>
wrote:

> thank you both for your replies!
> So if we consider an invoicing application itself, what you say is
> that i need to observe the fields rate, quantity, tax, etc (say)
> independently, and then send in the whole form when even one field is
> changed? If we take an invoice example, there are going to be fields
> like invoice number, recipient, created on etc which are hardly
> necessary for this calculation right?

A general rule of thumb of mine is: Consider as a first choice the
approach that is both easy and trivially robust.

In this case, submitting the form is just a matter of setting :submit
=> 'invoice-form' in the observers.

One could select the strictly needed fields and avoid sending the
invoice number, customer ID, etc. to save a few bytes. But that
introduces more complexity and a coupling point between the form and
JavaScript.

So the question I ask myself is: is there some measure that justifies
that? Is the application having issues with the load or something due
to that? The answer so far is no, so I just :submit the form.
Vinay (Guest)
on 2008-10-13 13:18
(Received via mailing list)
I have this in place for now.

<%= observe_field 'cart_record_attributes__qty',:frequency => 0.1,:url
=>{:action => 'calculate', :submit => 'cart_form'},:method
=>:get,:with => "'qty='+ element.value" %>

i dont see the parameters being passed in the dvlpmnt log. Im
obviously not doing this right. Help?
The form is for an instance variable of cart.
<% form_for @cart do |f| %>
and Record is a child model (cart has_many records) and hence the long
name of the qty field(cart_record_attributes__qty).
Vinay (Guest)
on 2008-10-13 13:36
(Received via mailing list)
I vaguely remember coming across a post which mentioned how to pass
multiple form element values through the :with option. Does anyone
know how to do that?
Frederick C. (Guest)
on 2008-10-13 13:46
(Received via mailing list)
On Oct 13, 10:36 am, Vinay <removed_email_address@domain.invalid> wrote:
> I vaguely remember coming across a post which mentioned how to pass
> multiple form element values through the :with option. Does anyone
> know how to do that?
>
That may have been my blog post here:
http://www.spacevatican.org/2008/5/17/with-or-with...

Fred
Vinay (Guest)
on 2008-10-13 14:57
(Received via mailing list)
:) thanks for that. Its working now.


On Oct 13, 2:45 pm, Frederick C. <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.