I'm curious to see what the _initComplete function does/looks like, with 
regards to ex2edit.php. I can get the TESubmit line in the debugmsgs, 
but I am not sure what the response is supposed to look like from my XML 
generator script.  I can make an Edit form, but when I "save" changes, 
the "Saving..." dialog pop-up appears and nothing happens, click "Ok" 
and it returns false.  I have added the "error" tag to my XML generator 
(I serialize and append the $_POST array to my error message) expecting 
to at least generate that much as the example does when any of the DB 
operations are performed.

Does the same back end script that generates the LiveGrid XML handle the 
post request for updates?  Am I missing a variable in the options?  Am I 
declaring an option incorrectly?

I am using Firebug to trace the XHR requests/responses and I never see 
the POST for the update to the record...

Attached is my js saved as a txt.

NOTE:
Due to security I am not using the supplied PHP back end scripts 
supplied with the  Rico package, I am interested in seeing what the raw 
request/responses are supposed to look like so that I may emulate them 
where needed.

So I have started to narrow down the reason I am not seeing a POST
request or response from my back-end.  It has sent me on a path, for
which I am still on, into the realm of modifying someone else's codes.

In Rico.TableEdit.options I have added the property "editTableAction"
with a default of "window.location.pathname"

In Rico.TableEdit.TESubmit() I changed:

new Ajax.Updater(this.responseDiv, window.location.pathname, ....
to
new Ajax.Updater(this.responseDiv, this.options.editTableAction ....

I did the same for Rico.TableEdit.deleteRecord()

I think however that by doing this I have opened up a vulnerability to a
CSFR/XSS attack... by allowing the calling script to modify the form
action could I not then inject code that sends your post to a different
server then???? or will Same Origin Policy be held intact?

******************

I am obviously missing something in the Rico.TableEdit logic...
I see my POST to my back-end script, of which is currently generating a
simple error as a response, to prove I can send a POST.  (I had caught
the error at one point and displayed it, as intended, in the saveMsg
dialog box, but changed something). Now the XHR response appears (in
firebug) the "Saving..." dialog appears and disappears thereafter the
LiveGrid is reset and empty.

I am going to try and back trace the modifications I made to
Rico.TableEdit to see if I can produce the error message again.  That 
was the closest I have made it to my intended behavior.  (Thus far
my main issue remains to be the inability to send my POST back to
the currently loaded page, as it appears Rico.TableEdit does.)

"Due to security I am not using the supplied PHP back end scripts 
supplied with the  Rico package"

I'm not sure why this is the case. Is there something in particular that 
concerns you?

Matt

I have implemented an in-house security wrapper, it is written in a PHP
5.2.x OOP paradigm.  It manages sessions and users logged in to the web
application.  Due to the fact that the development and implementation of
this security feature began well before I even started to learn how to
use Rico, it made more sense to me to figure out what Rico expected the
XML responses to look like and then emulate them.

After this thread was started, I did in fact, figure out how to add a
level of flexibility to TESubmit().

After the line:
Rico.writeDebugMsg("TESubmit:"+parms);

I added:

var updaterParams = {
  parameters:parms,
  onComplete: function(){
    this.responseHandler;
  }
};
new Ajax.Updater(this.responseDiv, this.options.editTableAction,
updaterParams);

I can catch a message in my XML response, populate the dialog but I
can't figure out where to go to get the LiveGrid to refresh(send a
request for the new XML).  Your suggestion is processResponse(), as of
now it does not appear that I even get that far in my scripts.  I
dropped in an alert(), with no result, I will put a stop point in
firebug next, to see if I missed something.

I feel like a total hack job though, because my understanding of
javascript isn't all that great. For example I understand the syntax I
can follow most of what you are doing, but I do not understand why I
needed to add updaterParams in order to catch and handle the XML
response... instead of the way you originally wrote it:
new Ajax.Updater(this.responseDiv, ...., {parameters:parms,
onComplete:this.responseHandler});

So it turns out my great idea wasn't so great... the scope resolution
problems I was having...were my own doing... var updaterParams was
totally a fluke, the Ajax.Updater was working...in spite of not having
any options defined. ie. the onComplete....

I put the call to the ajax.updater back to:
new Ajax.Updater(...,...,{parameters:parms,
onComplete:this.responseHandler});

I am now "making it to" processResponse(), but now I have a whole slew
of new questions to answer.  First being where is
this.options.onSubmitResponse defined/declared or by what is
onSubmitResponse defined/declared?

One way to further explore what is going on is to use firebug and insert 
some console commands into your script in strategic points of the 
processing, check out Firebug's Console API Documentation( 
http://www.getfirebug.com/console.html )
console.log() and console.debug() are my personal favorites. Conditional 
breakpoints set in the script tab are also extremely useful.(Right-click 
to the left of the line number)

Good Luck, -Mark