ProcessWire Cheatsheet

[ryan]

I'm enjoying the animation here. Though if it were slow I probably wouldn't. But seems to be flying (in Chrome 20): very fast and smooth and just plain fun to use. I get a foundation building block feeling out of this (especially switching in/out of 4-col), and it relates well to ProcessWire as a builders tool.

Sometimes it's hard to tell with animation whether it's best for long term. I remember my first exposure to the things going on in OS X and then iOS made me think I'd get annoyed with it. But it grew on me and made me enjoy using it more. Some of the animation in Windows was quite the opposite. Time will tell what the case is with the cheatsheet, and I may be wrong, but thinking it may grow on folks that aren't sure about it. Some of this is eye candy, but it's of the kind that attracts people and makes us look good, IMO. Either that, or I'm just really impressed because I've never seen anything like this before.

[Soma]

I'm kinda with Ryan. I really like the animation and it has the right speed. It depends a little on the browser as it's done with css transitions. Making it even faster will not help but make choppy (depends on how many elements are animated). But I agree it would be nice to turn it off if one likes. So it is very easy to add another option to disable it. Will push an update later.

[apeisa]

Soma, no option to disable / enable animations. If someone doesn't like it, build a monkeyscript or something to disable it. I would say that even the column # option is "little too much", would be nicer to have right amount of columns based on screen width. In other news: I really like the new improvements!

[slkwrm]

Yeah, maybe I'm too hardcore here. I turned off most of Windows 7 eye candy at first, but some time later I turned on Aero Peek and transparency back . XP was ugly but it was fast! Now every time I see it I wonder how could I use it for so many years.

Soma, it would be great to have this animation switch option. I thought there will be a long discussion before this change could be made. And with this on/off option everybody's happy! Thank you!

Edit:

@Apeisa. Sorry, didn't see your reply. Yes, using a browser script is another good way to handle it, especially if this change is hard to implement. Thank you for this idea.

[ryan]

I would say that even the column # option is "little too much", would be nicer to have right amount of columns based on screen width.

I've found the column choice valuable for getting a different view on things. When you've got 4 columns, you can see a lot at once, but maybe you don't want to get too much into details or copy/paste because, depending on length, you may get wrapping like this:

$page
->setOutputFormatting(true|false
)

That's perfectly okay and expected, but for me the advantage of being able to reduce columns is that I can eliminate wrapping when I want/need to.

[Martijn Geerts]

Think you make a mistake with the 1.1 update, it should be way higher Really enjoy the isotope transitions, think they are GPU processed to. To select the cols is a big plus. Think I gonna love the narrowness of one column select! Screen pixels are expensive

Hope to start next week with the first project in PW.

[Soma]

Ok I just pushed an update. You can now disable transitions.

I will at some point hide the additional options in a hidden settings layer. I will still have to see what I'll do with additional stuff. I also see adding some that's left off in the same sheet and give them a color code like advanced. Adding additional sheet that can be switched would aslo be nice, but not as trivial as it seems.

[slkwrm]

Thank you for this update, Soma! Having tried both modes, with and without transition, I can tell I definitely prefer the latter

[diogo]

There is something funky happening with the cheatsheet. It's working fine on Soma's Github.

Edit: for those that need it, here is the link http://somatonic.github.com/ProcessWireCheatsheet/

[ryan]

PW pulls this from GitHub directly and caches it for a period of time. It looks like GitHub gave us a page with a meta redirect in it on the last pull... I'm guessing it was a "GitHub is down, try again" type thing that reloads itself. Anyway, I cleared the cache and that seems to have fixed it. Thanks for letting me know.

[diogo]

I thought of updating my bookmark to github but I will keep it like this so I can tell if it happens again

[apeisa]

It's all crazy again, in redirect loop with itself (I assume). This is the page source:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="0.1">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<TITLE></TITLE>
</HEAD>
<BODY><P></BODY>
</HTML>

[Soma]

I logged in and saved the page, it's back now.

[Wanze]

