Thank you Larry for your valuable Feedback and concerns about my proposal. I understand your concern about primitive Types, but I think they are a little bit too much hated today. Also I think we are creating bigger problems with less intercompatibility if we go with object for both the template or the context. I would focus what the best and most developer friendly way is to get all under the hood.
In mostly all Templates engines I analysed the template itself is represented as a string. Sure some template engines under the hood work with Template objects / Template Wrapper objects. But we are not on that Level we are on the Level above the caller. So why is it that way that mostly all did end in that scenario of using a string. I personally think it is because it is the most developer friendliest way. Because of going with a object I would need to import a class, inject a factory or something like that unnecessary complex for that usecase. A string is simple and very developer friendly in this way. The developer know the template they created and put the name into the method call and its done. I also think that is also the case why Laravel got a lot of traction, why other including me trying to overcomplicate things with Object and Types. You will find array and strings a lot in Laravel interfaces and methods, when you scroll through there Documentation. Also asking where do templates coming from. They are mostly coming from 3 places. Place 1: Configuration, Place 2: Database, Place 3 Hardcoded in all cases they are already a string. There are no usecases to convert or manipulate them, I currently think of which would make them usable as convert the string to object. So now from the template name to the context. I mostly see the same problems for the context. Why I see there more the usecase as mezzio mention there TemplateContainer. I think it does overcomplicate the things and the array is still the better Developer Experience here. The object will end us just in another rabbit hole. And in the "big factory question", who is creating the object and providing it. If we have directly a factory method on the TemplateRenderInterface::createView as example which will mostly get string, array it is the question what value it does it really has then. If we go the way of saying we do not care about who is creating that object. It requires me as library author to create such an object or require a library which create it for me. Which I think is the problem I would like to avoid. With string and array I would not need to take care a lot and need to ask me that complicate question. The Developer using my Library will give me the template they want to render and I will call the injected Render with the data I will provide. I think really the best developer experience is keeping it simple with string, array. Still I'm curious how the object you had in mind should look like. Can you show an example what you had in mind? Would help to understand maybe better what advantages it really would had. Thx, Alex Larry Garfield schrieb am Mittwoch, 1. Juni 2022 um 18:00:22 UTC+2: > On Tue, May 31, 2022, at 6:12 PM, Alexander Schranz wrote: > > > > *The proposal* > > The interface for a TemplateRender I would recommend is the following > > based on my analysis of exist template engines and what is the easiest > > way to put them together and have maximum interoperability: > > > > /** > > * Render the template with the given context data. > > * > > * @param string $template > > * @param array<string, mixed> $context > > * > > * @return string > > * > > * @throw TemplateNotFoundExceptionInterface > > */ > > public function render(string $template, array $context = []): string; > > For maximum compatibility we even could consider to publish 2 version > > of the template renderer v1 without typehints so exist template engine > > still supporting old php version can already implement it and v2 with > > typehints. > > > > *Exist TemplateRenderer Discussion* > > There was already an exist disussion about implementing a > > TemplateRendererInterface here: > > https://groups.google.com/g/php-fig/c/w1cugJ9DaFg/m/TPTnYY5LBgAJ. > > > > The discussion goes over several topics just to mention the main parts: > > > > * Template should be objects > > * Context should be objects > > * TemplateRender should stream to output even asynchronity > > To target this specific points. I would focus in this PSR on exist > > solution as we see most work for template with logical string based > > names and do not require an object. > > I was one of the people arguing in the past that a templating interface > needs to be more robust than a dict->string mapper. It does seem that there > is a de facto consensus on that model anyway, so even if it's a poor model > there is potential value in standardizing that much. > > My concern is that while there's obviously a straightforward way to make > common render() methods *type* compatible, that doesn't mean they're > *semantically* compatible. The template name string is, AFAIK, wildly > variable between different systems right now, and the value part of the > replacement array is also a huge ball of undefined. For a standard to > actually be viable, those would need to be standardized at least enough > that a library could use it and expect it to then "just work" whether it's > plugged into Twig, Plates, Sulu, TYPO3 Fluid, or whatever. That also gets > into questions of escaping, and what is escaped where. > > Those are extremely non-trivial questions. I don't know how resolvable > those are in practice, but they would all happen outside the type system, > or else involve not passing primitives (eg, a template object instead of > just a string name, and then we're right back where we started). If the > major players in the template world are on board for a working group to > sort out *that* part of the problem space, I'm happy to support them doing > so. But it would need buy-in from the major players there, because > otherwise it wouldn't be useful. > > --Larry Garfield > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b60cc456-4d50-446f-bd27-94554f01582bn%40googlegroups.com.
