Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #2798 > unrolled thread

how to create (open) a dialog box

Back to article view | Back to comp.lang.php

Contents

  how to create (open) a dialog box Andre <pas@pourmois.be> - 2011-08-14 10:43 +0000
    Re: how to create (open) a dialog box Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-14 09:13 -0400
    Re: how to create (open) a dialog box Robert Hairgrove <nobody@hogwash.com> - 2011-08-14 18:18 +0200
      Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-14 20:59 +0200
        Re: how to create (open) a dialog box Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-15 08:48 -0400
          Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-15 18:12 +0100
            Re: how to create (open) a dialog box Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-15 13:31 -0400
              Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-15 19:13 +0100
          Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-15 21:07 +0200
            Re: how to create (open) a dialog box Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-15 17:19 -0400
              Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-16 18:47 +0200
                Re: how to create (open) a dialog box Jerry Stuckle <jstucklex@attglobal.net> - 2011-08-16 19:47 -0400
    Re: how to create (open) a dialog box Andre <pas@pourmois.be> - 2011-08-15 12:39 +0000
      Re: how to create (open) a dialog box A.Reader <anonymously@example.com> - 2011-08-15 14:18 -0400
        Re: how to create (open) a dialog box sheldonlg <sheldonlg@thevillages.net> - 2011-08-15 20:50 -0400
          Re: how to create (open) a dialog box Robert Hairgrove <nobody@hogwash.com> - 2011-08-16 08:21 +0200
            Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-16 19:03 +0200
              Re: how to create (open) a dialog box sheldonlg <sheldonlg@thevillages.net> - 2011-08-16 16:02 -0400
                Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-16 21:13 +0100
                  Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-16 23:16 +0200
                    Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-16 22:25 +0100
                      Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-17 20:31 +0200
                        Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-17 21:50 +0100
                          Re: how to create (open) a dialog box sheldonlg <sheldonlg@thevillages.net> - 2011-08-17 21:06 -0400
                            Re: how to create (open) a dialog box Michael Fesser <netizen@gmx.de> - 2011-08-18 17:13 +0200
                              Re: how to create (open) a dialog box Tim Streater <timstreater@greenbee.net> - 2011-08-18 18:37 +0100
                Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-16 23:11 +0200
                  Re: how to create (open) a dialog box Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-16 23:15 +0200

Page 2 of 2 — ← Prev page 1 [2]

#2855

In article <4033706.4JQzZI6eRS@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:
> 
> > sheldonlg <sheldonlg@thevillages.net> wrote:
> >> 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.
> > 
> > Yes. In my app I never submit any forms at all. Everything happens via
> > onclick events and ajax.
> 
> IOW, your app cannot be used without client-side scripting, as "ajax" 
> requires that.  With few exceptions, I would consider that bad software 
> design.

So what should I replace my 15000 lines of javaScript with then? Magic?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#2865

Tim Streater wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Tim Streater wrote:
>> > sheldonlg <sheldonlg@thevillages.net> wrote:
>> >> 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.
>> > 
>> > Yes. In my app I never submit any forms at all. Everything happens via
>> > onclick events and ajax.
>> IOW, your app cannot be used without client-side scripting, as "ajax"
>> requires that.  With few exceptions, I would consider that bad software
>> design.
> 
> So what should I replace my 15000 lines of javaScript with then? Magic?

You should rewrite your application so that it works with and without 
client-side scripting.  That design approach is called graceful degradation. 
It is not hard to do (see my example) if you start from the premise that 
client-side scripting is not available, instead of the opposite.  And 15000 
LOCs is probably too much client-side script code.  You might want to ask 
questions about parts of your code where it is on-topic.
 

PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#2866