Maybe a useful addition:

$sanitizer->entities()

Cheers

Btw the cheatsheet is the best API overview/explanation ever seen!

Thanks for making this.

[ryan]

Soma, once we've got 2.3 as the current stable version out there, I'll go through the cheatsheet and figure out what needs to be added, etc. 

[k07n]

Found little typo in main.js

Here is the pull-request https://github.com/somatonic/ProcessWireCheatsheet/pull/1

[ryan]

Thanks k07n, I have applied that update. 

[k07n]

Hi! It's me again.

$('.section:not("#index") h3').bind('click', function(){
        var parent = $(this).parent('.cat');
        if( parent.find('.descr:visible').length > 0 ) {
            parent.find('.descr').slideUp( animated ? speed : 0, function(){ $container.isotope('reLayout'); });
        }
        else {
            parent.find('.descr').slideDown( animated ? speed : 0, function(){ $container.isotope('reLayout'); });
        }
    });
 

There is no need to callback reLayout on slide.

$('.section:not("#index") h3').bind('click', function(){
        var parent = $(this).parent('.cat');
        if( parent.find('.descr:visible').length > 0 ) {
            parent.find('.descr').slideUp( animated ? speed : 0 );
        }
        else {
            parent.find('.descr').slideDown( animated ? speed : 0 );
        }
        $container.isotope('reLayout');
    });
 

This little change insanely increase speed.

[Soma]

Thanks for the suggestion k07n. But the code you removed is there for a reason. I see how this might affect performance (haven't spent too much time with it) but it's needed to rearrange the boxes when you click on the red titles to toggle the descriptions or you will end up with overlaying stacked boxes. Maybe there's another way to archive it but haven't looked into it.

[k07n]

Thanks for the suggestion k07n. But the code you removed is there for a reason. I see how this might affect performance (haven't spent too much time with it) but it's needed to rearrange the boxes when you click on the red titles to toggle the descriptions or you will end up with overlaying stacked boxes. Maybe there's another way to archive it but haven't looked into it.

I move $container.isotope('reLayout'); under IF, so isotope will rearrange hidden boxes.

[Soma]

Sorry I missed that somehow. But it doesn't work, it messes up the layout even more! As I said it's there for a reason to relayout ispotope after the animation is done. It doesn't happend when animation is disabled but when it's on. So there would have to be a separate if to only do it that way when animated is enabled.

[Soma]

Ok I see now the problem is that for every description slideUp there's a callback call to relayout. When it's enough to call it once after all have completed. I'll fix this. Thanks for finding it.

[k07n]

Yeap, you right.

I use 'straightDown' isotop layout in my project and only css animation, maybe thats why its works fine for me.

[Soma]

No problem.

I fixed the callback issue now with:

$('.section:not("#index") h3').bind('click', function(){
    parent = $(this).parent('.cat');
    if( parent.find('.descr:visible').length > 0 ) {
        parent.find('.descr').slideUp(animated ? speed : 0).promise().done(function(){ $container.isotope('reLayout'); });
    } else {
        parent.find('.descr').slideDown(animated ? speed : 0).promise().done(function(){ $container.isotope('reLayout'); });
    }
});

[diogo]

I would say the ideal here would be to drop isotop and build the columns based on the amount of <p>s (cells). Coming from my head as I write: let's say in the markup we have the three columns, but all the <div class="section"> (sections) are in the first. We count all the <p>s excluding the advanced 

$('#container p').not('.advanced').count()

 and divide them by 3. Then we take that number, identify to which .cat it belongs to, select all the <div>s that come after it, and append them to the next column

$('#container p').eq(result).closest('.section').nextAll().appendTo('#second-column')

Do the same with the second column, but this time appending the rest of the <p>s to the third column.

If the advanced option is selected, do the same without excluding the .advanced class.

The sections would have position relative and the dropdowns would affect the following elements naturally. There also would't be changes of position of the sections while opening and closing the things.

edit: changed .cat to .section, as it makes more sense