| Re: how to create (open) a dialog box [message #175142 is a reply to message #175136] |
Tue, 16 August 2011 21:11   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
sheldonlg wrote:
> On 8/16/2011 1:03 PM, Thomas 'PointedEars' Lahn wrote:
>> The client-side dialog – in fact, any client-side code – should augment a
>> server-side generated solution (to reduce the number of roundtrips to the
>> server, thus enhancing user experience and reducing server/network load);
>> with few exceptions, it should not replace it. This can be done easily,
>> for example:
>>
>> <form action="delete-dialog.php"
>> onsubmit="return window.confirm('Delete?')">
>> <input type="submit" value="Delete">
>> </form>
>>
>> The best solution regarding this approach is a server-side framework
>> which provides the classes to generate the forms (here: both for
>> submitting the deletion request and confirming it) and the client-side
>> code, so that the data only needs to be maintained in one place.
>
> Wouldn't you use onsubmit only if you are submitting the entire page?
> The onclick allows you to confirm the deletion, send off an AJAX
> request, and still stay on the page.
You need to be more precise with your terminology. There are no pages, in
particular not with server-side programming.
An (X)HTML document (as it can also be generated by a server-side script)
can contain more than one form, and they can be submitted separatedly.
Also, the target of a form submission can be – in HTML 4.01 Transitional or
XHTML 1.0 Transitional, or in XHTML 1.x with a user-defined DTD, to satisfy
validity constraints – another window (an iframe, a frame, or a tab), in
which case the document in the form's viewport would not change.
In this case, change is the purpose of the form, though. One *wants* to
display a document with a delete confirmation dialog *even if* the client-
side dialog *cannot* be displayed.
If the client-side dialog cannot be displayed (which is the premise of my
suggestion), then "AJAX" would not work either (keep in mind that the term
is not exactly a misnomer in the only regard that the "J" stands for
"JavaScript".)
However, my example is flawed as it is – due to oversimplification –
incomplete: If you would confirm the client-side dialog, the server-side
confirmation dialog would be displayed regardless.
A fix would be to set the submitted value of an `input' element to a certain
different value before submission so that the server side would not generate
the confirmation dialog again, e.g.:
<script type="text/javascript">
function confirmDelete(form)
{
if (window.confirm("Delete this item?"))
{
form.elements["confirmed"].value = "1";
return true;
}
return false;
}
</script>
<form action="delete-dialog.php"
onsubmit="return confirmDelete(this)"
method="POST">
<input type="hidden" name="confirmed" value="0">
<input type="submit" value="Delete">
</form>
Then, on the server-side, e.g.:
<?php
if ($_POST['confirmed'] !== '1')
{
/* this part should be done dynamically by the mentioned framework */
?>
<form action="delete-dialog.php"
method="POST">
<div>
<input type="hidden" name="confirmed" value="1">
<span>Delete this item?</span>
<input type="submit" value="Delete">
</div>
</form>
<?php
}
else
{
/* proceed with deletion */
}
?>
(I am using POST, and not GET, here so that one is less likely to cause
deletion accidentally when navigating the history. A good browser would ask
the user before submitting POST data again.)
More sophisticated approaches include using XHR (colloquially and falsely
called "AJAX") to request, retrieve and display a server generated
confirmation dialog instead of the rather crude, built-in one (BTDT). But
AISB, this would not work without client-side scripting, so it can be safely
excluded as a *fallback* for a server-side solution.
HTH
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]