AJAX + Table


#1

Hello all.

I am trying ot load table rows using AJAX based on a search. The
following code results in:

  1. Firefox renders correctly (Multiple rows inserted into page).
  2. Opera renders the entire returned string in one by the looks of
    it (Bunched up under first header, the <> tags arne’t visible)
  3. IE6 does nothing…great :wink:
  4. This is driving me nuts so any help would be much appreciated :slight_smile:

    SEARCH PAGE (Has a layout with unintereting stuff in it. The JS’s are
    there:)

    <%= form_remote_tag(:update => “results”,
    :url => { :action => :results },
    :position => “bottom” ) %>
    <%= render :partial => ‘form’ %>
    <%= submit_tag “Search” %>
    <%= end_form_tag %>

    SPR Number Developer Origin Date Status

    CONTROLLER FUNCTION

    def results
    @componentlogs =
    Componentlog.find_by_compname(params[:componentlog][:cl_compname]).reverse
    render :partial=> “componentlog”, :collection => @componentlogs
    end

    PARTIAL FORM

    <%=h componentlog.cl_spr %> <%=h componentlog.cl_user %> <%=h componentlog.cl_fromarea %> <%=h componentlog.cl_date %> <%=h componentlog.cl_date.to_formatted_s(:my_time) %> <%=h componentlog.cl_status %>

    Any help would be seriously appreciated!

    Thanks very much


#2

Jeff J. wrote:

SPR Number Developer Origin Date Status

Have you tried wrapping the table in a div and replacing the entire
table?

_Kevin


#3

Kevin O. wrote:

Jeff J. wrote:

SPR Number Developer Origin Date Status

Have you tried wrapping the table in a div and replacing the entire
table?

_Kevin

Can’t do that because it is a partial view that is being called
repeatedly for each item in the list. How would I render the headers
only once and not end up with

HEADERS
DATA ROW
HEADERS
DATA ROW
HEADERS
DATA ROW

I tried rendering a separate partial for the headers but that fell over.


#4

Why can’t you have a partial for the table that utilizes the partials
for
the rows to render itself? Then just redraw that partial in a div.

-Will


#5

Jeff J. <rurounijones@…> writes:

  1. Firefox renders correctly (Multiple rows inserted into page).
  2. Opera renders the entire returned string in one by the looks of
    it (Bunched up under first header, the <> tags arne’t visible)
  3. IE6 does nothing…great :wink:
  4. Jeff,

    I believe the reason you are experiencing this is do to the issue
    discussed
    here:
    http://www.robsanheim.com/2005/10/11/prototype-insertion-ie-6-trs-and-invalid-target-element-for-this-operation/

    I don’t have any experience with Opera, myself, but I know that in IE it
    is not
    possible to insert new rows into a table using the DOMs innerHtml
    property
    (which is how the code that is generated by the form_remote_tag is doing
    it).
    Unfortunately, as helpful as all these helper tags are in Rails in
    abstracting
    out the javascript code involved, sometimes they can’t cover up the
    pecularities
    of particular browsers. You will likely need to resort to either
    modifying the
    Prototype code yourself or wrapping the returned results in some code to
    detect
    whether it needs to use the workarounds available for IE.

    Regards,
    Tom Lockney


#6

Thomas L. wrote:

Jeff J. <rurounijones@…> writes:

  1. Firefox renders correctly (Multiple rows inserted into page).
  2. Opera renders the entire returned string in one by the looks of
    it (Bunched up under first header, the <> tags arne’t visible)
  3. IE6 does nothing…great :wink:
  4. Jeff,

    I believe the reason you are experiencing this is do to the issue
    discussed
    here:
    http://www.robsanheim.com/2005/10/11/prototype-insertion-ie-6-trs-and-invalid-target-element-for-this-operation/

    I don’t have any experience with Opera, myself, but I know that in IE it
    is not
    possible to insert new rows into a table using the DOMs innerHtml
    property
    (which is how the code that is generated by the form_remote_tag is doing
    it).
    Unfortunately, as helpful as all these helper tags are in Rails in
    abstracting
    out the javascript code involved, sometimes they can’t cover up the
    pecularities
    of particular browsers. You will likely need to resort to either
    modifying the
    Prototype code yourself or wrapping the returned results in some code to
    detect
    whether it needs to use the workarounds available for IE.

    Regards,
    Tom Lockney

    Thank you very much for that Tom. I had spent the best part of the day
    googling to try and find information for this but I guess my google-fu
    is weak (Although I was focussing on the Opera bit)!

    I am a newbie when it comes to RoR but I shall try the methods listed
    above and in the posts attached to that website.

    Again thanks.

    (Might have to add something to the WIKI about this. It must be a pretty
    common operation)


#7

Jeff J. <rurounijones@…> writes:

Again thanks.

No problem. It actually took me a second to realize that was the problem
you
were seeing. I was familiar with it from doing javascript coding in IE
from
years past (it predates IE 6).

(Might have to add something to the WIKI about this. It must be a pretty
common operation)

It’s already listed on the scriptaculous wiki under the prototype
section, but
most people probably don’t know to look there for things like this:

http://wiki.script.aculo.us/scriptaculous/show/Insertion.Bottom


#8

I just went through this myself.

What you need for IE to work properly is a TBODY tag within the table,
and
target that ID instead of the Parent table.

Even though that worked perfectly fine, I found that when I tried to
replace
all of the

rows with a new set, I had to first add the new ones,
then
remove the old ID’s last. I really didn’t get to the bottom of why this
happens, everything looked fine while debugging, but in any case, it
worked
so I am happy with it for now :slight_smile:
> > > > > > > >
SPR NumberDeveloperOriginDateStatus

In RJS you could write:
tablelog.each { |row| page.insert_html :bottom, ‘results’, render
:partial
=> ‘table/row’, :locals => { :componentlog => row } }

Which the table/row partial contains:

<%=h componentlog.cl_spr %> <%=h componentlog.cl_user %> <%=h componentlog.cl_fromarea %> <%=h componentlog.cl_date %> <%=h componentlog.cl_date.to_formatted_s(:my_time) %> <%=h componentlog.cl_status %>

Regards,
Nathaniel.

 Nathaniel S. H. Brown                           http://nshb.net

#9

A simple workaround for this is to have the row posted as a complete
one-row
table directed to a hidden div. You can also add a ‘:complete’ action,
which is to run a short javascript to remove the row from the hidden div
and
insert it into the main table. This works fine in Firefox.

Here is my form_remote_tag for this method:

<%= form_remote_tag( :update => ‘effort_add_div’,
:url => { :action => ‘ajax_add_effort’,
:id => @person.id,
:person_id => @person.id,
:task_id => task.id,
:day_id => @day.id, :date => @day.date } ,
:complete => ‘xfereffort()’ ) %>

And here is my row transfer code:

function xfereffort(){
var src=document.getElementById(‘effort_add_table_tbody’);
var dst=document.getElementById(‘effort_table_tbody’);
var lst=document.getElementById(‘effort_id_list’);

var rows=src.getElementsByTagName(‘TR’);
if (rows.length > 0){
var row=rows[0];
var rowid=row.getAttribute(“id”).split(’.’)[1];
src.removeChild(row);
dst.appendChild(row);
var elist=lst.value;
if (elist.length > 0){
lst.value = elist + “,” + rowid;
}else{
lst.value=rowid;
}
}
}