On Wed, Jun 1, 2022, at 2:12 PM, Alexander Schranz wrote:
> 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
Please bottom-post if replying to someone who already bottom-posted.
Regarding the string for the template name, what mbabker replied on the GitHub
thread is basically my point.
If I, as a random library dev that wants something rendered, want to call this
method, then right now I would have to one of the following:
Twig:
$this->template->render('controller/welcome.html.twig', [...]);
Laravel Blade:
$this->template->render('welcome', [...]);
Smarty:
$this->template->render('welcome.tpl', [...]);
Latte:
$this->render('path/to/welcome.latte', [...]);
Just standardizing that the first argument is "a template name" isn't enough.
Is that string a file name? File path? Relative to where? Lookup ID from
some index maintained elsewhere? How do I then tell the framework my library
is getting plugged into what template ID needs to be defined somewhere?
Those are all things that COULD be answered successfully, but MUST be answered
consistently for this proposal to work. That's what a working group would be
responsible for hammering out.
Also, how do I, as a random library author, provide a default template if that
template is naturally going to be in one particular template system or another?
Or am I not allowed to? If I don't, does that mean I cannot actually test my
library without pulling in some template engine?
Again, there probably are solutions to that question, but they will only be
found by bringing the right people to the table to make compromises and hash
out those details.
In short, *do not focus on the spec right now*. The current proposal is very
incomplete as it doesn't address these and other issues, but that's OK, it
should be at this point. Focus on building the team who will think through
finding these and other issues none of us have thought of yet, and figuring out
a collective solution.
--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/8041b30d-7066-4cdc-8c2e-85a18bcdba72%40www.fastmail.com.
