RFC: Bake revamp

[AD7six]

I've asked a few of you about this already, I'd like to put it out there for further thought.

I find writing bake templates to be a bit of a ball ache, yet the results are very powerful. It's like a secret weapon that's just too hard to use for you're average user. For this reason I'd like to find a way that writing bake templates is easier. 

I did have some lofty/complex ideas which would enable view templates and view files to be almost interchangable - in the end though I came up with the following:

Modify template rendering so that it's still in a familiar language (php) but without needing to write php with php.

PHP tags in the template are effectively ignored. The new template with the new render logic generates the same output (more or less) as the existing template with the existing code.

Syntax summary:

 <% ... %> contains templating logic, become php tags when processing the template
 <?(php|=) ... ?> considered raw text when processing the template

https://gist.github.com/AD7six/bececf78e6ebd8ab96fd

It comes to mind right now that the template task could infact be replaced by/refactored into a view class - and therefore have all the benefits of the view layer (helpers, elements).

There have been other suggestions such as "why not use an existing template language like twig?" and to this my main objections are:

• It's a new syntax
• It makes it hard to bake twig templates

Anyway, what do we think - is it worth thinking about changing how bake templates are generated?

Cheers,

AD

[Ravage84]

My answers from the other thread about this topic:

I agree working with bake templates is no joy.
Any solution is welcomed.

Using Twig for bake templates sounds not so bad to me.
But be sure you will get a hell a lot of requests to use it for the views by default then ;-)

Sure it has to be documented and people have to learn it.
But there is already a documentation (+ a community etc.) and not all CakePHP "users" have to learn it, only if they want to work on bake templates.

In any case I prefer Twig over Mustache or any other template engine like Smarty *horror*.
Also other solutions like using asp tags seem prone to break sooner or later or for some users respectively.

My question though is would we want to have a dependency like Twig while you decided some time ago that you don't want to have Doctrine?
I probably compare here apples with pears since Doctrine was a replacement for something more integral as Twig was...

Marc

[Reuben Helms]

I'm in favour of what the gist presents.  I already know PHP, I shouldn't need to have to learn another language just to pump out some bake templates.

Fed up to the gills with having to support (and recommend) Joomla installs for prospective clients who are too cheap to commission a website that actually does what they want to, and looking for an alternative to Symphony CMS (because XSLT is still programming), I started taking a look at Drupal.  Drupal 8 isn't due to go live until at least Sep 30, but it has adopted Twig for it's templates.  I did read that Drupal would be adopting other features of Symphony2, but that's a topic for a different forum.  I'm not a fan of having to learn a new syntax, just to do conditions, loops and what not, when the templates are just going to be rendered by a single language that does those things well enough already.  

If it was a template language that had multiple languages using it, then perhaps. I can't think of any off hand, since most template languages are implemented with the language that it's going to be running with anyway.  The only thing I could see actually doing that is some sort of Javascript/node experience for heavy client side implementations.  But I digress.

The only thing I might recommend is that such make templates that use this syntax have their own extension, so that they don't get confused with regular View templates.  Unless you're going to support this syntax in default views, which probably wouldn't be good for performance (unless the intermediary got cached), but whatever the case, a different extension would be advised. If .ctp = Cake TemPlate, then perhaps .btp = Bake TemPlate.  

Then you might need to decide what is the trigger for using the appropriate View class.  So you look for the template file first, and use the appropriate View class that goes with the extension, or do you have the controller specify the View class to use, and have that View class look for a view file with the specific extension?  I think the latter may perform better, but maybe you'd want to pick a default View class for the application ( or plugin ), and use the other as a fall back.

Regards

Reuben Helms

[mark_story]

The proposed syntax doesn't remove the need to program though. Its still just PHP with all the good/bad parts. Twig while different has several measurable advantages both in terseness and features provided.

I think the biggest gain from using erb style delimiters is that templates that generate PHP code are much simpler to grok than before. I think it is a net win in that situation. I see no reason to use this template style in view templates unless there was a more compelling reason. The most compelling reason I can think of is auto-escaping. This is sorely lacking from CakePHP and would be one of the many reasons I would consider suggesting CakePHP use Twig or another standalone templating system.

-Mark

[mark_story]

I much prefer the erb style delimiters to the ones we talked about last time. Would it not be better to change variable echoing to be <%= $variable %> or <%= variable %> instead of the present approach? Both of these re-use more from existing languages/knowledge than what is currently planned.

I have some concerns as to what will happen when a server has asp style tags enabled. Perhaps we should throw loud exceptions in those situations as baking will surely end poorly.

-Mark

[AD7six]

On Sunday, 28 July 2013 03:19:24 UTC+2, mark_story wrote:

The proposed syntax doesn't remove the need to program though. Its still just PHP with all the good/bad parts.

Personally I see that as a good thing - it's a familiar syntax.

 

Twig while different has several measurable advantages both in terseness and features provided.

I think the biggest gain from using erb style delimiters is that templates that generate PHP code are much simpler to grok than before.

If bake templates are twig templates I see two problems

