{block} and {include} without #

Notice: This thread is very old.
David Grudl
Nette Core | 8082
+
0
-

There are two ways how to write block names – with or without #. And this is not good.

Macro {include} forces you to use #, so a lot of developers prefer to use # in {block} too.

In 2.1 I introduced short syntax {#content}. Now I realized that it was wrong :-(

Short syntax is not understandable. And this looks weird <div n:#=xxx>. And three syntaxes are even worse than two.

Much better solution is to remove #. So now it is possible to use {include content} and you can feel free to forget #. It was history, but now it has no sense.

Jan Tvrdík
Nette guru | 2595
+
0
-

How does this handle variable block names, e.g. {include #$name}?

David Grudl
Nette Core | 8082
+
0
-

In this case is # required because it is not possible to distinguish whether $name contains file name or block name. But of course, we can find better syntax for this usage.

I did not create this thread because I want to remove the #, it still works and will work. The purpose is to solve another problem: when I teach people to use Latte, they are confused about using/not using these hash signs. They ask what's the difference. And there is no difference.

nAS
Member | 277
+
0
-

As Jan Tvrdík mentioned, this doesn't solve problem with two different syntaxes. Wouldn't be better to prefer block name with # everywhere? As you mention, most developers already prefer # in block name.

P.S. I agree that macro {#name} should be obsoleted, few more characters ( {block #name} ) increases readability a lot.

arron
Member | 464
+
0
-

@nAS +1

Majkl578
Moderator | 1364
+
0
-

@nAS: +1

enumag
Member | 2118
+
0
-

@nAS: +1

dimkalinux
Member | 24
+
0
-

{block #name} +1

Jan Tvrdík
Nette guru | 2595
+
0
-

Just to make things clear – you all prefer <div n:block="#name">...</div> over <div n:block="name">...</div>, right?

enumag
Member | 2118
+
0
-

@Jan Tvrdík: Hmm…

Well in my opinion it's wrong to use the {include} macro for files as well as blocks. The # is there only because of this and cannot be removed completely because of {include #$name}.

Sadly there already is a {includeblock} macro which should be renamed imho. I'd expect it to work as include for blocks, for example {includeblock $name} should be equal to {include #$name}.

duke
Member | 650
+
0
-

I suggest keeping the usage of leading # in block names as optional and at least for now keep the current behavior of {include} macro. I am not sure about {#blockname} syntax, but perhaps we could keep it as a syntactic sugar for those who prefer to use this shorter notation, but I agree sandbox and other tutorials should use {block blockname} notation (same goes for <div n:#=blockname> vs <div n:block="blockname">).

I agree with enumag though, that {includeblock} macro should be renamed as it doesn't include a block, but AFAIK loads block definitions from a file. I could imagine e.g. {loadblocks}.

Then sometime in future we could split {include} into two macros (for files and blocks), but without that intermediate step it would probably create too much confusion.

Honza Marek
Member | 1664
+
0
-

I think two macros (include and includeblock) and no # would be ideal. Unfortunately there are backward compatibility issues.

enumag
Member | 2118
+
0
-

@duke: My thoughts exactly. :-)

I'd like to sum up my suggestion:

Changes for 2.1:

  • renamed {includeblock} to {loadblocks}
  • {includeblock} preserved for BC but throwing deprecated error
  • hashes as they are now
  • optionaly deprecated {block #name}
  • optionaly deprecated/removed {#block} syntax

Changes for 3.0:

  • new macro {includeblock name} same as {include #name}
  • deprecated {include name}, {include #name}, {block #name}
Filip Procházka
Moderator | 4668
+
0
-

We could have {include file.latte} and {call #name} :)

But I still prefer writing the # in the block name everywhere.

bazo
Member | 620
+
0
-

i really like the short #syntax, i prefer it to writing {block name}
lots of rewriting ahead… :(

xificurk
Member | 121
+
0
-

If I may put my two cents in, I would go for {useblocks} instead of {includeblocks}.

Last edited by xificurk (2013-11-06 23:51)

nAS
Member | 277
+
0
-

@bazo: You can always define your own macro.

bazo
Member | 620
+
0
-

i would have to define the macro in all my apps, i can as well rewrite the {#name} tags to {block #name}
rewrite is at least forward compatible

enumag
Member | 2118
+
0
-

@dg: Will you do sth about this before 2.1?