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

Groups > comp.lang.javascript > #12896 > unrolled thread

Enhanced prompt

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

Contents

  Enhanced prompt Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-03-19 13:53 +0100
    Re: Enhanced prompt Scott Sauyet <scott.sauyet@gmail.com> - 2012-03-19 06:45 -0700
      Re: Enhanced prompt Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-03-19 17:54 +0100
        Re: Enhanced prompt Scott Sauyet <scott.sauyet@gmail.com> - 2012-03-19 10:53 -0700
          Re: Enhanced prompt Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-03-20 19:45 +0100
    Re: Enhanced prompt Martin Honnen <mahotrash@yahoo.de> - 2012-03-19 18:07 +0100
      Re: Enhanced prompt Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-03-20 19:46 +0100

#12896 — Enhanced prompt

I have a requirement here that is very similar to
window.prompt(...), but slightly exceeds it. Let's assume the
requirement is that the prompt text contain a clickable link.

I have tried to write an enhancedPrompt(...) function in
DOM/JavaScript, but so far failed, because this function would
have to wait for the user to click on the [OK] or [Cancel]
button, then return to the calling routine.

So far it seems to me that this cannot be programmed in
DOM/JavaScript. I may have to split the calling routine into a
first part that creates the dialog (for example, an absolutely
positioned element with a higher z-index) and a second part that
gets called when the user clicks a button.

I can do that, but I would still like to know whether I am
overlooking something here. It looks like a somewhat painful
limitation of the DOM/JavaScript combo.

All good thoughts are welcome.

Hans-Georg

[toc] | [next] | [standalone]

#12898

Hans-Georg Michna wrote:
> [ ... ]
> I have tried to write an enhancedPrompt(...) function in
> DOM/JavaScript, but so far failed, because this function would
> have to wait for the user to click on the [OK] or [Cancel]
> button, then return to the calling routine.
>
> So far it seems to me that this cannot be programmed in
> DOM/JavaScript. I may have to split the calling routine into a
> first part that creates the dialog (for example, an absolutely
> positioned element with a higher z-index) and a second part that
> gets called when the user clicks a button.
>
> I can do that, but I would still like to know whether I am
> overlooking something here. It looks like a somewhat painful
> limitation of the DOM/JavaScript combo.

I don't think you're missing something.  ES3/5 does not support
continuations.  There is still talk of it for the next version, I
believe, but I have not been following it too closely.  Somehow or
another for the moment, you will need to use a callback to handle
this.

That said, if you used one of the Promises APIs [1], you might find it
easier to work with some of these ugly callbacks.

  -- Scott

[1] http://wiki.commonjs.org/wiki/Promises

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

#12901

On Mon, 19 Mar 2012 06:45:56 -0700 (PDT), Scott Sauyet wrote:

>Hans-Georg Michna wrote:
>> [ ... ]
>> I have tried to write an enhancedPrompt(...) function in
>> DOM/JavaScript, but so far failed, because this function would
>> have to wait for the user to click on the [OK] or [Cancel]
>> button, then return to the calling routine.
>>
>> So far it seems to me that this cannot be programmed in
>> DOM/JavaScript. I may have to split the calling routine into a
>> first part that creates the dialog (for example, an absolutely
>> positioned element with a higher z-index) and a second part that
>> gets called when the user clicks a button.
>>
>> I can do that, but I would still like to know whether I am
>> overlooking something here. It looks like a somewhat painful
>> limitation of the DOM/JavaScript combo.

>I don't think you're missing something.  ES3/5 does not support
>continuations.  There is still talk of it for the next version, I
>believe, but I have not been following it too closely.  Somehow or
>another for the moment, you will need to use a callback to handle
>this.
>
>That said, if you used one of the Promises APIs [1], you might find it
>easier to work with some of these ugly callbacks.
>
>  -- Scott
>
>[1] http://wiki.commonjs.org/wiki/Promises

Thanks for confirming this.

It is painful. Imagine a function calling chain, in which the
last one contains a prompt that you have to replace with a
self-made one. Or a loop with a prompt. With a callback function
you lose the entire context.

But I guess you know this. I will probably have to go that way,
whether I like it or not. It seems to be one of the few weak
spots of the DOM/JavaScript combo.

Hans-Georg

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

#12904

Hans-Georg Michna wrote:
> Scott Sauyet wrote:
>> Hans-Georg Michna wrote:

>>> [writing an enhancedPrompt(...) function in JS ]
>>> So far it seems to me that this cannot be programmed in
>>> DOM/JavaScript. I may have to split the calling routine into a
>>> first part that creates the dialog (for example, an absolutely
>>> positioned element with a higher z-index) and a second part that

>> I don't think you're missing something.  ES3/5 does not support
>> continuations.  There is still talk of it for the next version, I
>> believe, but I have not been following it too closely.  Somehow or
>> another for the moment, you will need to use a callback to handle
>> this.

> It is painful. Imagine a function calling chain, in which the
> last one contains a prompt that you have to replace with a
> self-made one. Or a loop with a prompt. With a callback function
> you lose the entire context.

Yes, any time you need to convert synchronous code to asynchronous
techniques, it's ugly, and these changes seem to be viral.

Often the resulting code, if done well, is no less readable or
maintainable than the original, though.

If the callback function is created in your original context, it
should close over the variables currently in scope, so this might not
be as big a deal as you fear.  But it's non-trivial, and can involve
significant rework.

> But I guess you know this. I will probably have to go that way
> whether I like it or not. It seems to be one of the few weak
> spots of the DOM/JavaScript combo.

It is a weak spot.  But there are similar concerns in many GUI
environments.  In many environments, this is simply handled with event
loops.  You can do that here or use some sort of Publish/Subscribe
technique, or the Promises I mentioned earlier.  Or you can hand-code
however many levels of callbacks you need.  None is really ideal when
what you really want is simple continuations that can pick up
execution exactly where you left off with the current state updated in
some minimal manner.  You won't get that before ES.next, if even then.

Sorry,

  -- Scott

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

#12932

On Mon, 19 Mar 2012 10:53:45 -0700 (PDT), Scott Sauyet wrote:

>If the callback function is created in your original context, it
>should close over the variables currently in scope, so this might not
>be as big a deal as you fear.  But it's non-trivial, and can involve
>significant rework.

Yes, I thought about that. If I have to do it, I will first try
to go that way.

Hans-Georg

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

#12903

Hans-Georg Michna wrote:
> I have a requirement here that is very similar to
> window.prompt(...), but slightly exceeds it. Let's assume the
> requirement is that the prompt text contain a clickable link.

Which browsers do you target? With 
https://developer.mozilla.org/en/DOM/window.showModalDialog you can 
create a blocking, modal dialog where the contents of the window is 
specified with a HTML document so a link is no problem and where you can 
return a value to the calling code.


-- 

	Martin Honnen --- MVP Data Platform Development
	http://msmvps.com/blogs/martin_honnen/

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

#12933

On Mon, 19 Mar 2012 18:07:18 +0100, Martin Honnen wrote:

>Hans-Georg Michna wrote:

>> I have a requirement here that is very similar to
>> window.prompt(...), but slightly exceeds it. Let's assume the
>> requirement is that the prompt text contain a clickable link.

>Which browsers do you target? With 
>https://developer.mozilla.org/en/DOM/window.showModalDialog you can 
>create a blocking, modal dialog where the contents of the window is 
>specified with a HTML document so a link is no problem and where you can 
>return a value to the calling code.

Nice, and I was not aware of it. Thanks for the info!

But I have to cater to as many browsers as possible, so this
will not work for me.

Hans-Georg

[toc] | [prev] | [standalone]

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

csiph-web