In article <8880046.SEqChMirdb@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:
> 
> > Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> >> Tim Streater wrote:
> >> > sheldonlg <sheldonlg@thevillages.net> wrote:
> >> >> 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.
> >> > 
> >> > Yes. In my app I never submit any forms at all. Everything happens via
> >> > onclick events and ajax.
> >> IOW, your app cannot be used without client-side scripting, as "ajax"
> >> requires that.  With few exceptions, I would consider that bad software
> >> design.
> > 
> > So what should I replace my 15000 lines of javaScript with then? Magic?
> 
> You should rewrite your application so that it works with and without 
> client-side scripting.

No I don't. This app requires JavaScript to be enabled in order to run. 
Y'know, like most applications have a minimum configuration requirement? 
Well this is one of those.

> That design approach is called graceful degradation.

So apps should be designed so they still run if someone removes the 
processor from the computer? Were you always this mad?

> It is not hard to do (see my example) if you start from the premise that 
> client-side scripting is not available, instead of the opposite.  And 15000 
> LOCs is probably too much client-side script code.  You might want to ask 
> questions about parts of your code where it is on-topic.

I don't need to ask any questions at this time about my code, you rude 
bastard. I expect it could be done with little or no JavaScript, but it 
would be piss-poor experience for the user.

Now fuck off and take your shitty useless advice with you.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#2868

On 8/17/2011 4:50 PM, Tim Streater wrote:
> In article <8880046.SEqChMirdb@PointedEars.de>,
> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

>> That design approach is called graceful degradation.
>
> So apps should be designed so they still run if someone removes the
> processor from the computer? Were you always this mad?

His basis is that you want to reach as many people as possible and a 
certain percentage of them will turn off javascript.  Now I ask, what is 
that percentage?  If you are selling something, how much added revenue 
would be gained from having that percentage reach you versus the added 
costs for writing AND DEBUGGING AND MAINTAINING a dual system.

Putting into google "percentage of people who turn off javascript" we 
get from the very first link:

"According to data collected in 2007, 1.04% have it disabled in the EU, 
and 3.05% have it disabled in the US."

So, between one and three percent turn off javascript.  I call that no 
BFD.  I'll put a message in the script for the "page" that javascript is 
required for this "page".  It just doesn't pass the cost/benefit analysis.

(I, myself, am in the 97% of the US users).

-- 
Shelly

[toc] | [prev] | [next] | [standalone]

#2872

.oO(sheldonlg)

>Putting into google "percentage of people who turn off javascript" we 
>get from the very first link:
>
>"According to data collected in 2007, 1.04% have it disabled in the EU, 
>and 3.05% have it disabled in the US."

Such global "statistics" are completely useless. What matters are your
own stats from your own website, nothing else.

>So, between one and three percent turn off javascript.

On one of the sites I maintan it's 8.5% for the current month and 12.6%
for the entire year until today. We're in the EU.

Micha

-- 
http://mfesser.de/blickwinkel

[toc] | [prev] | [next] | [standalone]

#2877

In article <klaq47duigbittnsusdng3cep8625hl7np@mfesser.de>,
 Michael Fesser <netizen@gmx.de> wrote:

> .oO(sheldonlg)
> 
> >Putting into google "percentage of people who turn off javascript" we 
> >get from the very first link:
> >
> >"According to data collected in 2007, 1.04% have it disabled in the EU, 
> >and 3.05% have it disabled in the US."
> 
> Such global "statistics" are completely useless. What matters are your
> own stats from your own website, nothing else.

In my case, there is no "website", and so the stats are meaningless 
anyway, although I appreciate what Shelly was doing. In my case, a 
browser with JavaScript (I choose to use Safari), apache, a number of 
PHP scripts, and SQLite are the components of my application. These all 
come free under OS X, and since its the only platform I have and have an 
interest in, that is the platform it runs on. To run it, the user 
double-clicks an application icon just as they do with any app.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#2850

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

[toc] | [prev] | [next] | [standalone]

#2851

Thomas 'PointedEars' Lahn wrote:

> 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.
                                      ^^^^^^^^^^^^^^^^^^^^^^
Err, that's _client-side (traditional) solution_ (window.confirm), of 
course.

-- 
PointedEars

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web