I’m trying to rewrite a fusebox-like application (Active4D plugin to
4D database) in RoR/postgres and I’m doing okay - but keep running
into things that stump me. It seems like it takes me hours to figure
out something that I could have written in pure code in minutes.
The select_month and select_day helper has been my latest waste of
time. All I’m trying to do is add a javascript onchange call and I
can’t get it to show up.
Given:
select_month(date, options = {}, html_options = {})
I have:
select_month(0,:include_blank => true, :onchange => “setBirthMMDD” )
I know I’ve gotten html options to work on form fields, but maybe I’m
missing something on how the html_options hash has to be formatted.
I’ve tried:
select_month(0,:include_blank => true, :html_options => {:onchange =>
“setBirthMMDD”} )
and that does not work, nor does it generate an error.
We use the birth month and day as a verification field and I’m just
trying to set a hidden field. Can’t ask for birthday because of
potential age discrimination issues.
I’ve also tried to set style or class and can’t seem to get any html
option to work - so I guess I don’t know what I’m doing.
Any help would be appreciated.
On Sep 2, 9:29 am, AppleII717 [email protected] wrote:
select_month(date, options = {}, html_options = {})
I have:
select_month(0,:include_blank => true, :onchange => “setBirthMMDD” )
I know I’ve gotten html options to work on form fields, but maybe I’m
missing something on how the html_options hash has to be formatted.
If you do that ruby doesn’t know that you want the first pair to be in
one hash and the second in another - you have to be explicit (ie this
time you don’t get to omit the {} round the hashes.
Fred
2009/9/2 AppleII717 [email protected]:
Given:
I’ve tried:
select_month(0,:include_blank => true, :html_options => {:onchange =>
“setBirthMMDD”} )
and that does not work, nor does it generate an error.
We use the birth month and day as a verification field and I’m just
trying to set a hidden field. Can’t ask for birthday because of
potential age discrimination issues.
If you are just trying to set a hidden field could you not just pass
whatever the user is entering/selecting to the server and compute the
value there rather than doing it in the browser? I believe it best to
avoid js where possible.
Colin
As usual, the fastest way to figure something out is to post something
on some help forum - then about 5 minutes after the post, the bell
goes off.
I almost had it right with:
select_month(0,:include_blank => true, :html_options => {:onchange =>
“setBirthMMDD”} )
just needed:
select_month(0, options = {:include_blank => true}, html_options =
{:onchange =>
“setBirthMMDD”} )
Just as the rdoc documentation described. The rdoc documentation still
causes me problems. It would have been helpful if they had at least
one example in the date helper area that used html_options=. Any time
I see a hash, I assume a => assignment.
I at least figured out how to read (or pay closer attention) rdoc
documentation a little better. There are just so many shortcut options
that ruby or rails tries to figure out that it confuses the issue.
Think I’ll just be explicit from now on and avoid the shortcuts.
Thank for the help.
Steve
On Sep 2, 6:44 am, Frederick C. [email protected]
AppleII717 wrote:
I’m trying to rewrite a fusebox-like application (Active4D plugin to
4D database) in RoR/postgres and I’m doing okay - but keep running
into things that stump me.
I’ve done a lot of work with Fusebox. It’s a pretty good framework.
Rails is nothing at all like it. Don’t expect much similarity. 
It seems like it takes me hours to figure
out something that I could have written in pure code in minutes.
“Pure code”? What do you mean by that? Particularly in the context of
coming from Fusebox, this seems meaningless.
Anyway, any learning process takes time. That’s the way it is.
The select_month and select_day helper has been my latest waste of
time. All I’m trying to do is add a javascript onchange call and I
can’t get it to show up.
JavaScript onchange handlers belong in external JavaScript files, not
within HTML. Ideally it should be possible to look at your generated
HTML and (except for a tag) not be able to tell whether any
JS is involved.
(One of the few things I really hate about Rails is that it encourages
mixing JS and HTML.)
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sep 2, 7:24 am, Colin L. [email protected] wrote:
If you are just trying to set a hidden field could you not just pass
whatever the user is entering/selecting to the server and compute the
value there rather than doing it in the browser? I believe it best to
avoid js where possible.
Colin
It’s a conversion issue and I’m still in a proof of concept phase. The
old data structure stored the birthMMDD as a string(4) and I imported
a couple hundred thousand records. If I move on with this
application, I’d break it down to two integer fields and I would not
need javascript or a computational method.
I’m trying to cut down my javascript habits, but sometimes it’s just
faster. My next problem is phone numbers. They were stored as string
(10), but the user could use any format they wished. At the end, we
just stripped out the non digits and validated on 10 digits. But when
you are displaying it in the form, 10 straight digits without
formatting is not very user friendly. Stripping them out in a before
filter has also become non trivial because of a polymorphic
relationship where the phone number fields don’t all use the same
field name. Its is almost faster to use javascript format the phone
number in a display field and put the unformatted number in the real
field.
Been “playing” with rails for about 3 years, but the world is more
than generated CRUD and there is a steep learning curve. You tend to
fall back to what you know.
Steve
AppleII717 wrote:
As usual, the fastest way to figure something out is to post something
on some help forum - then about 5 minutes after the post, the bell
goes off.
I almost had it right with:
select_month(0,:include_blank => true, :html_options => {:onchange =>
“setBirthMMDD”} )
just needed:
select_month(0, options = {:include_blank => true}, html_options =
{:onchange =>
“setBirthMMDD”} )
No. This actually assigns to local variables called options and
html_options, then uses the values of those assignments. What you
should do is
select_month(0, {:include_blank => true}, {:onchange => “setBirthMMDD”}
)
If this is hard to understand, review your basic Ruby syntax.
Just as the rdoc documentation described. The rdoc documentation still
causes me problems. It would have been helpful if they had at least
one example in the date helper area that used html_options=. Any time
I see a hash, I assume a => assignment.
And so you should. The issue here is that Ruby needs to know where one
hash ends and the other begins, which is why you need explicit braces.
I at least figured out how to read (or pay closer attention) rdoc
documentation a little better. There are just so many shortcut options
that ruby or rails tries to figure out that it confuses the issue.
Think I’ll just be explicit from now on and avoid the shortcuts.
Unfortunately, in trying to do that, you made a potentially more serious
mistake (more serious because it might clobber local variables you’re
using).
Thank for the help.
Steve
On Sep 2, 6:44�am, Frederick C. [email protected]
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
AppleII717 wrote:
[…]
I’m trying to cut down my javascript habits, but sometimes it’s just
faster. My next problem is phone numbers. They were stored as string
(10), but the user could use any format they wished. At the end, we
just stripped out the non digits and validated on 10 digits. But when
you are displaying it in the form, 10 straight digits without
formatting is not very user friendly.
Right.
Stripping them out in a before
filter has also become non trivial because of a polymorphic
relationship where the phone number fields don’t all use the same
field name.
Then this should probably be refactored.
Its is almost faster to use javascript format the phone
number in a display field and put the unformatted number in the real
field.
This is a 100% inappropriate use of JS. Regardless of the name of the
phone number field, it is trivial to write a helper function to do the
formatting on the server side – and it will work even if the client has
JS off. There is no reason at all to use JS here.
Been “playing” with rails for about 3 years, but the world is more
than generated CRUD
So is Rails.
and there is a steep learning curve.
Not really – as long as you don’t rely on scaffolding, and as long as
you’re OK with Ruby itself.
You tend to
fall back to what you know.
Steve
I don’t know…I tend to use it as an excuse to learn. YMMV.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sep 2, 8:28 am, Marnen Laibow-Koser <rails-mailing-l…@andreas-
s.net> wrote:
Right.
Stripping them out in a before
filter has also become non trivial because of a polymorphic
relationship where the phone number fields don’t all use the same
field name.
Then this should probably be refactored.
Right, but then I discovered I was going the wrong way on my
polymorphic relations. Without going into boring details, I have
several types of users (employees, citizens, customers, etc), each
with different profiles. I used Authlogic and defined the Users with a
poloymorphic loginable type. The mistake I make is trying to edit the
Citizen profile from User. It works, but that’s where I ran in to the
phone name problem. Going from the Citizen, I can update the User
attributes and take care of phone stuff in the Citizen controller/
model.
I now agree - well I did before - I was just stuck in a learning mode
that was not working because I took the wrong path.
You tend to
fall back to what you know.
Steve
I don’t know…I tend to use it as an excuse to learn. YMMV.
I’ve learned a lot since getting out of the “playing” mode. I just
hate getting stuck trying to do something I know should be simple. As
a few posts have pointed out, my Ruby is kind of weak. I love it, but
don’t have enough experience to do much without looking something up
in the docs. Guess I just want to learn faster!