1. It's  a new syntax for most users
2. It makes baking twig templates, and various other {} based templates/snippets difficult.

The main reason to go with asp style tags (or any other unique pair of delimiters, I went with asp tags for brevity) is simply to choose something that's mutually exclusive with any end-view file.

I think it is a net win in that situation. I see no reason to use this template style in view templates unless there was a more compelling reason. The most compelling reason I can think of is auto-escaping. This is sorely lacking from CakePHP and would be one of the many reasons I would consider suggesting CakePHP use Twig or another standalone templating system.

I can't relate this point to the question - as it appears to be related to how views are processed - can you clarify please?

From the subsequent reply:

 Would it not be better to change variable echoing to be <%= $variable %> or <%= variable %> instead of the present approach?

The code was changed since we discussed to to do the above, I removed the @ alias, evidently not from all examples in the gist

Cheers,

AD

[mark_story]

I'm not suggesting we use Twig for this use case. From my interpretation of Reuben Helms' reply was that he was expecting the erb style delimiters used in view files as well.

I don't think there is much point in introducing a new template syntax for view files unless there are some 

clear advantages. Twig is an example of an alternate template syntax that provides a number of distinct and tangible improvements.

If the original proposal was to co-opt erb delimiters in bake templates using a lightweight processing system, I'm all for that. 

I too find bake templates impenetrable at the best of times.

-Mark

[Reuben Helms]

I'm not fussed on the style of delimiter used, it's more the content of those delimiters, and a preference for that content to be PHP, rather than Twig.

[Reuben Helms]

As I read back on that comment, I realize that I'm just getting old, as the comment sounds like one of those people that resists change, just because it's change.  While CakePHP might be a playground I'm welcome to play in and contribute to, I've it's not my play equipment alone, and I've got to share.

So, just to recap, no one wants to write the following in a bake template:

<?php echo '<?php echo $data[\'' . $model->alias . '\'][\'id\']; ?>'; ?>

Specifically, it's the inner php statements that are annoying, and can get confusing.

So, the first suggestion is to use erb style delimiters or similar to make help distinguish the php for the bake, and the php for the generated template:

<?php echo '<%= $data[\'' . $model->alias . '\'][\'id\']; %>'; ?>

This is definitely easier for my eyes to parse.

The flipside is to use the syntax change for the php statements in the bake template, rather than the output.

<% echo '<?php echo $data[\'' . $model->alias . '\'][\'id\']; ?>' %>

The issue with that one is that we might loose the benefit of syntax checking that is available with our IDE of choice (mine is Eclipse).

One alternative raised was the usage of Twig in the bake template.

<?php echo $data[{{ $model->alias }}]['id']; ?>

With this, I'm assuming that a Twig template doesn't execute <?php ?> blocks, but just echos it, like it would any other tag.  I'm also assuming that I'm using the correct syntax for Twig variable access and the bake controller would correctly insert view variables into the Twig engine for use in the template.

The flipside to this is Twig in the actual view.

<?php echo '{{ $data[\'' . $model->alias . '\'][\'id\'] }}'; ?>

Things start to get hairy when you use Twig in the bake view and the actual view.

{{ '{{ $data[\'' }}{{ $model->alias}}{{ '\'][\'id\'] }}' }}

I'm not sure that's the best way to do that. I did consider {% verbatim %}.. lets just see what that might look like.

{% verbatim %} {{ $data[' {% endverbatim %}{{ $model->alias }}{% verbatim %} ']['id'] }} {% endverbatim %}

Well, it looks like I've talked myself 180 degrees.  The option to use Twig in the bake template only actually looks the cleanest for this trivial example, assuming I've got my syntax right.

Though I have a feeling that my trivial example may not actually reflect the reality of an actual bake template, as shown by the AD7six gist, as his example looks much cleaner when using h() and __().

Regards

Reuben Helms

[AD7six]

On Thursday, 1 August 2013 01:04:13 UTC+2, Reuben Helms wrote:

As I read back on that comment, I realize that I'm just getting old, as the comment sounds like one of those people that resists change, just because it's change.  While CakePHP might be a playground I'm welcome to play in and contribute to, I've it's not my play equipment alone, and I've got to share.

So, just to recap, no one wants to write the following in a bake template:

<?php echo '<?php echo $data[\'' . $model->alias . '\'][\'id\']; ?>'; ?>

Specifically, it's the inner php statements that are annoying, and can get confusing.

So, the first suggestion is to use erb style delimiters or similar to make help distinguish the php for the bake, and the php for the generated template:

<?php echo '<%= $data[\'' . $model->alias . '\'][\'id\']; %>'; ?>

Bear in mind - that should be

<?php echo $data['<%= $model->alias %>']['id']; ?>

                  ^^^^^^^^^^^^^^^^^^^^

 

The whole purpose of my proposal was to prevent echoing/escaping php code.

Cheers,

AD

[Reuben Helms]

Bugger it, I knew I had it the wrong way around somewhere down the line.

Cheers,

AD

--
You received this message because you are subscribed to a topic in the Google Groups "cakephp-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cakephp-core/plAK5Hof4ls/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.