Req #74966 [Com]: No good way to read logical keystrokes & flavoring

From: 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

« previous php.bugs (#210236) next »