Closed alganet closed 12 years ago
I understand the separation of concerns here, but how an alias is different from:
<h1 class="page-title">No title defined</h1>
$view = new Html('file.html');
$view['.page-title'] = 'Example page';
The template side isn't the problem, problem is on the controller side. Let's say I have this:
return array(
'.page-title' => $author->name
);
Now I need to make this controller speak JSON. Output would be something like: {".page-title":"Alexandre Gaigalas"}
, but makes a lot more sense to be {"title":"Alexandre Gaigalas"}
. Also let the designers change their template classes and structure without changing the controllers (just the INI/PHP that describe those aliases)
Now I understood. Makes a lot of sense, and makes sense also to pass some collection of aliases in the Html object constructor .... I also agree with the markup you liked the most. =) It is a feature to me already.
I've added basic static support for this. If we ever step into runtime manipulation of selectors we need to improve my implementation a little.
We currently implement a template engine, this is awesome. But now we're starting to mix up layers.
A controller should never do something like:
'Cause "body > h1" is particular from the View layer, not the Controller one. We currently have nothing to offer to an user that wants to separate those, and we need to encourage this good practice.
I've thought on a simple aliasing mechanism on the template:
Respect\Template would try to match an alias before matching a selector. Or perhaps it should match only aliases, forcing the developer to register them and separate the logic.
Is possible (perhaps on Respect\Framework =D) to use a Config-compatible INI to register those aliases, making it easy for the developer to add new ones:
Another possible syntax (my favourite):