rejetto forum
Software => HFS ~ HTTP File Server => HTML & templates => Topic started by: rejetto on January 18, 2008, 05:18:13 AM
-
This topic is mainly for those of you who edit templates.
I have in mind 2 changes for the macros.
1. change {{ and }} to {. and .} or similar ...suggestions are welcome.
The point is readability. All those }}}}}} are very unclear and hard to count. While .}.}.} is easier to know they are 3.
This is a 20 seconds job for me, but it will break compatibility with those of you who are already using a template with macros. It will cause some whining for few days.
I think it is worth it, and we must do it before I publish the stable version.
2. Having named parameters.
I mean, optionally you will specify parameters based on their names instead of their order.
Example {{substring|1|3|hey you}} will be equivalent to {{substring|what=hey you|from=1|to=3}}
In the later case the order is not important because you are naming the parameters.
What do we gain? Readability and memory, you can remember parameters' name instead of the order, sometimes it's easier.
I'm not even sure i can create this feature easily, but i want to know your opinion before.
-
1.
change {{ and }} to {. and .} or similar ...this would be welcome!
2. 2. Having named parameters.could be very usefull, so we don'nt need no more to copy an rewrite notes from wiki changeing A|B|C|D| ... to string,expression,fromto ... perhaps you could first do this change in the wiki so we could propose alternate names if you choose some unhappy parametername.
-
1.
I like the idea for changing the surrounding markers because I have a lot of trouble reading some of the nested macro's I have created, and even more trouble when I find out I have missed closing one. {. and .} are a good suggestion and I'm in favor of those unless someone suggests a better more readable combination.
2.
This also sounds like a good idea and I think it could be useful for readability in some cases but the current way macro parameters work is fine in my opinion.
-
1. what about {: and :} ? you like it more?
-
{. and .} is still better because there is more white space so it stands out better.
-
1. When we'll decide the new markers, you'll be able to convert your template by submitting it to www.rejetto.com/convert.php :)
2. I made a little test with named parameters, and they work. I will let you know as i decide name of parameters. You can suggest in the while.
-
1. Moreover, i think {{\ and /}} should become {\ and /}
i don't think they should collide with other things
-
i'd like to hear from the rawr team about the legacy breaking
(although we're speaking of legacy with betas, no with officials)
-
I do not know if you will be of my opinion,but as rejetto I think that the shortest is the best
the advantage off {{ or }} is that you press the key ALT-GR + twice {
but {. you must press ALT GR + { and then SHIFT+. (when you have no numeric keyboard)
French keyboard is not more easy than us keyboard where keys are not at same place.
Often I am obliged to concentrate on the keyboard for not to confuse [[ and {{.
for {{\ ansd /}} why not use {{\ and \}} and then only 3 actions with keyboard
1 ALT-GR
2 \
3 {{ or }}
WHY ??
how making diffence by using {{set|myvar|/set}} ; Is myvar empty or must it be "/set"?
the same problem is here to detect {{\ ...... /}} or {{\ .... \}}
I propose at this place {\\ and //} to reduce usage {{ as will rejetto to use one {
All those }}}}}} are very unclear and hard to count
you can add some caraters as space or / : /}}/}}/}} easy to count.
A good example of that (http://www.rejetto.com/forum/index.php?topic=5353.msg1032379#msg1032379)
{{if|{{or|{{{{?p}}=1}}|{{not|{{?p}}}}}}||{{\{{for|B|1|{{sub|{{mul|{{^topic-limit}}|{{?p}}}}|25}}|{{\{{set|topic-order|{{cut|{{add|{{length|{{substring||;|{{^topic-order}}}}}}|2}}||{{^topic-order}}}}}}/}}/for}}/}}/if}}
converted to
{{if not|{{or|{{?p=1}}|{{?p=}} /or}}
|{{\
{{for|B
|1
|{{sub|{{mul|{{^topic-limit}}| {{?p}} }} |25}}
|{{\
{{set|topic-order
| {{cut|{{add|{{length|{{substring||;|{{^topic-order}} /substring}} /length}}|2 /add}}
||{{^topic-order}}}}
/cut}}
/set}}
/}}
/for}}
/}}
/if}}
Why not use something as php
<?HFS {set |myvar | SOME } {if|myvar| Ok for Me| why not?} ?>
Why not redefine syntax for macros
<?HFS set myvar= SOME; if (myvar) {Ok for Me} else {why not?} ?> ;D ;D ;D ;D
There, I joke naturally
The simplest is to preserve the existing, as a pebble in a shoe which hurts us in the foot, and to encourage rejetto to offer us a PHP version or cgi as fast as possible
there is no easy solution {{ {§ {[ {| {$ {# {\ {: {& the problem is how many keys you must press to obtain the min caracters in the template? I prefer to save the end of my fingers ;D
Make your choice :D
Post scriptum:
{: is more visible as {.
-
I prefer {: and :}
Mars, PHP-esque syntax would be pretty slick, but I fear it's not practical for Rejetto to implement :( Besides, true PHP support would be better :D
-
I'm all for readability,
I have my own thing in mind... [\macro/] I like this because you don't even have to press shift, its just 1 press for each symbol.
[\if | [\$section/] | [\$section/] /]
/]/]/] it's easy to see as well ;D
I also like this because its like \ / stands for importing a section, you could even remove $ and just have [\ /] for the section import so you end up with [section] [\section/]. This is just an idea for it though.
About legacy, I can just make the next build have the new macros and force an update, once i'm able to fire the {{load}} macro in [special:strings] i'll be able to release.
If it HAS to have the {} then i prefer {\ /}
-
I have my own thing in mind... [\macro/] I like this because you don't even have to press shift, its just 1 press for each symbol.
Look at the other countries, this is not true for the French keyboard for example
[\section/]
[\ /] or {\ /} It returns to the same, so much to use [[ ]] or {{ }}
******************************************************
for {{\ /}} I suggest, when it is possible, to do without it
to examples
{{set|myvar|{{one macro|some parametters}} }}
{{set|mymacro|{{\ {{one macro|some parametters}} /}} }}
Replaceable by
{{set var | myvar | {{one macro|some parametters}} }}
{{set macro | mymacro | {{one macro|some parametters}} }} no dequote necessary but working as it ( set is not necessary to define var and macro)
And make a difference during the call
{{%myvar}}
{{^mymacro}}
And keep {{set|mymacro| }} for a usage mixed as
{{set|mymacro | ... {{one macro|some parametters}} .... {{\ {{other macro|some parametters}} /}} ... }}
-
It will be better with {\ /} or [\ /] cause it is more readable, your whole post achieves nothing towards a solution.
-
It will be better with {\ /} or [\ /] cause it is more readable
Everything depends from which point of view we take place and of how we write his code, proof is there:
Quote
{{if|{{or|{{{{?p}}=1}}|{{not|{{?p}}}}}}||{{\{{for|B|1|{{sub|{{mul|{{^topic-limit}}|{{?p}}}}|25}}|{{\{{set|topic-order|{{cut|{{add|{{length|{{substring||;|{{^topic-order}}}}}}|2}}||{{^topic-order}}}}}}/}}/for}}/}}/if}}
converted to
Quote
{{if not|{{or|{{?p=1}}|{{?p=}} /or}}
|{{\
{{for|B
|1
|{{sub|{{mul|{{^topic-limit}}| {{?p}} }} |25}}
|{{\
{{set|topic-order
| {{cut|{{add|{{length|{{substring||;|{{^topic-order}} /substring}} /length}}|2 /add}}
||{{^topic-order}}}}
/cut}}
/set}}
/}}
/for}}
/}}
/if}}
It is enough to take time to make things methodically ;D ;D ;D
If we look in depth at posts, we notice that nobody really brings solutions but only the preferences of each. ???
-
for {{\ ansd /}} why not use {{\ and \}} and then only 3 actions with keyboard
1 ALT-GR
2 \
3 {{ or }}
WHY ??
i proposed {\ and /} few posts above.
how making diffence by using {{set|myvar|/set}} ; Is myvar empty or must it be "/set"?
"making difference"? it is empty, because /set is ignored, as stated in the wiki.
All those }}}}}} are very unclear and hard to count
you can add some caraters as space or / : /}}/}}/}} easy to count.
space is ok, but it's not very strong, and it makes the string longer.
you cannot use "/" and type /}} because that is the quoting closer!!!
.}.}.} is plainer than the extra space, and shorter.
Why not use something as php
<?HFS {set |myvar | SOME } {if|myvar| Ok for Me| why not?} ?>
Because it's a longer syntax that would penalize quick usage.
there is no easy solution {{ {§ {[ {| {$ {# {\ {: {& the problem is how many keys you must press to obtain the min caracters in the template? I prefer to save the end of my fingers ;D
Make your choice :D
that is not the only point.
You write only once, but read many.
You shouldn't be quicker at typing and slower at reading. That is a bad design principle.
Post scriptum:
{: is more visible as {.
In the end :)
-
I have my own thing in mind... [\macro/]
that would collide with sections syntax
If it HAS to have the {} then i prefer {\ /}
you mean {\macro|parameter/} ?
and what for quoting?
-
{{set|myvar|{{one macro|some parametters}} }}
{{set|mymacro|{{\ {{one macro|some parametters}} /}} }}
Replaceable by
{{set var | myvar | {{one macro|some parametters}} }}
{{set macro | mymacro | {{one macro|some parametters}} }} no dequote necessary but working as it ( set is not necessary to define var and macro)
that can't be done with the current parser, because the parser knows nothing about the macros.
-
well for qouting (which i've never used), we could just go... {\\ //}
-
Why not use something as php
<?HFS {set |myvar | SOME } {if|myvar| Ok for Me| why not?} ?>
Because it's a longer syntax that would penalize quick usage.
i changed my mind. I'll see if i can easily adapt the parser to work in shorter way inside <?hfs ?> and in the longer way outside.
-
<?hfs
if ($section = "section") {
$section
} else {
$section1
}
?>
orr
<?hfs
if {$section = section} {
$section
} else {
$section1
}
?>
orr
<?hfs
if $section = section {
$section
} else {
$section1
}
?>
If you could do something like that, it would be very pro. I have thought that it should be <?hfs ?> since the beginning. But i was worried about the speeds also.
-
I think that it is possible to work with the examples of TSG but two rule must be established well:
1)
<?hfs
if ($section = "section") {
$section
} else {
$section1
}
?>
The use of <?HFS ?> has to return no result.
We have to declare specific variables to work correctly in this environment ($variable) or the other shape not to be confused with the existing
2) Creation of a macro specific to return one or several results to the order of execution (in the style of document.write)
$return ...
or {{return result| ....}}
****
In the final, we shall have an appearance of javascript but executed quoted to server
[quote]<?hfs
$return "begin of macro";
if ($section = "mysection") {
$return {{section|$section}};
} else {
$return {{section|$section1}};
}
$return "end of this 'macro' ";
?>[/quote]
-
to return variables in php don't you just go... <?php print $variable; ?> so... <?hfs print $section ?> <?hfs print !string ?> etc etc, and for others you would just echo your answer instead of print. I'm havent had much experience with php just what i've learnt from making our homepage.
-
you guys...!
the example was already in my post, and has nothing to do with yours.
the parser only knows 2 rules. {{macros}} and {{\quoting/}}
for a php-like thing there's a rule for the if, a rule for the while, a rule for the break, ...and so on for 200 times.
-
Well then use {\ /} {\\ //}!
-
Lets vote!
you can suggest more options and i will add them.
You can change your mind and change your vote at any moment.
-
{:m:} {\q/} that is confusing... there is no similarity between them and you can't see that a macro has been qouted. Same goes for {.m.} {\q/}. {\m/} {\\q//} is better.
-
Voted strictly on readability. Soon I hope to learn some coding and be worth my vote :P
I agree with tsg though, that looks best for readability and to be seen in junks of code
-
Tsg, I am sorry to oppose to you, but {\m/} and {\\q//} are too similar to be acceptable.
I had proposed in rejetto a modification of the code to use {\\ double dequote //} as a replacement of {{\{{\ dequote /}}/}} when it was necessary : REFUSED
I recognize the weight of your influence within the forum, but the fact of insisting (by several posts) on obtaining the syntax which is best convenient for you, does not very fair play .
;D
-
Well what about, {\macro/} {/quoting\} the opposite being a macro that will run later (thats how i see macro quoting).
-
What would be not bad it is that you are not the only one to be future evolutions, we would understand a little better the reasons of some of your posts
-
Well what about, {\macro/} {/quoting\} the opposite being a macro that will run later (thats how i see macro quoting).
now you can vote it ;)
-
Voted strictly on readability.
very good.
to vote for readability you should
1. have a in front of you a "script" of average complexity using the several options of the poll
2. be able to understand what it means
that's what i call "read" for "readability" :)
-
What would be not bad it is that you are not the only one to be future evolutions, we would understand a little better the reasons of some of your posts
wtf are you going on about? I just suggested another idea. The reason I am trying to push a certain way of writing Macro is because i have to write this shit (no offence rejetto) for 3 templates now. I am sick of changing them for releases, I want a proper method, one that doesn't change for many months. I take a lot into account before posting my ideas, sometimes they are brief because I have spoken with rejetto personally over IM and post a small amount on the forum. Giant Eagle is not interested in Macro, so it just leaves me to write the Macros for ToG, Terayon and RAWR-Template, it is tough to fit in editing during a university semester (I study Multimedia). So if anything I, rejetto and the other common template makers (all have left except my team) should have a greater influence on the final outcome. My weight on the forum has nothing to do with my posts, ever.
</off-topic>
<on-topic>
Thanks for adding that option rejetto, but it seems a little unfair to add them without resetting the poll? I guess people can change their vote but most are lazy. Can't you make a note of these results and reset it. Ino i can't even be bothered to change my own vote lol.
-
People who won't change their vote will likely won't even vote again.
I see the problem, but resetting seems to me more negative than positive.
-
oh oh another idea. How about {.m.} {:q:} so 2 dots means quoted! The best of 2 worlds ;)
-
I don't really like {.macro.} because I find the periods too easy to miss. I am also not a fan of shuffling my slashes with {\macro/} and {/quote\}. It's bad enough that Windows can't decide which way the slashes face in filenames/URLs :)
My first vote goes to {:macro:} and {\quote/}
If I could vote for a secondary preference I'd go with {\macro/} and {\\quote//} - the double slash // syntax is commonly used for comments in other languages which offsets the similarity between the two.
-
Has anyone considered defining special XML-style tags as our macros?
<hfs:macro parameter1="value" parameter2="value"/>
or
<hfs:macro parameter1="value" parameter2="value"></hfs:macro>
Embedding macros becomes more troublesome however :(
-
I have decided I am going to make a set of examples. Because i don't think people realise the importance of their decisions here. The idea is to make the code more readable and see the difference between a macro and a quote without any drastic effect that will clearly change their appearance as a macro.
1. {.macro.} and {\macro with quoting/} =
{.breadcrumbs|{\<a href="%bread-url%">{.or|%bread-name%|{.!home.}/</a>.}/}.}
2. {:macro:} and {\macro with quoting/} =
{:breadcrumbs|{\<a href="%bread-url%">{:or|%bread-name%|{:!home:}/</a>:}/}:}
3. {\macro/} and {\\macro with quoting//} =
{\breadcrumbs|{\\<a href="%bread-url%">{\or|%bread-name%|{\!home/}/</a>/}//}/}
4. {\macro/} and {/macro with quoting\} =
{\breadcrumbs|{/<a href="%bread-url%">{\or|%bread-name%|{\!home/}/</a>/}\}/}
5. {.macro.} and {:macro with quoting:} =
{.breadcrumbs|{:<a href="%bread-url%">{.or|%bread-name%|{.!home.}/</a>.}:}.}
Personally I am now swinging towards the 5th option, because they both carry a similarity between each other, 2 dots means quoted for later. There is also more white space above the fullstop which makes it a lot clearer to read, and is easier to write as it does not require a shift input (on en_us keyboard anyway). The ones with a forward slash on the end get lost in the html endings i have noticed, which has turned me off all of those, (even my own ones mars).
-
just one question to TSG
http://en.wikipedia.org/wiki/Keyboard_layout#US
In the link this below which keyboard gets closer most of your
-
I don't see a problem? I cant help that your keyboard is wrong ;). The majority of the worlds keyboards will be fine. You place a fullstop at the end of a sentence right? So you must be used to the motion. And a colon is simpler for you than it is for the English.
On the French keyboard you just have the :. on the opposite shift. So I don't see the problem. The world is a lot bigger than France.
-
My BIG problem is the legibility of template when you are in 1024*768 or 1152*864
a dot don't appears correctly .:.:.:.:.:.:.:.:.:.:.:.:.::.:.:.:.:.:.:.:.:.:.:.:.:.
it more visible with \:\:\:\:\:\:\:\: :/:/:/:/:/:/:/:/:/:/:/:/:/:/:/
Why this choice? Characters appear like this in the Diff Template box
For the example:
Source:
{{if|{{or|{{{{?p}}=1}}|{{not|{{?p}}}}}}||{{\{{for|B|1|{{sub|{{mul|{{^topic-limit}}|{{?p}}}}|25}}|{{\{{set|topic-order|{{cut|{{add|{{length|{{substring||;|{{^topic-order}}}}}}|2}}||{{^topic-order}}}}}}/}}/for}}/}}/if}}
Model 1: {.macro.} and {\macro with quoting/}
{.if|{.or|{.{.?p.}=1.}|{.not|{.?p.}.}.}||{\{.for|B|1|{.sub|{.mul|{.^topic-limit.}|{.?p.}.}|25.}|{\{.set|topic-order|{.cut|{.add|{.length|{.substring||;|{.^topic-order.}.}.}|2.}||{.^topic-order.}.}.}/}/for.}/}/if.}
Model 2: {:macro:} and {\macro with quoting/}
{:if|{:or|{:{:?p:}=1:}|{:not|{:?p:}:}:}||{\{:for|B|1|{:sub|{:mul|{:^topic-limit:}|{:?p:}:}|25:}|{\{:set|topic-order|{:cut|{:add|{:length|{:substring||;|{:^topic-order:}:}:}|2:}||{:^topic-order:}:}:}/}/for:}/}/if:}
Model 3: {\macro/} and {\\macro with quoting//}
{\if|{\or|{\{\?p/}=1/}|{\not|{\?p/}/}/}||{\\{\for|B|1|{\sub|{\mul|{\^topic-limit/}|{\?p/}/}|25/}|{\\{\set|topic-order|{\cut|{\add|{\length|{\substring||;|{\^topic-order/}/}/}|2/}||{\^topic-order/}/}/}//}/for/}//}/if/}
Model 4: {\macro/} and {/macro with quoting\}
{\if|{\or|{\{\?p/}=1/}|{\not|{\?p/}/}/}||{/{\for|B|1|{\sub|{\mul|{\^topic-limit/}|{\?p/}/}|25/}|{/{\set|topic-order|{\cut|{\add|{\length|{\substring||;|{\^topic-order/}/}/}|2/}||{\^topic-order/}/}/}\}/for/}\}/if/}
model 5: {.macro.} and {:macro with quoting:}
{.if|{.or|{.{.?p.}=1.}|{.not|{.?p.}.}.}||{:{.for|B|1|{.sub|{.mul|{.^topic-limit.}|{.?p.}.}|25.}|{:{.set|topic-order|{.cut|{.add|{.length|{.substring||;|{.^topic-order.}.}.}|2.}||{.^topic-order.}.}.}:}/for.}:}/if.}
MODEL 6: the best NO CHANGE
{{if not|{{or|{{?p=1}}|{{?p=}} /or}}
|{{\
{{for|B
|1
|{{sub|{{mul|{{^topic-limit}}| {{?p}} }} |25}}
|{{\
{{set|topic-order
| {{cut|{{add|{{length|{{substring||;|{{^topic-order}} /substring}} /length}}|2 /add}}
||{{^topic-order}}}}
/cut}}
/set}}
/}}
/for}}
/}}
/if}}
We can put the meter to zero and add a sixth option ;D ;D ;D ;D ;D
Later each can really choose ;D ;D ;D
-
Armistice of joke
at beginning of all template
<!-- HFS build x {{macros}} {{\dequote/}} -->
or
<!-- HFS build x {.macros.} {\dequote/} -->
or
<!-- HFS build x {:macros:} {\dequote/} -->
or
<!-- HFS build x {\macros/} {\\dequote//} -->
or
<!-- HFS build x {\macros/} {/dequote\} -->
or
<!-- HFS build x {.macros.} {:dequote:} -->
The advantages are:
- no interference with the html code
- we can emit a warning if the version of hfs is too former
- the most mattering is here:
hfs adapts itself automatically to the syntax chosen as the macro
As it everybody will find his preference there and the portability will be complete, and in case new creators had the other preferences they would be free to decide on the fact what is best advisable to them, because we arrived there here at an enactment of election campaign >:(
-
MODEL 6: the best NO CHANGE
Rejetto, where is the option to keep things as is?
I still don't like {.macro.} syntax. It's a strange use of periods and is the easiest of the choices to miss, especially if you write it nicely tabbed like Mars' examples.
{.if not|{.or|{.?p=1.}|{.?p=.}.}
|{:
{.for|B
|1
|{.sub|{.mul|{.^topic-limit.}| {.?p.} .} |25.}
|{:
{.set|topic-order
| {.cut|{.add|{.length|{.substring||;|{.^topic-order.} .} .}|2.}
||{.^topic-order.}.}
.}
.}
:}
.}
:}
.}
However, I do dislike option 4 the most, especially after TSG's example :)
-
a dot don't appears correctly .:.:.:.:.:.:.:.:.:.:.:.:.::.:.:.:.:.:.:.:.:.:.:.:.:.
i don't understand the meaning of this example, you'll never have such a thing :)
the other examples are very good.
anyway, consider that i doubt you will use this syntax for complex cases, because you'd better opt for
<?tpl {if|{or|{{?p}=1}|{not|{?p}}}||{\{for|B|1|{sub| etc etc ... tpl?>
this syntax will be available from #175
Rejetto, where is the option to keep things as is?
I don't want to keep it the way it is now, but you can try to change my mind if you wish.
I think we can consider this poll closed (no need to lock it).
-
I just noticed that inside your <?tpl , which is brilliant i might add, i can use it in several places. You quote using the old \ shouldn't quoting inside <?tpl be the same as outside? even tho you use short syntax inside there. It just an idea to continue the common language properties.
-
yes, quoting is the same as outside <?tpl