Rails - Jul 2006 - Best practices - field initialization based on display rules

All,

I have a form with the following field interaction rules.

Given checkbox A,
text field B
text field C

If checkbox A is checked then make text field C equal to the value of 
text field B and disable field C.

If checkbox A is unchecked then enable field C.

In order to display a form where I''m manipulating an already existing 
object, I have something like this in my RHTML template to display text 
field C:

<%= (@obj.field_B == @obj.field_C)  ?
     text_field(:obj, ''field_C'', :disabled =>
''true'') :
     text_field(:obj, ''field_C'', :disabled =>
''false'') %>

Should I put this logic in a helper so as to simplify my template and 
keep this small bit of business logic out of it?

I already have Javascript that would force this behavior for me given 
the checked status of the checkbox - should I just call that Javascript 
function in an onLoad() handler?

Should I use an onLoad handler that executes an AJAX call to handle 
setting up these fields correctly - then I could just add AJAX calls to 
default other fields as well?  (seems a little excessive to me).

Thanks,
Wes

-- 
Posted via http://www.ruby-forum.com/.

On Monday, July 17, 2006, at 7:48 PM, Wes Gamble wrote:
>All,
>
>I have a form with the following field interaction rules.
>
>Given checkbox A,
>text field B
>text field C
>
>If checkbox A is checked then make text field C equal to the value of
>text field B and disable field C.
>
>If checkbox A is unchecked then enable field C.
>
>In order to display a form where I''m manipulating an already
existing
>object, I have something like this in my RHTML template to display text
>field C:
>
><%= (@obj.field_B == @obj.field_C)  ?
>     text_field(:obj, ''field_C'', :disabled =>
''true'') :
>     text_field(:obj, ''field_C'', :disabled =>
''false'') %>
>
>Should I put this logic in a helper so as to simplify my template and
>keep this small bit of business logic out of it?
>
>I already have Javascript that would force this behavior for me given
>the checked status of the checkbox - should I just call that Javascript
>function in an onLoad() handler?
>
>Should I use an onLoad handler that executes an AJAX call to handle
>setting up these fields correctly - then I could just add AJAX calls to
>default other fields as well?  (seems a little excessive to me).
>
>Thanks,
>Wes
>
>--
>Posted via http://www.ruby-forum.com/.
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
I would do this in two steps..

First.. use your controller to set the proper state of instance  
variables so that the rules are enforced when an object is loaded in.   
This way you don''t need any JS to play around with the initial
settings.
 You can also set the enabled/disabled state of controls like this.

Second... I would use the KRJS plugin to enforce the rules once the page  
has been loaded.  It''s pretty simple to add an AJAX response to an  
''onchange'' event and then embed the RJS in the controller. 
This keeps
the business logic out of the view.

In theory you could write a JS library that does all the validation on  
the client side, but I wouldn''t trust that route.  It''s not
very DRY.


_Kevin
www.sciwerks.com

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.

Kevin Olbrich wrote:
> On Monday, July 17, 2006, at 7:48 PM, Wes Gamble wrote:
>>
>>Should I put this logic in a helper so as to simplify my template and
>>Thanks,
>>Wes
>>
>>--
>>Posted via http://www.ruby-forum.com/.
>>_______________________________________________
>>Rails mailing list
>>Rails@lists.rubyonrails.org
>>http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> I would do this in two steps..
> 
> First.. use your controller to set the proper state of instance
> variables so that the rules are enforced when an object is loaded in.
> This way you don''t need any JS to play around with the initial
settings.
>  You can also set the enabled/disabled state of controls like this.
> 
> Second... I would use the KRJS plugin to enforce the rules once the page
> has been loaded.  It''s pretty simple to add an AJAX response to an
> ''onchange'' event and then embed the RJS in the
controller.  This keeps
> the business logic out of the view.
> 
> In theory you could write a JS library that does all the validation on
> the client side, but I wouldn''t trust that route.  It''s
not very DRY.
> 
> 
> _Kevin
> www.sciwerks.com

Kevin,

I take your point on the DRYness of a client-side approach.  On the 
other hand, what I''m needing to do in the view doesn''t really
need any
information from the server so doing a POST just to do AJAX somehow 
seems excessive (probably because it''s ingrained in me that doing the 
POST is expensive, even though I know it''s not because it''s
not the
whole page worth of data going back and forth).  But I see your point 
and I''d consider an AJAX approach.

However, I''m not sure I get you on this point:

"You can also set the enabled/disabled state of controls like this."

Do you mean set up a variable in my model to represent the state of the 
edit field in my view (e.g. enabled vs. disabled)?  If so, I would think 
that that sort of thing would belong in a "form model" object (what in
the Java world we call a form bean, which is simply responsible for 
tracking the state of form elements).

Thanks,
Wes

-- 
Posted via http://www.ruby-forum.com/.

On Monday, July 17, 2006, at 9:16 PM, Wes Gamble wrote:
>Kevin Olbrich wrote:
>> On Monday, July 17, 2006, at 7:48 PM, Wes Gamble wrote:
>>>
>>>Should I put this logic in a helper so as to simplify my template
and
>>>Thanks,
>>>Wes
>>>
>>>--
>>>Posted via http://www.ruby-forum.com/.
>>>_______________________________________________
>>>Rails mailing list
>>>Rails@lists.rubyonrails.org
>>>http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>> I would do this in two steps..
>>
>> First.. use your controller to set the proper state of instance
>> variables so that the rules are enforced when an object is loaded in.
>> This way you don''t need any JS to play around with the initial
settings.
>>  You can also set the enabled/disabled state of controls like this.
>>
>> Second... I would use the KRJS plugin to enforce the rules once the
page
>> has been loaded.  It''s pretty simple to add an AJAX response
to an
>> ''onchange'' event and then embed the RJS in the
controller.  This keeps
>> the business logic out of the view.
>>
>> In theory you could write a JS library that does all the validation on
>> the client side, but I wouldn''t trust that route. 
It''s not very DRY.
>>
>>
>> _Kevin
>> www.sciwerks.com
>
>
>Kevin,
>
>I take your point on the DRYness of a client-side approach.  On the
>other hand, what I''m needing to do in the view doesn''t
really need any
>information from the server so doing a POST just to do AJAX somehow
>seems excessive (probably because it''s ingrained in me that doing
the
>POST is expensive, even though I know it''s not because
it''s not the
>whole page worth of data going back and forth).  But I see your point
>and I''d consider an AJAX approach.
>
>However, I''m not sure I get you on this point:
>
>"You can also set the enabled/disabled state of controls like
this."
>
>Do you mean set up a variable in my model to represent the state of the
>edit field in my view (e.g. enabled vs. disabled)?  If so, I would think
>that that sort of thing would belong in a "form model" object
(what in
>the Java world we call a form bean, which is simply responsible for
>tracking the state of form elements).
>
>Thanks,
>Wes
>
>--
>Posted via http://www.ruby-forum.com/.
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
Something like that.  I sometimes put code in my views like this..

<%= text_field ''model'',''attribute'',
:disabled=>@model.some_method %>

this works when the page is first loaded to set the initial state but  
you then need to worry about it from then on.

Regarding the AJAX thing... I just do what is easiest to implement and  
then optimize it later if it becomes a problem.  Using something like  
the KRJS plugin, it''s almost trivial to implement this sort of thing.


_Kevin
www.sciwerks.com

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.