Possible to submit post data without going to new page

[ergophobe]

The subject line pretty much says it.

If it's possible at all, I would like to submit one small piece of a page to the server without leaving, reloading or otherwise updating the underlying HTML on the page. I've already taken care of displaying the new result on the page using javascript/DOM.

To give some background...

I have been working on a table that presents as text, but when the user clicks on a cell, it becomes an <input type="text" ... />. I have two ways to get it to do what I want, but I don't think either of them is compatible with the way I expect the user to use the table.

* Method 1. Edit a cell and submit to the server, then reload the page with the edited information.
- Problem: these pages could have a lot or rows, each row with a lot of data. I think people will get frustrated with reloading after each minor change.

* Method 2. edit, "save" the info on the page, edit, "save" the info on the page. This is not, however, sent to the server. I could double the "saves" as hidden inputs and then submit the whole page when the user is all done.
- Problem: If the user were to click a link or refresh or anything like that, all changes would be lost. Given that some cells are links ("more info" for especially large blob fields), I think that users would quite easily forget the need to submit the table and their changes would be lost.

Tom

[Purple Martin]

Put an iFrame in a hidden div. The page in the iFrame contains a small form. Using JavaScript you put the data from the table cell into a field in the form then submit the form. The page the user sees won't need to reload. When the hidden form page reloads you can use JavaScript to grab data returned by the server and then make changes to the visible table.

Alternatively, I've seen it done with Flash Communication Server. The Flash piece embedded in the page looks like a normal HTML table, and has a continuous two-way communication with the server and database, so there's no page reloading. I saw this done for a Content Management System within a controlled corporate environment and it worked very well, but it may not be appripriate to use this solution for pages viewed by the general public (because of the limitations of Flash).

[ergophobe]

Thanks for the suggestions.

I had thought about the inline frame option, but haven't really pursued it. I think that sounds best, since I wouldn't even know where to start with Flash. I had also thought about Flash, because it is in fact a closed system for a limited number of people, but as I say it's more a problem of my skills than the user base that pose the problem there.

Tom

[ergophobe]

In thinking about it, my problem with using inline frames is that it seems like if I do that, I will have to send a query to the database for every frame and, thus, every cell in the table. These tables are way too big for that.

I guess a third option would be a popup edit box. That might be made to work. This site will not be open to the public, so I can require that all users have JS and popups enabled.

Tom

[Purple Martin]

The form in the iFrame can have many fields, one for each table cell. Therefore you only need to submit the form once to work out changes for all the cells. The question then is WHEN should you submit? You could consider having an "Update Table" button that the user clicks to submit the iFrame and update the entire table. How this works will depend on how the table / interface is set up, so you'll have to think carefully about useability to decide if this is the best option for your application.

Whatever you do, you should consider some way of letting the user know that the contents of a cell(s) is in the process of being updated while the form is being submited and reloaded.

[ergophobe]

The form in the iFrame can have many fields, one for each table cell.
Therefore you only need to submit the form once to work out changes for all the cells.

That's basically what I'm trying to avoid. Since there's nothing on the page but the table, this amounts to just having the table be one big form or, possibly, a series of forms with a frame for each record, which might work pretty well. That makes the javascript for changing the table from text to form and back more problematic and increases the chance that a user would leave the page without saving. Of course, I can display the records as input fields, but then I might as well just have a normal form.

I won't say that my original idea for the page was particularly thought out - more an experiment than an idea that I would stand by. That said, a solution like the one that you envision sort of defeats the purpose of what I was trying to do. The idea was to create a compact table that would look just like a text table, but that could allow a few quick edits - main editing of a given record would take place in a different form that would show all fields for that record in full on a single page.

Again, this is for a very small number of "data-oriented" users who can be counted on to learn how to use the interface. The key thing is that it is as useable (in this case that likely means "time efficient" more than "intuitive") as possible for an *expert* user, rather than that it be accessible to a broad user base. The small number of people who will use this will spend a lot of time with it. It can have a slight learning curve, but it absolutely can't be annoying (and that's where I get stuck on most solutions - all seem to have some annoying aspect).

Tom

[ergophobe]

Another thread on Blinking Refresh [webmasterworld.com] alerted me to Javascript Remote Scripting. That's exactly what I was looking for.

Some links

[ashleyit.com ]
[developer.apple.com ]

[figment88]

I've used JavaScript Remote Scripting and had to change how I coded it. Basically the problem was network latency. The site almost always worked but some time there was a delay retrieving the information. I found it easier to restructure the site instead of figuring out how to relay status to the visitor.

If you are just interested in saving the form entires before they are submitted, you can use onchange and onclick events to call a JavaScript function that changes parameters on a webbug.

For example,

<script>
bug = new Image();

function save_info(param) {
bug.src = "/webbug.php?param=" + param;
}
</script>

Then webbug.php would be a script that sets session variables or persistant cookies.

[ergophobe]

I'm interested in submitting POST data without actually refreshing the page.

It's possible, for example, that a user might want to load a single huge page containing a large data set (a table of say 2000 rows and 3MB of data). I don't expect that on any regular basis, but it's likely that someone will want to do it occasionally.

I would like to allow that person to make a quick change here, a quick change there without refreshing the page.