If I may give my two cents, I also find anything that has to do with files
extra.
I think a renderer is, at its very core, something that simply renders.
i.e. something which, when told to `render()`, simply renders no questions
asked.
An `EnglishAlphabetRenderer` will quite simply give
"abcdefghijklmnopqrstuvwxyz".
A template renderer is a renderer that renders a template. At this point,
it becomes important to define what a "template" is. Me and Xedin had a
not-so-short discussion about this topic when we came to create our own
standard, because it is very un-intuitive at first and may sound quite
backwards.
Definition in my own words: "*a template is a representation of a set of
possible results that can be narrowed done to a specific result if given
context.*"
To use a non-dev example, a ruler can be considered to be a template -
given different colors (context) you can draw red, blue or green lines -
given different apparatus you can draw lines using a pen, marker, pencil or
blood, if you're creepy like that.
But, what makes the ruler a template? Is it the shape, or the physical
matter that makes it rigid enough to draw against? We believe its the
matter that makes it a template - change its shape and it remains a ruler,
just for different things. Square rulers with holes in them for various
shapes are called stencils, but they are basically just rulers because
what's different is just the *configuration* of that matter. The underlying
concept is the same - drag a drawing apparatus across its rigid surface and
you will draw shapes.
Similarly, a template can itself be considered a renderer. To re-use
Xedin's previous example:
"Hello %s" is the configuration while `sprintf()` is the mechanism for
rendering and `sprintf("Hello %s", $name)` is the template. Given context
"Xedin", the result would be "Hello Xedin".
What we typically think is the template (ex. "Hello %s") is in fact the
configuration. The only difference is that a template MAY need context when
told to "render()".
Notice how I do not mention files - it's the whole point I'm trying to
make. I think files are a very convenient way of storing the configuration
of a template, but they are not required by any renderer.
As far as the API for a renderer or engine goes, I have yet to see valid
reasons for anything other than a "render()" method, or a proxy thereof, to
exist.
For reference to our own standard:
- RenderInterface
<https://github.com/Dhii/output-renderer-interface/blob/release/0.2/src/TemplateInterface.php>
- TemplateInterface
<https://github.com/Dhii/output-renderer-interface/blob/release/0.2/src/TemplateInterface.php>
On Tuesday, 26 September 2017 15:55:03 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/44f114fe-789c-4993-a20d-8a5a391fe624%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
