rejetto forum
Software => HFS ~ HTTP File Server => HTML & templates => Topic started by: Mars on February 20, 2009, 12:19:27 AM
-
main.pas
if name[1] = '!' then
try result:=or_([fromTable('special:strings',p), md.tpl.getStrByID(p), par(0), p]) except end;
1)Bad formulation, cannot absolutely work except by correcting as follows
if name[1] = '!' then
try result:=or_([fromTable(md.tpl['special:strings'],p), md.tpl.getStrByID(p), par(0), p]) except end;
2)But it is not still sufficient:
function fromTable(tbl, k:string):string; //transformed by mars
var
i: integer;
h: THashedStringList;
begin
result:='';
i:=pos(CRLF,tbl);
if i>0 then
begin
h:=ThashedStringList.create();
h.Text:=tbl;
result:=dequote(h.Values[ k ]);
h.Free;
exit;
end;
i:=md.cd.vars.indexOfName(tbl);
if i < 0 then exit;
h:=md.cd.vars.Objects[ i ] as THashedStringList;
if h = NIL then
begin
h:=ThashedStringList.create();
h.Text:=md.cd.vars.valueFromIndex[ i ];
md.cd.vars.Objects[ i ]:=h;
end;
result:=h.Values[ k ];
if (tbl = 'ini') and (result = 'no') then result:='';
end; // fromTable
And so, everything works marvelously.
***********************************
Some correctives sometimes bringing novelties, here is three macro with current tastes to multiply their possibilities of use:
.....
var
i: int64;
j:integer;
begin
try
try
assert(assigned(cbData), 'cbMacros: cbData=NIL');
md:=cbData;
.......
if name = 'set' then //mod by mars
begin
result:=CRLF;
if pars.count=2 then result:=dequote(par(1))
else for j := 1 to pars.Count - 1 do result:=result+dequote(par(j)+CRLF);
setVar(p, result);
result:='';
end;
if name = 'set append' then //mod by mars
begin
result:=CRLF;
if pars.count=2 then result:=dequote(par(1))
else for j := 1 to pars.Count - 1 do result:=result+dequote(par(j))+CRLF;
if satisfied(md.cd) then setVar(p, md.cd.vars.values[p]+result);
result:='';
end;
if name = 'from table' then //mod by mars
begin
result:=CRLF;
if (pos('=',p)>0) or (pars.count>2) then
for j := 0 to pars.Count - 2 do result:=result+dequote(par(j)+CRLF)
else result:=p;
result:=fromTable(result, par(pars.Count-1));
end;
With in example: how to use the possibilities
<hr>
{.!marco.}
<p>
{.!mars|{.from table|{.section|special:alias.}|mars.}.}
<hr>
{.set|midas|pot1=vert|pot2=jaune|
pot3=rouge
pot5=violet|pot4=noir.}
{.set append|midas|pot6=marron|
pot8=blanc
pot9=orange.}
{.from table|midas|pot5.}
<p>
{.from table|{.^midas.}|pot8.}
<hr>
{.from table|{.load|hfs.ini.}|listen-on.}
<hr>
{.from table|marco=rapido|tata=valou|tartare.}
<p>
{.from table|
marco=rapido
tartare=valise
|marco.}
<hr>
{.from table|{.section|special:alias.}|mars.}
<hr>
{.from table|{.section|special:alias.}|marco.}
[special:alias]
marco=mars-alias
tartare=valise
mars=tatoo
never=boubou
[special:strings]
marco=mars-strings
you can use this little template with the french build 224 to see result as
--------------------------------------------------------------------------------
mars-strings
tatoo
--------------------------------------------------------------------------------
violet
blanc
--------------------------------------------------------------------------------
127.0.0.1
--------------------------------------------------------------------------------
rapido
--------------------------------------------------------------------------------
tatoo
--------------------------------------------------------------------------------
mars-alias
-
1)Bad formulation, cannot absolutely work except by correcting as follows
fromtable works on variable names, and that's what i'm passing.
i see it is not very clear, so i will add this comment in the source
// we look for p (they key) in {.^special:strings.} then in [special:strings]. If no luck, we try to output an eventual parameter, or the key itself.
if name = 'set' then //mod by mars
if name = 'set append' then //mod by mars
i think you burned out all parameters of these macros to gain very very little functionality.
if name = 'from table' then //mod by mars
aside the comment above, here you are duplicating the functionality of {.switch.} but the syntax is not much handier
-
1)Bad formulation, cannot absolutely work except by correcting as follows
fromtable works on variable names, and that's what i'm passing.
i see it is not very clear, so i will add this comment in the source
// we look for p (they key) in {.^special:strings.} then in [special:strings]. If no luck, we try to output an eventual parameter, or the key itself.
what would you think about testing this line in main.pas,
try result:=or_([fromTable('special:strings',p), par(0), p]) except end;
the beautiful theory of the fromTable('special:strings',p) falls then to the water.
The only reason for which the transcription of call of variables {. Var.} work is only possible by the presence of
md.tpl.getStrByID(p)
********************************
To be able to use the macro ' from table ' it is compulsory to spend by macro 'set' and the associated variables, my version of this macro allows the users to spend the other values, but it is sometimes boring to use one macro 'set' with 150 lines in the continuation, while by separating every line by one' |' , we can write it on one or several lines
{.set (append)|midas|pot1=vert|pot2=jaune|
pot3=rouge
pot5=violet
pot4=noir.}
With the current limitations which are imposed, it is compulsory to pass by:
{.set (append)|midas|
pot1=vert
pot2=jaune
pot3=rouge
pot5=violet
pot4=noir
....
// after a very very long time ;D
....
pot175896= It is still far the end of the file? ;).}
{.from table|midas|pot175896.}
OUF! It is finish
Then, Who prefers to can use always:
{.set (append)|midas|pot1=vert|pot2=jaune|pot3=rouge|pot5=violet|pot4=noir
....
pot175896= It is not still far the end of the file ;).}
or sometime:
{.from table|pot1=vert|pot2=jaune|pot3=rouge|pot5=violet|pot4=noir
|pot3.}
and why not the possibility:
{.from table|{section|mysection|myfile.}|valuesearch.}
using [special:string] is caching. if this section is changed we can see only old values, not the refresh:
My propositions are not contradictory to the exsistant, and can bring a little of freshness in the macro, I do not understand your hesitation.
aside the comment above, here you are duplicating the functionality of {.switch.} but the syntax is not much handier
I shall thus end by a quetion,without expectation of answer ;):
Why to use the macro MOVE, while we have COPY and DELETE who combined together make the same work
-
what would you think about testing this line in main.pas,
try result:=or_([fromTable('special:strings',p), par(0), p]) except end;
the beautiful theory of the fromTable('special:strings',p) falls then to the water.
The only reason for which the transcription of call of variables {. Var.} work is only possible by the presence of
md.tpl.getStrByID(p)
getStrByID() makes the [section] work.
fromTable() makes the {.^variable.} work.
so, since you removed getStrByID, even without testing i guess the variable will work and the section will not.
I just tested this in the last build, and it is working as expected
{.set|special:strings|
a=1
b=2
c=3
.}
{.!b.}
this is 3.
i don't understand if you are trying to report a bug or not. If yes, please provide a way to reproduce it (what you do, what you get, what you expected).
To be able to use the macro ' from table ' it is compulsory to spend by macro 'set' and the associated variables, my version of this macro allows the users to spend the other values, but it is sometimes boring to use one macro 'set' with 150 lines in the continuation, while by separating every line by one' |' , we can write it on one or several lines
if you feel uncomfortable with too many lines, you may solve it with a user-macro that will replace a string you decide with the newline.
if this cannot be done, we can work on it.
{.from table|pot1=vert|pot2=jaune|pot3=rouge|pot5=violet|pot4=noir
|pot3.}
this is the {.switch.}
and why not the possibility:
{.from table|{section|mysection|myfile.}|valuesearch.}
you just have to {.set.} first.
if you don't like the double step, you can {.set.} your macro (or maybe an alias)
using [special:string] is caching. if this section is changed we can see only old values, not the refresh:
changed? how? can you make an example?
My propositions are not contradictory to the exsistant, and can bring a little of freshness in the macro, I do not understand your hesitation.
i think i'm replying point by point to your statements. if there's any of my replies that's not clear to you, just tell me which one, i can try to reword.
I shall thus end by a quetion,without expectation of answer ;):
Why to use the macro MOVE, while we have COPY and DELETE who combined together make the same work
is move always the same as copy+delete? answer: no. ;)
-
Quote
{.from table|pot1=vert|pot2=jaune|pot3=rouge|pot5=violet|pot4=noir
|pot3.}
this is the {.switch.}
I do not believe that their functionings are identical same if under the shape which I propose they get closer to it but in a very particular case.
You cannot use
{.from table|pot1,pot10=vert|pot2,pot20=jaune|pot3,pot30=rouge|pot5,pot50=violet|pot4,pot40=noir|pot3.}
with the same result as
{.switch|pot3|,|pot1,pot10|vert|pot2,pot20|jaune|pot3,pot30|rouge|pot5,pot50|violet|pot4,pot40|noir| elsevalue.}
Which gives a result by default if there is no correspondence.
****************************************************************
{.set|special:strings|
a=1
b=2
c=3
.}
{.!b.}
this is 3.
i don't understand if you are trying to report a bug or not. If yes, please provide a way to reproduce it (what you do, what you get, what you expected).
This is a particular use for the case of the variable {.set|special:strings|.... as a masqued possibility,
I know nobody who would have had the idea to use it because the section foreseen for that exists. Excepted maybe TSG? :D.
If you modify the fromtable() procedure as I proposed it, then we can amputate the code of fromtable('special:string') and use correctly with the same result :
{.set|special:strings|
a=1
b=2
c=3
.}
{.from table|{.^special:strings.}|b.}
******************************************************************
Quote
using [special:string] is caching. if this section is changed we can see only old values, not the refresh:
changed? how? can you make an example?
It has to correspond certainly to an old ghost bug which I had owed noticed in a previous build, I did not manage to reproduce, certainly corrected involuntarily since the build 222 with its big modifications, I shall experience with more hurdy-gurdies versions to confirm my error.
******************************************************************
Quote
To be able to use the macro ' from table ' it is compulsory to spend by macro 'set' and the associated variables, my version of this macro allows the users to spend the other values, but it is sometimes boring to use one macro 'set' with 150 lines in the continuation, while by separating every line by one' |' , we can write it on one or several lines
if you feel uncomfortable with too many lines, you may solve it with a user-macro that will replace a string you decide with the newline.
if this cannot be done, we can work on it.
Quote
and why not the possibility:
{.from table|{section|mysection|myfile.}|valuesearch.}
you just have to {.set.} first.
if you don't like the double step, you can {.set.} your macro (or maybe an alias)
It is true that we can always create alias from other alias, but it extends the length of the template and increases the possibility of errors, while to spread the possibilities of certain macro can allow certain forms of use to determine more quickly where can be an error which we would manage not to encircle at normal time.
I thus maintain my demand, indeed by reminding that it modifies not at all the normal functioning of the macro current.
*******************************************************************
Quote
I shall thus end by a quetion,without expectation of answer :
Why to use the macro MOVE, while we have COPY and DELETE who combined together make the same work
is move always the same as copy+delete? answer: no.
Set apart a remainder of the file in the local recycledbin, from the point of view of hfs the result is identical ;)
-
You cannot use
{.from table|pot1,pot10=vert|pot2,pot20=jaune|pot3,pot30=rouge|pot5,pot50=violet|pot4,pot40=noir|pot3.}
with the same result as
{.switch|pot3|,|pot1,pot10|vert|pot2,pot20|jaune|pot3,pot30|rouge|pot5,pot50|violet|pot4,pot40|noir| elsevalue.}
Which gives a result by default if there is no correspondence.
so? i don't understand where's your point... in your example fromtable is losing over the switch.
be clear, what is offering your {.fromtable.} more than the {.switch.} to make us think that it's worth?
This is a particular use for the case of the variable {.set|special:strings|.... as a masqued possibility,
I know nobody who would have had the idea to use it because the section foreseen for that exists. Excepted maybe TSG? :D.
the benefit is that variable are dynamic, and can be changed, while sections are not.
you can load the language text externally, as many softwares do. i think this can be very useful.
If you modify the fromtable() procedure as I proposed it, then we can amputate the code of fromtable('special:string') and use correctly with the same result :
{.from table|{.^special:strings.}|b.}
{.!b.} is way much shorter, and a lot faster (because it's caching the structure).
so, why the hell should i want to use something longer and slower?
It is true that we can always create alias from other alias, but it extends the length of the template and increases the possibility of errors,
this is not the good way to go.
keeping the core to the minimum is quite important, and additions should be weighed, not just added.
your reasons are: to write 1 line less in the template. it's not enough in my opinion.
is move always the same as copy+delete? answer: no.
Set apart a remainder of the file in the local recycledbin, from the point of view of hfs the result is identical ;)
i don't understand. try rewording.
-
I could clearly see that you missplaced a comma up there mars :) ;)
Armin_van_Buuren_-_Imagine_The_Remixes-WEB-2009-TPRoxxTheHouse 09(06:07:00)