ope=minv and if. then, else

Does ope=minv also respect the if something; then '1'; else '' values? This doesn't seem to be the case?? Why is that?

It would be really usefull when I check a boolean value and 0 should lead to field removal, but '0' isn't ''....

suppose example = 0
field needs to exist only when example = 1
<span>[onload.example; if '[val]' = '1'; then '1'; else ''; magnet=span; ope=minv]</span>

This doesn't work, because the magnet parameter seems to check the [val], rather then the output of the field when ope=minv is set...

Adding ope=minv also breaks the magnet type. mtype=m+m does not remove just the tags, is has no effect. On an empty value ope=minv

I've looked through the code and found the problem:

At about line 1155 I've changed:
Into:

With that change the logic adds up for as far as I can see. Works perfectly for me now :)

Can you change this in the source?

Whoops; the if; then; else problem is not solved yet. I've only solved the magnet problem

I've found the problem; the minv operator changes the value before the if then else structure is tested. The if statement tests the empty value set by the minv operator. I'll try to come up with a simple solution...

Ok, I've figured it all out. To me it makes most sense if minv clears out the value at the end and does not change the expected behaviour. To obtain that I have done two small changes on top of the change I posted earlier in this thread:

I removed [976]: $Loc->OpeAct[$i] = 8;
I removed [1032]: case 8: $Loc->MInvOk = ($CurrVal!==''); $CurrVal = ''; break;
I added before 1134 (if ($CurrVal==='') {):
Together with the other change this operator no longer interferes with previous behaviour.

I'd like to add that the other operators might have to be moved as well because they make changes to the value even before it can be tested...

The manual says that ope=minv clears the value but magnet will consider old value, with my changes that is actually correct and the magnet remains as it was without ope=minv, so I hope that this will be considered a bug and changed :)

Hi Rwd,

Thank you very much to have posted this bug before TBS version 3.5.0 is released.

Your fix is working and is smart because it let other parameters (like "if") to take advantage of the not null value. But making a check on $Loc->MInv each time the merged value is null can be quite costly in time. I'll try to find another solution.

As you notice and as it is documented, parameter "ope" is processed before parameter "if". Therefore, [val] is always null for a "if/then/else" after a "minv". Your new code does not has this inconvenient.

By the way, I was also thinking about two parameters (let's say "m_v" et "m_i") that let the magnet visible (or invisible) only for one value.
Example: <div>[var.x;ope=m_i:0;magnet=div]<div>

Hi Rwd,

Thank you very much to have posted this bug before TBS version 3.5.0 is released.

Your fix is working and is smart because it let other parameters (like "if") to take advantage of the not null value. But making a check on $Loc->MInv each time the merged value is null can be quite costly in time. I'll try to find another solution.

As you notice and as it is documented, parameter "ope" is processed before parameter "if". Therefore, [val] is always null for a "if/then/else" after a "minv". Your new code does not has this inconvenient.

By the way, I was also thinking about two parameters (let's say "m_v" et "m_i") that let the magnet visible (or invisible) only for one value.
Example: <div>[var.x;ope=m_i:0;magnet=div]<div>

I might have put the MInv in the wrong spot, if you put it inside the else block right before it is only evaluated when currval !== ''. That already helps a tiny bit, but it there can also save time by not having to do the str_replace if MInv is set.

I never realised, but does checking if a certain variable is set take that much time??

The extra magnet things you want to introduce are the equivalents of if '[val]' != '1'; then ''; and if '[val]' = '0'; then ''; Perhaps they process a bit faster, but I do not understand why they are needed. There is a plugin tbsplus which does a lot of operators that are usefull (including the invisible magnet thing you introduced as minv). Since I am using the plus plugin anyway I might as well use those functions, but I prefer the built in functions you made...

ps, glad to have helped a bit, even though you still need to take a look at it to make my solution more efficient

Hi RwD,

I've made the fix for your bug on the current beta RC which is available for download.

I'll make some benches to test for a smarter solution which could also support the other features I've described above.

Thanks again,

I look forward to seeing how you solved it. Performance will of course always be a problem. But I have no time for testing right now...

I've made some benches :
Replacing with

actually costs + 0,30% of time of the merging process (regardless of PHP 4 or PHP 5).

If you add e new check like (isset($Loc->MyProperty)) or ($x==='something') in the global scope of meth_Locator_Replace() it will cost about 1%, which is few but something.

Is there no more efficient way to code that entire function? Or is this already as short as it can be? Also, I do not know (because I didn't check) how you locate certain elements and all. I remember that I once discovered a component for Delphi that searched text a whole lot faster because of more efficient algorithms then Delphi functions had built in standard. If you do not use such optimized algorithms yet, most improvement lies there?

Searching TBS items and analyze their parameters is something quite fast in TBS. I don't use any preg functions, all is direct string search. That part is stable and several times optimized.

Processing parameters of the items is something more delicate. They are several ways to do it, I've chosen to try the existence of each root parameters ("if" is root, "then"/"else" are not root). Parameter "ope" is designed to be a root one with many child.