>
> Having given it quite a bit of thought, and passing this by @mecha, I
> would like to provide some feedback with regard to working with streams. As
> a disclaimer, I would like to mention that I do not make solving a specific
> problem the target of this standard; however, I do want to make sure that
> specific problems _can_ be solved. I believe streaming to be one of them,
> and I guess @David would agree with me.
>
I don't agree. There's no need for one solution fit them all. Always having
to return an object might be bad for the developer experience. On the other
hand, it's mostly some library that implements the interface, so it might
not really matter.
> I really dig the need for streaming, as the rendering output can become
> really really huge. It may certainly be preferable to "cache" the output to
> disk, and then send it to the server in a more appropriate manner. As an
> example, imagine that your software needs to print a very large
> confirmation document, such as a receipt, which contains a lot of detail
> about every item. Streaming would be extremely useful here, because it
> allows you to occupy only a small amount of memory at any point in time,
> while still handling the rendering like a boss using the same algorithm.
> Duh. Cool.
>
But not worth the effort in 99% of all cases.
> The problem is that, because the template is responsible for rendering,
> and the return value (stream) is responsible for retrieving the value in
> chunks (they are two separate things), the stream would need to be
> buffered. Buffered streams work by having something write to the stream at
> the same time as something else reads from it. And this can work really
> well in some cases. However, it only works in cases when rendering is done
> in steps. When you are rendering PHTML or Mustache, there are no steps,
> e.g. you cannot tell the engine to render only the first e.g. 256 bytes of
> the _template_. You can only buffer output in chunks, and this can easily
> be done by using the 2 parameters of `ob_start()`, e.g.
> `ob_start('function_that_writes_to_disk', 256)`. This means that the events
> are coming from the stream, instead of the consumer of the stream. This
> conflicts with the whole philosophy of the stream standard, whereby it
> provides the consumer a way to "request" a number of bytes from it. In this
> case, a buffered stream would still have to contain the complete output at
> some point. A sub-optimal solution to that could be using the `php://temp`
> stream, which would start writing "overflowing" bytes to disk. However,
> this is not the best solution, since it will make the application slower,
> and most importantly ignores the advantage of the output callback, which
> _should_ be used for writing to the destination.
>
> The solution, in my opinion, lies in the assumption that a stream is
> something that `TemplateInterface#render()` should _return_. If, instead of
> returning a readable stream, `render()` could _accept_ a *writable* stream,
> the problem disappears on its own.
>
> $sourcePath = 'my-template.php';
> $destinationPath = 'my-template.cache';
> $destinationStream = new WritableFileStream($destinationPath);
> $template = new PhpTemplate($sourcePath);
> $template->render($context = null, $destinationStream);
>
> So, here we have a signature which suggests that in certain cases, a
> second parameter should be accepted by the `render()` method. I would say
> that
>
>> If the `$stream` parameter is provided, output will be written to it, and
>> the returned value will evaluate to an empty string.
>
>
Sorry, but what? There should be a defined return type that's not changing
based on the parameters passed. Returning a readable stream is just fine,
you just need to figure out how to handle backpressure. You might want to
have a look at https://amphp.org/byte-stream/, which is async, but the same
thing applies to sync, just that you can skip the promises.
Regards, Niklas
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/98327010-b6eb-4727-a83a-f4fc83fb8c63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
