Templated views
Rate Topic:

Hi
I know the reason for going away from templates is a speed issue, but consider this: If we "precompile" the template to php then from that point forward we use the "compiled" version of the php file we would be just as efficient (well the first ht would be slower but after that it would be fast)

Of course this should be extended to allow for any widget to be invoked through the "<com:" template but for now as a proof of concept it seems to work with CHtml objects.
The Pros
1) Most editors can now parse the document as XML (especially with "CHtml::form()")
2) Allows for editors to perform an auto complete operation on tags.
3) It really does not detract from performance except during that "first load"
4) Its more legible the using php directly to invoke widgets

The cons:
1) It does not save any typing
2) May be confusing to see a compiled version along with the template in the same folder

I would like to add a few more cons about using a template though:
3. using a template means educating users a new language, which contradicts the goal Yii tries to reach. Of course, this may not be an issue for existing prado users.
4. When there is an error in the template, using compiled version make debugging difficult because PHP would complain the error in the compiled version instead of the original template file.

I agree with you that performance is not a big issue here. Maybe I should change those render methods a bit to prepare for such kind of extension.

I have a lot of experience with eZ publish, which uses a compiled template language. I hve a couple of cons based on that.

Cons:
5) Generating the compiled templates takes a while. It is not an issue on a production site as it is done only once, but annoying while developing becuse the templates are changed a lot.
6) eZ publish don't discover changes in some templates so you have to clear the template cache manually. Annoying.
7) In eZ publish we have to write fetch functions or template operators if we need to do something the template language cannot do. This is time consuming and adds overhead. Yii is very liberating as I can just add some php code in the view if I really need to. I believe development time is better spent elsewhere.

rsubsonic: If you look at the implementation i suggested it does not eliminate the possibility of having raw php code in the template it only reduces it. Also the implementation only regenerates the file based on last update date of the files so recompile would only occur during on the changed template.

qiang: Thanks, by using a template system you reduce the "signal to noise" ratio (ie what the view is actual doing compared to the amount of code used to generate a view ). By doing so your code is clearer and you should see an increase in productivity rather then increasing the learning curve. I am intrigued on how would this be implemented as an extension, could you elaborate ?

Pro
5) Suppression (Like prados Visibility flag) could be added as an attribute, resulting in a generated code block like <?php ? if (!$this->ShouldSuppress) echo CHtml::.... ?> like Suppress="$this->ShouldSuppress"

6) I never remember the order of arguments for every method call, using attributes eliminates that problem.

Yes, maybe I should read before I post. I had another look at your implementation, and it would make using template files optional, right? I can definitely live with that.

I understand that your implementation is a proof-of-concept, but would it be better to store the compiled templates somewhere in WebRoot/protected/runtime so the webserver don't need to have write access to WebRoot/protected/views? It would also make it less confusing than having compiled .php, manually created .php and .tpl files in the same directory.

rsubsonic:That's correct, I am only looking to add to the existing functionality not take away. I definitely agree with having the "complied" version live outside the actual application folder, perhaps in the 'final' version all view's "complied" (and "normal" versions) could be copied to a runtime area so in production there would just be one directory to check for both files (although with themes that may be a little more tricky to implement).

qiang: wow, by the time I finished typing this message you finished it already. Will this work for CWidgets && CControllers ? They call getViewFile before calling the renderFile method so that could fail...

Instead of working with getViewFile, we deal with renderViewFile. The possible view renderer could be like the following:
1. check if a compiled version exists for the view file to be rendered
2. if not, compile it and save it to runtime directory using some unique name
3. call $context->renderViewFileInternal() with the generated PHP view file and the parameters, where $context refers to the controller or widget instance. The reason we use $context to do the rendering is because we want to make $this in the view refer to the controller or widget.

I think for now we will not implement this in the Yii framework because we want to keep Yii relatively simple. Of course, if a user comes up with some nice syntax and renderer implementation, we will consider including it the formal release in future.

I'd really love to see this in Yii, especially as this would really help PRADO users to migrate big PRADO projects with many templates to Yii (i run one of those). What i also really like about the PRADO style templates is the fact that i can edit them with a XML Editor (which is not possible with the current Yii templates as they are not valid XML).

Prado's template is also not valid XML. Also, the only thing that will benefit from the Prado syntax in Yii is when you are using widgets in a template. However, in Yii you also use a lot of helper functions as well as some PHP constructs (such as if, foreach).

Prado's template is also not valid XML. Also, the only thing that will benefit from the Prado syntax in Yii is when you are using widgets in a template. However, in Yii you also use a lot of helper functions as well as some PHP constructs (such as if, foreach).

Humm..... that's exactly why I choose Prado over doing something with a Smarty-based framework, for example. I really don't like placing loops and conditionals in a view, and XML widgets seem more "components" than PHP code (LOL). Call me fool, but I feel this is placing logic into the view, even if it maybe is "view logic" and not "business logic" (I know this is debatable, there are tons of discussions related to Smarty and this kind of inclusion of code in views)

The parser is not too difficult to implement and be plugged into the yii framework. Yes, maybe we will provide some parsers for Prado or other template syntax. But at this moment, this is not the most imperative task.

I have started such a parser which I will make freely available after testing with the 1.0 beta release. The reason for the delay is that it is dependent on code existing only in the repository at the moment.

I am looking at applying a subset of the template code supported by Prado. Using the "<com:" approach to widgets and static method class calls along with a limited "<%" support. The output will be able to combine multiple consecutive php directives into one statement as well as passing the "tag body" as a parameter to a widget or static method call.