xsltforms-support

[Xsltforms-support] Two questions: about success and failure of PUT, and about cache invalidation

[C. M. Sperberg-M. <cm...@bl...>]

My apologies if this is a question that's already been asked and 
clarified; I have not yet found any discussion of it, but I am still looking.

I have a form which users employ to make systematic changes to
XML documents they are working on.  From time to time, I would
like them to save their work.  So I have a Save button that performs
a PUT to the server, and updates nothing (so they can continue to
work).

Question 1:  can I tell somehow whether the PUT was successful
or not?  I'd like to be able to indicate (maybe with an alert, or just
some conditional text int he form) "the document has been saved"
or "there was an error, the document was not saved". 

Question 2:  Sometimes my users are feeling paranoid about whether
they have successfully saved their work to the server, so they
refresh the form, which once again confronts them with a list of
documents they can load.  They select the document they just
saved, and ask to load it.

At this point, I would very much like to see a new GET request in
the server logs, and the users would like to see the changes they
just made, when the document is reloaded.  But currently we are 
both disappointed:  the server logs show no trace of a GET
request, and the document loaded by the user is the one they
just loaded a few minutes earlier -- the changes they just saved
are not visible.  If I wait long enough -- a day suffices, five minutes
does not typically suffice -- I eventually see the new version of the
document.

I infer from this behavior that either the browser or XSLTForms
has a copy of the old form of the document in its cache and is using
that form, instead of issuing a fresh GET request.   

Do any readers of this forum have suggestions on how to tell
the browser, or XSLTForms, to ignore any cached copies of the
document and do a fresh GET?  (Shift-reload works for the
form itself, but the document in question here is not a form, but
a document instance in the form, which is loaded using a
Load Document button which fires the following submission:

      <xf:submission id="get-document" 
		     ref="instance('ui')/document-id" 
		     method="get" 
		     replace="instance" 
		     instance="doc">
	<xf:resource value="concat('../sessions/', instance('ui')/document-id)"/>
      </xf:submission>

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Two questions: about success and failure of PUT, and about cache invalidation

[C. M. Sperberg-M. <cm...@bl...>]

On Feb 21, 2013, at 6:58 PM, C. M. Sperberg-McQueen wrote:

> My apologies if this is a question that's already been asked and 
> clarified; I have not yet found any discussion of it, but I am still looking.
> 
> I have a form which users employ to make systematic changes to
> XML documents they are working on.  From time to time, I would
> like them to save their work.  So I have a Save button that performs
> a PUT to the server, and updates nothing (so they can continue to
> work).
> 
> Question 1:  can I tell somehow whether the PUT was successful
> or not?  I'd like to be able to indicate (maybe with an alert, or just
> some conditional text int he form) "the document has been saved"
> or "there was an error, the document was not saved". 

You know, it's amazing how easy it is to find the information 
you want in the spec, if first you admit publicly that you don't know
the answer and ask for help.  Having sent my query, I looked at
the spec and found the discussion of the xforms-submit-done and
xforms-submit-error.

I replaced the following submission:

      <xf:submission id="save" 
		     method="put" 
		     replace="none">
	<xf:resource value="concat('/security-through-obscurity/', instance('ui')/document-id )"/>
      </xf:submission>


with the following elaboration:

      <xf:submission id="save" 
		     method="put" 
		     replace="none">
	<xf:resource value="concat('/security-through-obscurity/', instance('ui')/document-id )"/>

	<xf:message ev:event="xforms-submit-done">Save was successful!</xf:message>
	<xf:message ev:event="xforms-submit-error">Oops!  Document was not successfully saved!
	  Write down the following information and report the problem:
	  A submission error (<xf:output value="event('error-type')"/>) occurred.
	  Response: <xf:output value="event('response-status-code')"/>.
	  Reason given: <xf:output value="event('response-reason-phrase')"/>.
	</xf:message>

      </xf:submission>

And the form now tells the user explicitly whether the save was successful 
or not.

I expect my users will get sick of the dialog box popping up on success, and
I may look for a way to make the success indicator less obtrusive, but
the error box will be helpful.

My question about evading an over-enthusiastic cache remains
an open question.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Two questions: about success and failure of PUT, and about cache invalidation

[Alain C. <ala...@ag...>]

Hello Michael,
> I expect my users will get sick of the dialog box popping up on 
> success, and I may look for a way to make the success indicator less 
> obtrusive, but the error box will be helpful. 
I guess a success message displayed only 5 seconds or cleared just after 
the next user interaction would be nice. There is no delay in standard 
XForms action except for incremental mode. A bubbling event might do the 
trick for clearing the success message...
> My question about evading an over-enthusiastic cache remains an open 
> question. 
This is a well-known XMLHttpRequest issue and many developers just add a 
dummy parameter, such as the current date and time, to the HTTP request 
filename so the browser always consider it different.

Thank you for your feedbacks!

-Alain

Re: [Xsltforms-support] Two questions: about success and failure of PUT, and about cache invalidation

[C. M. Sperberg-M. <cm...@bl...>]

On Feb 22, 2013, at 11:01 AM, Alain Couthures wrote:

> Hello Michael,
>> I expect my users will get sick of the dialog box popping up on success, and I may look for a way to make the success indicator less obtrusive, but the error box will be helpful. 
> I guess a success message displayed only 5 seconds or cleared just after the next user interaction would be nice. There is no delay in standard XForms action except for incremental mode. A bubbling event might do the trick for clearing the success message...

Good idea.

>> My question about evading an over-enthusiastic cache remains an open question. 
> This is a well-known XMLHttpRequest issue and many developers just add a dummy parameter, such as the current date and time, to the HTTP request filename so the browser always consider it different.


Brilliant.  Thank you, that should work.  I'll do that right now.

Michael

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Two questions: about success and failure of PUT, and about cache invalidation

[C. M. Sperberg-M. <cm...@bl...>]

On Feb 22, 2013, at 11:07 AM, C. M. Sperberg-McQueen wrote:

> 
> On Feb 22, 2013, at 11:01 AM, Alain Couthures wrote:
> 
>> ...
> 
>>> My question about evading an over-enthusiastic cache remains an open question. 
>> This is a well-known XMLHttpRequest issue and many developers just add a dummy parameter, such as the current date and time, to the HTTP request filename so the browser always consider it different.
> 
> 
> Brilliant.  Thank you, that should work.  I'll do that right now.
> 

For the record, I also found another way that works in my situation.  The server
for this project is running Apache, and I was able to persuade Apache to
set the Expires header by putting the following into an .htaccess file in
a directory located above all the documents where stale copies were
causing us harm:

ExpiresActive on
ExpiresDefault "access plus 60 seconds"

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************