IMHO, having a template work with a file, or a string, or a stream - is implementation detail. Having a separate component responsible for rendering, e.g. a rendering engine, is also an implementation detail. All this can be DI'd into a template, which itself knows how to render itself, given a context. It may use an engine, or do the rendering itself, e.g. use a `printf()`-style format string. The template source may be a string, instead of a file; same example applies. What's important, IMHO, is that, given a context, it can produce output, regardless of how that is done. As for context, `ContainerInterface` is an already existing standard that allows retrieval of arbitrary data by key. By having a `ContextInterface` such as yours, you are requiring the implementation to be compatible with a new standard, and be aware of the method of sourcing the template itself. Also, IMO it's not important what data the context provides, as long as it provides all the data that the template requires.
I feel like this approach is very non-SOLID, because the interfaces are not segregated, domain-specific instead of interoperable, and SoC is not maintained. On Tuesday, September 26, 2017 at 3:55:03 PM UTC+2, David Lundgren wrote: > > > On Tuesday, September 26, 2017 at 4:17:38 AM UTC-5, Xedin Unknown wrote: >> >> `Template#file()` seems extra to me, because it breaks ISP. >> > > This method is used by the Context to be able to determine whether the > data it contains actually applies to the template. > > >> `Engine` also looks very non-segregated to me. >> > > Engine is basically what ties everything together to give a single entry > point in to the the rendering system. This would effectively be the > Renderer. > > >> Could you elaborate on the usage of `Context`? I couldn't understand how >> it could be used. >> > > You used DataObject in an earlier email to describe the same thing, > Context's hold the data that the templates will use. Context's in this case > have additional functionality in that they can conditionally provide their > data to the template based off of the templates name. This gives the > ability to globally create data, and have a specific only get that data. > > >> I use an interop context in the form of `ContainerInterface`. >> > > I didn't want to tie any other interfaces in to this system if it could > be avoided, preferring to be self-contained. I feel like requiring a > container, or logger, should be a decision that the frameworks should be > making. > > It seems like we may already be close to how it should work, mainly naming > differences, and a few extraneous methods/classes. > > My idea when originally building this spec was to do the smallest possible > interface for a rendering system. I would then pitch this to the framework > authors, and hopefully gain traction from them to support the interop > project, before coming here. This would let us easily swap out rendering > systems if they adopted this interface. > > As I mentioned previously, here are the code examples I've written > > - Phrender: https://github.com/dlundgren/phrender > - Bridge Proof of Concept: > https://github.com/dlundgren/output-interop-poc > > > Dave > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/e7e3d5b6-2107-49d3-9ea0-b36f02326eb6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
