Jump to content

NotionCommotion

Members
  • Posts

    2,446
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by NotionCommotion

  1. I understand that I provided very little information and can not expect much comments. I am in the discovery phase, and have very little information to give. I am building a PHP client application which bidirectionally communicates to a remote server using ReactPHP. This part is working. Now, it needs to bidirectionally communicate to a C++ application residing on the same machine. Messages from the PHP client app need to somehow be transmitted to the C++ app, and the C++ app needs to somehow transmit messages to the PHP app. The C++ author recommends using Unix domain sockets along with JSON-RPC where the C++ app is a client and the PHP app is a server. I do not have enough knowledge or expertise on this subject to question doing differently. What information would be needed to agree with this recommend or recommend doing differently? Thanks
  2. Thanks Jacques1, I had done so, and thought that http://php.net/manual/en/function.stream-socket-server.php is the right direction. They give examples of Internet Domain sockets (AF_INET) such as TCP and UDP, but not Unix domain sockets. For unix sockets, I will try using unix:///tmp/pa. Am I on the right path? Any other words of wisdom? Thanks
  3. Is it possible to use PHP to create a unix domain socket to a file path such as /tmp/pa and listen for connections? If so, where should I start? Can a library such as reactphp be used? Thanks
  4. Agree they should be included where required. They appear to be only required for very few applications. My new position is to not included them where they are not required but optional. <?php function foo($arr) { if($arr) { foreach ($arr->x as $value) { $x=$bla->{$value->bla}; } switch($bbb){ case asd: } } else { while($arr->x) { } } }
  5. Do I understand all your positions correctly? Benanamen says it is optional, however, sometimes advantageous not to include. ginerjm says to include them all the time in case the code is later changed. mac_gyver says not to include them. EDIT. I went searching my code for where I did use them after curly brackets, and came across this. Not the same context of my original question, but thought I would post this just in case someone in the future views this post. $arr[$prop]=$this->{$prop}; //semicolon is required
  6. For instance, are the last three semicolons required? Whether are not, is it best practice to or not to include? $c['errorHandler'] = function($c){ return function ($request, $response, $exception) use ($c){ if ($exception instanceof NotFoundException){ return $c['notFoundHandler']($request, $response); } else { return $c['response']->withStatus(500) ->withHeader('Content-type: text/html') ->write('Generic error'); }; }; }; Also, from a formatting perspective, what is the best practice where to include them (i.e. on the same line, or the following line)? ->write('Generic error'); ->write('Generic error') ;
  7. Maybe easier than I thought. I "think" the header defaults to text/html, and if not, expect there is a way to make it. Not sure that this is the "Slim" way of doing it, but it should work fine. <?php namespace RestApp; class MissingPage { public function __call($method, $args) { return ['Page not found',404]; } }
  8. The following script supports the following paths, and any other path will return a 404 response: /source/type1/subtype1 /source/type1/subtype2 /source/type2/subtype1 /source/type2/subtype2 <?php use \Psr\Http\Message\ServerRequestInterface as Request; use \Psr\Http\Message\ResponseInterface as Response; require __DIR__.'/../vendor/autoload.php'; $c = new \Slim\Container($settings); $c['SourceFactory'] = function ($c) { return new \RestApp\SourceFactory(); }; $c['notFoundHandler'] = function ($c) { return function ($request, $response) use ($c) { return $c['response'] ->withStatus(404) ->withHeader('Content-Type', 'text/html') ->write('Page not found'); }; }; $app = new \Slim\App($c); $app->post('/sources/{type: type1|type2}/{subtype: subtype1|subtype2}', function (Request $request, Response $response, $args) { $rs=$this->get('SourceFactory')->getByType($args['type'],$args['subtype'])->add($request->getParsedBody()); return $response->withJson($rs[0],$rs[1]); }); $app->run(); Instead of putting the logic in the slim path definitions (i.e. /sources/{type: type1|type2}/{subtype: subtype1|subtype2}), I would like to put the logic in the getByType() method, and have my slim path simply be /sources/{type}/{subtype}. To do so, I envision getByType() returning something like the following if type and subtype are not what they should be. <?php namespace RestApp; class MissingPage { public function __call($method, $args) { echo "This page is missing"; } } Okay, this should work. But I don't want it to just return This page is missing, but return the same content and headers should a path not have been supported such as /invalidPath/foo/bar. Hope what I am asking makes sense Any recommendations? Thanks
  9. "try promise"? Normally, I would assume this is a typo, but not going to assume anything on this topic. "behavior"? As in methods? "can do X" as in can do arithmetic rather than "is a Y" as in is a calculator? For me, this seems to be the norm and not the exception. Shouldn't we always attempt to centralize script instead of duplicating it? I've heard others voice that abstract classes should rarely be used and am questioning whether I am using them too often.
  10. Before learning about interfaces, I would often use abstract classes: abstract class MyAbstractClass { abstract public function someMethodToOverride(); public function availableMethod() { //code common to all extender classes which does not need to be duplicated... } } class MyFirstClass extends MyAbstractClass { public function someMethodToOverride() { //code unique to each extending class... } } class MySecondClass extends MyAbstractClass { public function someMethodToOverride() { //code unique to each extending class... } } Now trying to more often use interfaces. It is my understanding that the interface is primarily a guide to the user of the class, while abstract classes are to help the classes author create the class. Does it make sense to use both at the same time? For the above, does it make more sense to add someMethodToOverride() and availableMethod() to MyAbstractClass's interface? Or maybe get rid of MyAbstractClass's abstract method someMethodToOverride(), and just but this method in MyFirstClass's interface?
  11. Needs a little work, but the following should get you going in the right direction. CLIENT SIDE: <a href="?coupon_code=****-6dcf-****-4d05-bd68-****-****-****>click me</a> SERVER SIDE: $coupon_code=$_GET['coupon_code'];
  12. Try adding the following: ini_set('post_max_size', '2G');
  13. Add this to your script: echo('$_REQUEST<pre>'.print_r($_REQUEST,1).'</pre>'); echo('$_GET<pre>'.print_r($_GET,1).'</pre>'); echo('$_POST<pre>'.print_r($_POST,1).'</pre>'); var_dump() provides more info, but the above is all you need and will be simpler to read.
  14. The PHP app is storing the data in a local database should the network to the server be down (which is a WAN and not a LAN as I showed it). Whatever capabilities that are desired. It hasn't been built, but a spec has been created. I am sure it "could" do HTTP requests. My concern is I wish to personally do as much implementation as possible, but do not know C++, therefore am trying to limit the functionality implemented in it to that described in my initial post. Maybe this is not a good idea? Great question. Because as far as I know, the library I am using hasn't been ported to PHP. It is described https://sourceforge.net/projects/bacnet/ and http://bacnet.sourceforge.net/.
  15. I have the following. ReactPHP Server needs to send data to C++ App to tell it what data to get from PLCs. C++ App needs to send PLC data to ReactPHP Server. Should C++ App be a client or server to the PHP Application residing on the same machine? C++ programmer is saying C++ should be a client. This would mean adding a local ReactPHP Server to the machine with the ReactPHP Client, right? How would this data be delivered to the ReactPHP Client (and then to the remote ReactPHP Server)?
  16. Agree, not how they are implemented. As far as by whom, almost every example I have looked at does so (Symphony, Slim, ReactPHP, Pimple, etc as well as http://php.net/manual/en/language.oop5.interfaces.php). Are they all wrong, or am I missing something?
  17. Thanks requinix, I agree with the consistency part. I know in the past, I started one approach (curly brackets is a classic example) , later second guessed myself, and flipped, and I don't wish to do so again. I feel I* is nice as it is shorter, but also feel *Interface is nice as it matches many open-source projects and files are better listed in alphabetical order. Maybe I will flip a coin!
  18. And you use this one? Do you not bother making the name suggest the class which implements it?
  19. https://forums.phpfreaks.com/topic/302974-oop-abstract-classes/ and http://forums.devshed.com/php-development-5/questioning-abstract-classes-vs-regular-classes-929822.html inspired me to more often use interfaces. I would like to start off with a good naming and directory strategy. Looks like two common naming approaches are appending "Interface" after the class name and prepending a capital "I" before the class name. For instance, if my class name was BinaryMathOperator, it might be BinaryMathOperatorInterface or IBinaryMathOperator. And maybe other standards? I've also seen including the interface file in the same directory as the class, and also creating a separate directory for all? the interfaces. A little off topic, but got me thinking... Is it typical to ever have more than one class implement the same interface (or some multiple interfaces)? This will have some bearing on the naming strategy. For one just starting off, what would you recommend?
  20. I like "Kicken's guide to digging through code"! I can follow along, but find it a little difficult to determine when not to go down a rabbit hole when doing it by myself. I guess I need to just dig some more and get more practice. Thanks for the thorough examples!
  21. I will be building a SOAP client using PHP and it will read data only. I currently do not have access to the SOAP server which I will need to query, but want to get started now. Anyone know of a generic publically available SOAP server which I can play with? EDIT. Maybe http://graphical.weather.gov/xml/ for NOAA's SOAP server? EDIT. Maybe https://getsandbox.com/dashboard? I have some experience with Swagger, but thought it was only REST and not SOAP. Or maybe best to just build a SOAP server using PHP? Thanks
  22. Okay, Server has two emits. I expected the connection event which returns the $client. Evidently, there is also an error event on $socket which I suppose I should listen for. $this->emit('connection', array($client)); $that->emit('error', array(new \RuntimeException('Error accepting new connection'))); Okay, I know $stream is of class type \React\Socket\ConnectionInterface because of this line, right? $socket->on('connection', function (\React\Socket\ConnectionInterface $stream){ So, I look there and see... interface ConnectionInterface extends DuplexStreamInterface And so on.. interface DuplexStreamInterface extends ReadableStreamInterface, WritableStreamInterface But ReadableStreamInterface and WritableStreamInterface only have the following two emits... $this->emit('end', array($this)); $this->emit('close', array($this)); I see my close emit (and end whatever that is), but no data or error emit. Where am I going wrong?
  23. The following is on the close event instead of the error event. What am I looking for? /var/www/datalogger/src/Server.php:98: array(1) { [0] => class React\Socket\Connection#43 ( { public $bufferSize => int(65536) public $stream => resource(68) of type (stream) protected $readable => bool(false) protected $writable => bool(false) protected $closing => bool(false) protected $loop => class React\EventLoop\StreamSelectLoop#30 ( { private $nextTickQueue => class React\EventLoop\Tick\NextTickQueue#31 (2) { ... } private $futureTickQueue => class React\EventLoop\Tick\FutureTickQueue#33 (2) { ... } private $timers => class React\EventLoop\Timer\Timers#35 (3) { ... } private $readStreams => array(2) { ... } private $readListeners => array(2) { ... } private $writeStreams => array(0) { ... } private $writeListeners => array(0) { ... } private $running => bool(true) } protected $buffer => class React\Stream\Buffer#44 (7) { public $stream => resource(68) of type (stream) public $listening => bool(false) public $softLimit => int(65536) private $writable => bool(false) private $loop => class React\EventLoop\StreamSelectLoop#30 ( { ... } private $data => string(0) "" protected $listeners => array(3) { ... } } protected $listeners => array(3) { 'data' => array(1) { ... } 'close' => array(1) { ... } 'error' => array(1) { ... } } } }
  24. I didn't expect that. Do all events such as $stream->on('whatever', function($exception, $stream, $andMore?) {/*bla bla bla*/}); receive potentially more than one argument? How do you know? [Michael@devserver www]$ grep -rn '/var/www/react' -e "->emit(" /var/www/react/src/JSONStream.php:40: $this->emit('data', [$data]); /var/www/react/vendor/react/socket/src/Server.php:44: $that->emit('error', array(new \RuntimeException('Error accepting new connection'))); /var/www/react/vendor/react/socket/src/Server.php:58: $this->emit('connection', array($client)); /var/www/react/vendor/react/socket/src/SecureServer.php:63: $that->emit('error', array($error)); /var/www/react/vendor/react/socket/src/SecureServer.php:93: $that->emit('connection', array($conn)); /var/www/react/vendor/react/socket/src/SecureServer.php:96: $that->emit('error', array($error)); /var/www/react/vendor/react/stream/src/WritableStream.php:36: $this->emit('end', array($this)); /var/www/react/vendor/react/stream/src/WritableStream.php:37: $this->emit('close', array($this)); /var/www/react/vendor/react/stream/src/ThroughStream.php:22: $this->readable->emit('data', array($this->filter($data), $this)); /var/www/react/vendor/react/stream/src/ThroughStream.php:28: $this->readable->emit('data', array($this->filter($data), $this)); /var/www/react/vendor/react/stream/src/Stream.php:61: $that->emit('error', array($error, $that)); /var/www/react/vendor/react/stream/src/Stream.php:66: $that->emit('drain', array($that)); /var/www/react/vendor/react/stream/src/Stream.php:114: $this->emit('end', array($this)); /var/www/react/vendor/react/stream/src/Stream.php:115: $this->emit('close', array($this)); /var/www/react/vendor/react/stream/src/Stream.php:164: $this->emit('error', array(new \RuntimeException('Unable to read from stream: ' . $error->getMessage(), 0, $error), $this)); /var/www/react/vendor/react/stream/src/Stream.php:170: $this->emit('data', array($data, $this)); /var/www/react/vendor/react/stream/src/Util.php:15: $dest->emit('pipe', array($source)); /var/www/react/vendor/react/stream/src/Util.php:41: $target->emit($event, func_get_args()); /var/www/react/vendor/react/stream/src/Buffer.php:71: $this->emit('close', array($this)); /var/www/react/vendor/react/stream/src/Buffer.php:110: $this->emit('error', array(new \RuntimeException('Unable to write to stream: ' . $error->getMessage(), 0, $error), $this)); /var/www/react/vendor/react/stream/src/Buffer.php:120: $this->emit('drain', array($this)); /var/www/react/vendor/react/stream/src/Buffer.php:128: $this->emit('full-drain', array($this)); /var/www/react/vendor/react/stream/src/ReadableStream.php:38: $this->emit('end', array($this)); /var/www/react/vendor/react/stream/src/ReadableStream.php:39: $this->emit('close', array($this)); /var/www/react/vendor/react/stream/tests/StreamTest.php:160: $buffer->emit('drain'); /var/www/react/vendor/react/stream/tests/StreamTest.php:161: $buffer->emit('error', array(new \RuntimeException('Whoops'))); /var/www/react/vendor/react/stream/tests/ThroughStreamTest.php:30: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:93: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:94: $writable->emit('drain'); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:111: $input->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:135: $input->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:136: $writable->emit('drain'); /var/www/react/vendor/react/stream/tests/CompositeStreamTest.php:153: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/WritableStreamTest.php:20: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/BufferedSinkTest.php:106: $sink->emit('error', array(new \Exception('Shit happens'))); /var/www/react/vendor/react/stream/tests/BufferedSinkTest.php:150: $readable->emit('error', array(new \Exception('Shit happens'))); /var/www/react/vendor/react/stream/tests/BufferedSinkTest.php:165: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/BufferedSinkTest.php:166: $readable->emit('data', array('bar')); /var/www/react/vendor/react/stream/tests/BufferedSinkTest.php:180: $readable->emit('data', array('foo')); /var/www/react/vendor/react/stream/tests/Stub/ReadableStreamStub.php:23: $this->emit('data', array($data)); /var/www/react/vendor/react/stream/tests/Stub/ReadableStreamStub.php:29: $this->emit('error', array($error)); /var/www/react/vendor/react/stream/tests/Stub/ReadableStreamStub.php:35: $this->emit('end', array()); /var/www/react/vendor/react/stream/tests/Stub/ReadableStreamStub.php:52: $this->emit('close'); /var/www/react/vendor/react/stream/tests/UtilTest.php:131: $source->emit('data', array('hello')); /var/www/react/vendor/react/stream/tests/UtilTest.php:132: $source->emit('foo', array('bar')); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:60: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:64: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:77: $this->emitter->emit('foo', array('a', 'b')); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:91: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:108: $this->emitter->emit('foo', ['bar']); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:126: $this->emitter->emit('foo', ['bar', 'baz']); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:132: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:133: $this->emitter->emit('foo', ['bar']); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:134: $this->emitter->emit('foo', ['bar', 'baz']); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:150: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:166: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:182: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:197: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:212: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:231: $this->emitter->emit('foo'); /var/www/react/vendor/evenement/evenement/tests/Evenement/Tests/EventEmitterTest.php:232: $this->emitter->emit('bar'); /var/www/react/vendor/evenement/evenement/README.md:73:$emitter->emit('user.created', array($user)); [Michael@devserver www]$
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.