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 <sa...-ee4meeAH724@public.gmane.org> 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 <salex-ee4meeAH724@public.gmane.org>:> > 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.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> > 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. > > > > > > >
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 Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> On Sep 2, 9:29 am, AppleII717 <sa...-ee4meeAH724@public.gmane.org>
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
On Sep 2, 7:24 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> 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:> 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 <script src> 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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
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 Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
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 CRUDSo 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. > > SteveI don''t know...I tend to use it as an excuse to learn. YMMV. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/.
On Sep 2, 8:28 am, Marnen Laibow-Koser <rails-mailing-l...@andreas- s.net> wrote:> 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.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.> > > 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. > >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.> > > 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.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!> Best, > -- > Marnen Laibow-Koserhttp://www.marnen.org > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > -- > Posted viahttp://www.ruby-forum.com/.