SitePoint Sponsor

User Tag List

Results 1 to 12 of 12

Hybrid View

  1. #1
    SitePoint Enthusiast
    Join Date
    May 2006
    Location
    UK
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Toggling visibility of DIVs using RJS

    I want to create an app which has a form with a list of inputs and when the focus is on an input a div appears which displays help relating to that input. For example, the user tabs onto first name and a div appears (with a scriptaculous effect) explaining why this field is required, the same will happen for surname, dob etc.

    I am a total rails newbie and i'm having trouble figuring out how to do this.

    Thanks in advance.

  2. #2
    SitePoint Member vSkyfluxx's Avatar
    Join Date
    Mar 2006
    Posts
    23
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't done enough JavaScript wizardry but this is what I would try using something like observe_field on whichever inputs you need the helper div. If there are multiple helper divs, just render them next to the inputs (using a script.aculo.us helper, RJS, or a custom JS function) and make their display property initially set to none. The effect of observe_field would then show & hide the appropriate div. If there's only one helper div, then you could can have observe_field call an action with an RJS template, which would populate the helper div given the proper input field id.
    "Earth smiles in flowers" - Ralph Waldo Emerson
    DuskDesigns

  3. #3
    SitePoint Enthusiast AllTom's Avatar
    Join Date
    Feb 2008
    Location
    Wherever danger lies...
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Please use a Javascript function on the page instead of RJS. I don't see a need for the server to get involved in unhiding divs. Use an observe_field call like this:

    Code Ruby:
    observe_field("username", :function => "show_help('username')")

    Define the Javascript function show_help() somewhere on your page to show and hide the help boxes with appropriate calls to $('div-id').show() and .hide().
    Last edited by AllTom; Feb 7, 2008 at 09:31. Reason: typo

  4. #4
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AllTom View Post
    Please use a Javascript function on the page instead of RJS. I don't see a need for the server to get involved in unhiding divs.
    I thought a key reason for using RJS was that you could write the code in Ruby and not need to know about the JavaScript. That is, to let the framework worry about generating the JavaScript, in much the same way as systems like ASP.Net go about things.

    The key point here is surely which language you choose to do your coding in, rather than where that code activates. If you think all client side JavaScript should be written in native JavaScript, there seems to me to be little point in Rails including the AJAX libraries it now has.

    For example, most of the script.aclous.us functions create operations that are totally client side. For example, draggable_element and drop_receiving_element. Even the Prototype functions such as link_to_remote include a significant proportion of code that triggers client side.

  5. #5
    SitePoint Enthusiast AllTom's Avatar
    Join Date
    Feb 2008
    Location
    Wherever danger lies...
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ReggieB View Post
    I thought a key reason for using RJS was that you could write the code in Ruby and not need to know about the JavaScript. That is, to let the framework worry about generating the JavaScript, in much the same way as systems like ASP.Net go about things.

    The key point here is surely which language you choose to do your coding in, rather than where that code activates. If you think all client side JavaScript should be written in native JavaScript, there seems to me to be little point in Rails including the AJAX libraries it now has.

    For example, most of the script.aclous.us functions create operations that are totally client side. For example, draggable_element and drop_receiving_element. Even the Prototype functions such as link_to_remote include a significant proportion of code that triggers client side.
    However, ignoring efficiency to the point that one would write code that asks the server "they clicked a text box, what do I do??" and waits for its response is not good.

    Use RJS in the situations when you want to generate Javascript based on information from a database. The Javascript libraries are so high level that code for basic effects will look nearly like Ruby anyway.

    You can also look at it from a compatibility standpoint. Browsers which support AJAX are a subset of browsers which support Javascript, which is a subset of browsers which support HTML and CSS. If you use observe_field to call a Javascript function that shows divs dynamically, your code can easily be made to downgrade to work in every browser.

    If you pull the divs using AJAX, you can cater only to the smallest portion of web users.
    Last edited by AllTom; Feb 8, 2008 at 08:31. Reason: dumb typos

  6. #6
    SitePoint Evangelist
    Join Date
    Feb 2006
    Location
    Worcs. UK
    Posts
    404
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AllTom View Post
    You can also look at it from a compatibility standpoint. Browsers which support AJAX are a subset of browsers which support Javascript, which is a subset of browsers which support HTML and CSS. If you use observe_field to call a Javascript function that shows divs dynamically, your code can easily be made to downgrade to work in every browser.
    That is just back-to-front reasoning. One of the main problems with writing pure JavaScript is that different browers work with different versions. For example, older version of MS Internet Explorer don't use JavaScript but instead the very similar JScript.

    So while the subset of browsers that support JavaScript/JScript is large, you have to either be restrictive with your coding or write multiple versions of your code to be compatible with the differences between versions and the way browsers handle them.

    One of the reasons for using AJAX is that it take the headache of having to deal with this multiplicity of brower environments away from the developer. The developer codes one set of AJAX instructions and the AJAX functions themselves detect the browser and handle the variation in output code needs to perform the required action.

  7. #7
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This would be a real easy one if observe_field could take a block like link_to_function.

    Oh well.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  8. #8
    SitePoint Enthusiast AllTom's Avatar
    Join Date
    Feb 2008
    Location
    Wherever danger lies...
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samsm View Post
    This would be a real easy one if observe_field could take a block like link_to_function.

    Oh well.
    That's a great point. I missed this functionality being added. It looks like link_to_remote is just using PrototypeHelper::update_page which takes a block and returns Javascript. You could probably embed the RJS with something like

    Code Ruby:
    observe_field("username", :function => update_page { |page| page[:username_help].visual_effect(:appear) })

    Has anyone tried this? That would be a handy way of putting the Javascript on the page without AJAX.

  9. #9
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AllTom View Post
    Code Ruby:
    observe_field("username", :function => update_page { |page| page[:username_help].visual_effect(:appear) })
    I made a mental note of this a month ago, and just had the opportunity to try it ... seems to work perfectly.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  10. #10
    SitePoint Enthusiast AllTom's Avatar
    Join Date
    Feb 2008
    Location
    Wherever danger lies...
    Posts
    48
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vSkyfluxx's original suggestion was to use observe_field with a "script.aculo.us helper, RJS, or a custom JS function," and I recommended not using RJS. That was because, before samsm's post, I did not realize that RJS could be used with observe_field to generate the Javascript in-place, instead of in an RJS view on the server (all I'd ever done). This is all my misunderstanding.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •