Using the smc_toggle object with pure links?

[feline]

Yes, we using smc_toggle() for all collapse/expand functions (blocks, panels and other) and because each block is a oop class, we have always a unique id. And with the above change we can all insert just before the </body> tag.
That works perfect and save a lot of code in the templates 

One word to the funcOnBeforeCollapse, funcOnBeforeExpand ..
Because the attached function run in the object context, you can access any member value in your function like if(this.opt.bToggleEnabled) {doing is the toggle enabled}

Fel

[bloc]

Ah, I didn't know that, thanks for the tip.

But one question..if you save upshrink value for every block, wouldn't that be a enormous amount of data saved in the {db_prefix}themes table..? Let say you got 5000 members, and about 20 blocks, that alone would mean theoretically 100k of entries..

I am sure it will never be that much, stats show only a slight percentage of members really use it in full, but nevertheless. I arrived at the conclusion that saving all {20} blocks in a cookie takes no space at all(on server), can be different on different machines for each user, and do not add to the db queries. The only drawback is that it won't remember if you remove the cookie or move to another machine - but then again upshrinking the blocks aren't vital for the UI experience. Nor animating the upshrinking itself lol, which some seem to think it is.

[Arantor]

Yeah, it's really geared to handling multiple panels to be closed in a single press and/or multiple link items to update for the upshrink panels, meaning you can have a hide/show at the top and bottom of the page for example.

[bloc]

With the right concept I imaging it could actually transform a page totally, without the need for reloading the page. For example, press a login link, and the big(ish) login quick-login appear.

It can't handle multiple states I guess?

[Arantor]

No, it is literally a switch of states, but it probably wouldn't be *that* hard to butcher into supporting multiple states. Add something to deal with needing the extra data, and extending the method (changeState) to instead of toggle bCurrentlyCollapsed, have it track in this.opts.iCurrentState (integer, not boolean) and cycle through the states there.

[feline]

But one question..if you save upshrink value for every block, wouldn't that be a enormous amount of data saved in the {db_prefix}themes table..? Let say you got 5000 members, and about 20 blocks, that alone would mean theoretically 100k of entries..

Yes .. thats is heavy .. I think, we would move that to cookies ...

Fel

[Arantor]

And that's exactly why you have the power to pick which it is you set up.

[feline]

we have moved all toggles to cookies .. works perfect, is quicker and save many hundreds records in the table (we remove all collapse entrys) 

Fel

[feline]

One problem with the cookies for smc_toggle ..
The cookies are path dependent .. that's not good and I have changed that.
Can the developer that fix for next release please?

See my next post

Fel

[bloc]

One problem with the cookies for smc_toggle ..
The cookies are path dependent .. that's not good and I have changed that.
Can the developer that fix for next release please?

Fel

I don't think the SMF devs gonna notice this topic that much lol, try writing the suggestion in the Bugs board perhaps?

[feline]

you are right .. but I verified that more and see that's not a smf bug .. it's produced be SimpleSEF, so I have to call the author about that .. 

Fel

[Arantor]

*roll eyes* Another issue *sigh*