Req #74966 [Com]: No good way to read logical keystrokes & flavoring
| From: | spam2 at rhsoft dot net | Date: | Sun, 23 Jul 2017 12:49:20 +0000 |
| Subject: | Req #74966 [Com]: No good way to read logical keystrokes & flavoring | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210236@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=74966&edit=1
ID: 74966
Comment by: spam2 at rhsoft dot net
Reported by: scratch65535 at att dot net
Summary: No good way to read logical keystrokes & flavoring
Status: Not a bug
Type: Feature/Change Request
Package: Unknown/Other Function
Operating System: irrelevant
PHP Version: 7.1.7
Block user comment: N
Private report: N
New Comment:
stop it - you don't understand client/server architecture and PHP has really no business in
listening to events since there is no thinkable glue between client - server - php for that
or to say it in other words:there are different programming languages and when you are not capable
to figure out which part belongs to the client and which one to the server does not mean php needs
to be modified
frankly it's idiotic to even consider php listening directly to key events instead handle that
part on the client because even if it could work in theory it would be a terrible user experience
because of the introduced latency
Previous Comments:
------------------------------------------------------------------------
[2017-07-23 12:35:55] requinix@php.net
Did you seriously just invoke Godwin's Law?
There's one very basic fact here: if you are using a browser then you are not interacting with
PHP directly. That's fundamental. Just as I would not expect Chrome to know my keystrokes when
I'm using Netbeans, I would not expect PHP to know my keystrokes when I'm using Chrome.
Even if that webpage on Chrome was rendered by PHP. Even if both are running on the same machine.
If you had used Node.js then you would know the same thing applies over there. This isn't a
matter of PHP supporting behavior. This is a matter of the behavior not being possible in the first
place - and if you were at all familiar with how the internet works (and with your
"explanation" of how PHP "talks" to the browser, I doubt it) then you would
understand why this is not possible.
And this is all completely separate from the argument that the UI layer should be what's
responsible for the user interface (literally), not the backend.
PHP cannot monitor for events on a web client. Nor can Node.js, or C#.NET, or Ruby, or Python, or
any other web-capable language. Go anywhere else and they will tell you the same thing. But you know
what they will tell you? Same thing I said: Javascript can do it. So use that.
------------------------------------------------------------------------
[2017-07-23 12:11:38] scratch65535 at att dot net
Oh c'mon - that's shorthand. Php does "talk to the browser", if there's a
browser involved --it's called "echo", and it writes to port 80 on the client machine
using http protocol or to 443 using https, yada yada. It also listens to the browser, because
otherwise it would never get anything in the GET and PUT buffers. Is it really fruitful to quibble
about the level of abstraction in the description of what's going on?
Yes, php only knows what the browser tells it. And why does the browser tell it anything? Because
some human tells it to! The php developers, being human, could insinuate some js code in a broadly
similar way to all the capitalist crap that burdens every web page to report keypress information.
Such keypress information is wanted mainly, or only, in cases where the php job is running
interactively, typically locally, and is hf-bound. That's how the editor I'm writing will
run, only I can't write it or anything similar in php because php doesn't afford the
keypress information.
Yes, I could kludge a little ajax or perhaps even websocket job to do nothing but pass keystroke
information back to the php job. But I shouldn't have to: keystroke information couldn't
be more basic. Php is no longer a tiny, bounded, special-purpose language. It's a general
language and should have a full array of general capabilities -- including the ability to get
keystrokes without everyone having to write their own routines to do the work.
Node.js is part of a movement to make php obsolete: (When I read their "one language
everywhere" goal, the first thing that popped into my mind was "Ein Volk, Ein Reich, Ein
Führer" (I was born during the Battle of Britain), and the second thing was "One Ring
to bind them all!"). I don't use node.js, but millions do. Without a full array of basic
capabilities, php is vulnerable to being pushed aside.
------------------------------------------------------------------------
[2017-07-23 06:37:28] requinix@php.net
> php already knows how to talk to a browser window
Uh, no. PHP does not "talk to" the browser. The browser sends data in a request and PHP
sends data back in the corresponding response. There's also WebSockets but that's still in
the same vein as the sending/receiving process.
PHP on a server does not monitor keyboard events on a client. It doesn't monitor typing, mouse
clicks, DOM events, browser resizing, or anything at all that happens on a client. Nor is it even
possible to do so. The only way PHP can know about that is if the browser tells it.
That is client/server 101. If I knew a good single-source explanation for it then I'd give you
that link. So instead I'm going to give you
https://www.google.com/search?q=web+client+server+architecture
But I have good news for you: if you want to watch for the user pressing keys like Ctrl or Shift *in
Javascript* then you can use the keydown/keyup events.
> I'd argue that all basic i/o functionality... belongs in php itself.
How about mouse movement? You think PHP should be responsible for that too?
You can argue all you want about what you think PHP should be responsible for, that doesn't
make it possible.
------------------------------------------------------------------------
[2017-07-22 22:33:30] scratch65535 at att dot net
Probably gui, not command line. Too hard to keep track without a stable window, and php already
knows how to talk to a browser window.
I'd argue that all basic i/o functionality (and there's surely nothing more basic than
being able to get keypress events) belongs in php itself.
------------------------------------------------------------------------
[2017-07-22 19:56:33] requinix@php.net
So... you want to make an editor in PHP? That runs from the command line, like vim or emacs? I guess
reading keyboard state is alright, but that sounds like a job for a PECL extension (if there
isn't already one that can do it).
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74966
--
Edit this bug report at https://bugs.php.net/bug.php?id=74966&edit=1