Latte redesign: that could easily be used standalone

Love it. What could be first step?

Will be splitting compilation and rendering part of the redesign?

@DavidGrudl Latte plays role of filter now. If it'll be combined with templates, what about other filters registration strategy?

Last edited by Milo (2014-02-13 10:40)

I agree that FileTemplate (and PhpFileStorage) should be part of latte, but there should also be some thin Nette\Templating layer for integration of other templating engines, the concept of filters is good IMHO. I have already proposed splitting Nette\Latte\Engine into Nette\Latte\CompilerFactory and Nette\Templating\LatteFilter (not sure about namespaces now, but the main idea should be clear). It makes LatteFilter smiple & sexy.

Also +1 for compiler and parser as constructor dependency of latte filter.

Edit: Maybe Nette\Templating should have more general API, not all templating engines have to compile templates to php.

Edit 2: Storing parameters in $template is also very strict requirement. Maybe something like

interface ITemplatingEngine
{
	public function render(ITemplateSpecification $template, array $parameters);
}

Edit 3: Implementing both ITemplatingEngine and LatteFilter would require some additional bridge between Nette\Latte and Nette\Templating, but it would allow simplify integration of almost any templating engine to Nette\Templating and integration of latte to almost any framework.

Last edited by mkoubik (2014-02-13 12:55)

Theoretically, we could have

class Engine
{
	function __construct(Parser $parser = NULL, Compiler $compiler = NULL)
	{
		$this->parser = $parser ?: new Parser;
		$this->compiler = $compiler ?: new Compiler;
	}

Engine factory sounds nice, it could add the default macros, or the template factory could (should) add them.

$engine = (new Nette\Application\UI\LatteEngineFactory)->create();

If the default macros were added in TemplateFactory and not in Latte\Engine, the LatteEngineFactory doesn't make sense to me anymore.

David Grudl wrote:
Own instances will be used very rarely.

I agree with it. But if so, typehint Latte\Engine will be on many places and Engine will have to be inherited only because own Compiler/Parser need.

Filip's constructor propose Parser $parser = NULL, Compiler $compiler = NULL seems as good compromise to me. Or pronounce methods setParser() and setCompiler() as normal (not debugging only purpose) methods.

Btw. I vote for lazy $latte->onCompile[] variation.

Please note that Latte\Engine is only factory

That is not true. It is too smart to be “only factory”. It is a “smart factory” (yeah, difference!) like Nette\Configurator which contains its own general-purpose logic AND sets default extensions (that is the flaw). Latte\Engine has the same issue. Both general-purpose and specific-purpose logic. I'll need to see the actual implementation of Latte\Engine to determine whether the amount of general purpose logic is a reason to create an extra Latte\EngineFactory but now I think it is.

@David Grudl: If API is the only thing that matters to you, then what about creating sth. like Latte\BareEngine with general purpose logic and Latte\Engine extends BareEngine with default macros and helpers. We both know that it is not ideal, but the end-user API will remain the same and design would be cleaner.

@mkoubik: constructor in Latte\Engine should definitely not create instance of Compiler due to performance, because Compiler and Parser are required only when the renderer template is not yet compiled. Current solution in Nette is not creating Latte\Engine instance at all when templates are already compiled.

Ufff, please be more pragmatic :-) Who of you did ever changed parser of compiler? I bet that nobody. So do not propose ideas like parser and compiler in constructor, it is nonsense. No, it is dependency on dependency container :-) And we are talking about standalone Latte.

David Grudl wrote:

Ufff, please be more pragmatic :-) Who of you did ever changed parser of compiler?

Ok, I did, but this is not important.

If default Latte\Engine would not install any macros, I would agree. But what if my framework doesn't even support generation of links, what if I don't wanna allow users to insert php code to templates, etc.
Good compromise would be to have preinstalled some core macros, that do depend only on built-in PHP functions and classes in runtime (not true for current CoreMacros and definitely not true for UIMacros). Good compromise would be API

$latte = new Latte\Engine; // some essential macros predefined
$latte->addMacros(new UIMacros);

instead of

public function __construct()
{
	$this->parser = new Parser;
	$this->compiler = new Compiler;
	Macros\CoreMacros::install($this->compiler);
	Macros\UIMacros::install($this->compiler);
	\\ ...
}

and

MyMacros::install($latte->getCompiler());

If the API would be like in the first case and installing macros would be responsibility of latte engine itself, then compiler as a dependency of latte engine would be completely uninteristing for the end user.

BTW: Constructor IS a static factory method by definition. The only distinction is that it is the default one.

Last edited by mkoubik (2014-02-14 01:00)

If default Latte\Engine would not install any macros, I would agree

Yes, but in this case $res = $latte->render($file, $parameters) is exactly the same as $res = file_get_contents($file), just a little bit slower :-))

ad point two: topic is Latte redesign: that could easily be used standalone

($pdo = new PDO($dsn, $user, $pass)? Too simple, Anton Pavlovich. What about $pdo = (new PdoFactory)->create($dsn, $user, $pass) ;-) )

What's your opinion on this?

class Engine
{
	private $parser;
	private $compiler;

	public function __construct(Parser $parser = NULL, Compiler $compiler = NULL)
	{
		$this->parser = $parser ?: new Parser;
		$this->compiler = $compiler ?: new Compiler;

	}

	public static function create()
	{
		$engine = new self();
		$engine->addMacro(new Macros\CoreMacros());
		$engine->addMacro(new Macros\CacheMacro(), 'cache');
		$engine->addMacro(new Macros\UIMacros());
		$engine->addMacro(new Macros\FormMacros());
		return $engine;
	}
}

Or at least move the configuration from constructor to protected method so I can change it in child.

Last edited by mkoubik (2014-02-28 10:02)

I think UIMacros will have to be split too. Macros like {block} and {include} are not nette-specific. However {link} and {snippet} are. Which may be a little problem because snippets are actually blocks as well and they are using the same code.