"Wiggins D Anconia" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> >
> > Hi everybody,
> >
> > I'  m not sure this is the right list to ask this kind of question but
> I don't know where else. We are using html forms to insert and update
> news articles (texts) stored in a mysql database. Ever so often one of
> our journalists forgets to press the submit button or his computer
> crashes and everything written so far is lost. Is it possible to built
> something like an "autosave" function that submits the form data
> automatically every couple of minutes and updates the database entry?
> > Any hint's where to look up these kind of things?
> >
>
> It is sort of the right place :-)... Because this is a client side
> action (at least what triggers it) you are probably going to want to
> look to javascript. I believe you can setup timers in javascript that
> will trigger actions, that will be the hard part, the easy part is the
> action that is triggered is just a standard submit of the form, then the
> server side script would just store the info and reprint the form with
> the fields filled in the same, which I am assuming you can do.
>
> As a suggestion I would add (at least) two features,
>
> 1) a "clock" that displays a form element that is continually updated
> with the number of seconds left until the next save (as you will have to
> reload the page and there is nothing your journalist will hate more than
> being in the middle of a great thought and having his page reload on
> him) which brings me to...
>
> 2) have a "reset" clock button, so that if the user *is* paying
> attention they can reset it so that the refresh doesn't happen...
>
> Which brings me to "not refreshing" since I know you will ask.
> Presumably the javascript could build a request and submit it in a
> separate object (possibly in a popup window) which would provide all of
> the data from the form, the response would be that the form data has
> been saved and then wait a second or two and close the window
> automatically, then theoretically you wouldn't have to refresh the page.
> But now we are getting much more into the Javascript land where I am not
> nearly as strong.....
>

Overkill at this point, but you can set up and RPC server on the web server
and use a javascript RPC client to send the data to the server.

I use RPC::XML as the server (Apache::RPC::Server) and jsolait as the
client.

The initialization JavaScript looks like:

// rpc server endpoint
var rpcAddr = 'http://favorites.waveright.homeip.net/rpcservice';
// stores rpc server connection
try{
  var xmlrpc = importModule("jsolait.xmlrpc");
  rpcServer = new xmlrpc.ServerProxy(rpcAddr, new Array(), true);
}catch(e){
  reportRpcError( e );
}

and then you can say stuff like:

// calls rename method on rpc server
try {
  rv = rpcServer.favorites.rename( activeNode.type, activeNode.id,
newValue );
}catch(e){
  reportRpcError( e );
}

rename() is a perl subroutine compiled into the web server when it is
started. Your call would look something like:

rv = rpcServer.contentManager.updateArticle( articleID, articleBody );

What happens here is the RPC client formats the function call into XML, then
uses a http library that comes with your browser to make a http request to
the RPC server. The server reads the XML sent in the reqest, and calls the
perl function with the arguments specified. The return value of the function
is formatted as XML by the server and sent back to the client. The client
reads the XML response and converts the return value to a JavaScript
datatype.

This does away with things like the page reloading pointed out in another
reply. The RPC call to the server is totally transparent to the user.

The browser must support DOM level 2. IE 6, NN 7.1 and firebird all work
great.

If you would like to see an example of RPC in action check out:

http://favorites.waveright.homeip.net/

Like I said, a bit of overkill for what you mentioned, but if you implement
something like this then you can do things like build batch article updating
and so fourth in a snap. If you know ahead of time that you will want to
interface with the same data in two different ways ( for example, from both
a command line program and a CGI program ), then RPC or SOAP is the way to
go.

Todd W.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to