Wedge

Totally unrelated (again)... Would post in the 'These two bytes won't matter to you' topic, but I have a post to answer over there and if I post this, I'll forget about the other one ;)

I tried running minification processes on inline JavaScript. I took the media homepage as an example.

Running nothing: about .08s to execute the page
Running JSMin on the whole page: about 0.17s
Running Packer on the whole page: about 0.38s

Additionally, Packer tends to crash the page in some situations...
So JSMin is definitely the winner here.

However, it still doubles the time needed to generate the page... Which would be fine if it saved a lot of data, but it isn't the case.

Full page: 33759 bytes
Compressed: 32107 bytes

So it saves about 1.6kb...

Which is reduced to about 400 bytes after zipping the files.
About 4% saved on the full size.

I'm not exactly sure it's worth it... Sure, it's good for bandwidth (that's 400 bytes saved on *each* page load), but if it makes page generation twice more expensive... Not sure it's worth it.

Does anyone know of a PHP script that can compress JavaScript on the fly VERY quickly? And I mean, VERY?
I don't mind if it isn't optimized for size... I need something that optimizes for speed!

Hey, I knew about these too :P
Actually, the only reason I enabled the spellchecker on my server back in 2008 was to have that cool "maybe you meant..." at the top of the page.

Only problem -- 90% of the time, it suggests a totally stupid alternative to my perfectly working search term ;)

rev 1091
(17 files, 18kb)

* Layers used to have _above and _below functions. These have now been renamed to _before and _after, for simplicity. Please note that due to the peculiarity of layers, you can override or overload these two special functions, unlike the _before and _after that are attached to any block. See example in Welcome template. (Reports.php, Subs-Template.php, Welcome.php, TEMPLATES: Display, index, InfoCenter, ManageAttachments, ManageMedia, Media, PersonalMessage, PrintPage, Profile, Reports, Welcome, Wireless)

! Reports was using a layer with the same name as its contained block. Although technically it worked, it's bad practice. I should probably refuse adding blocks when a layer of the same name already exists... (Reports.php, Reports.template.php)

- A colon was stored in the language files when other strings on the same page stored it in the template itself. (Profile.language.php, Profile.template.php)

@ Note: I'm open to suggestions regarding a way to clarify the fact that template_layer_before() can be overloaded with template_layer_before_before() or _after(), while template_block_before() can't... :P

You can always try, but you'll have a hard time trying to offend me, given that I'm convinced that whenever you criticize me, it's because I deserve it, not because you want to offend me ;)...which, again, means we can't have both a topic=1.0 and a media album with ID #1. Creating a first album when topic=1.0 already exists will set the album ID to 2. And that's precisely one of the major blockers for me...Right now I'm staying at ::load(), waiting for feedback.Exactly... Except if you replace $blocks with array('layer' => array('block'), 'block2'), it's exactly the same except that we want to add another block right after the layer... So, technically, should Wedge behave completely differently (i.e. replace the contents of the layer rather than the layer itself) just because I added a block to the list...?

Working on replacing _above and _below with _before and _after... It's quite odd. Oh, and there's an even stranger one -- Reports.php has both a 'print' layer and a 'print' block. UH!

rev 1089
(4 files, 12kb)

+ wetem::load() can now process multidimensional arrays where sub-arrays are layers. New child layers should be properly indexed, too. (Boards.php, Display.php, Subs-Template.php, Welcome.php)

* Renamed a few ::layer options. 'replace' to 'rename' (because it's ultimately what it does), 'erase' to 'replace' (makes more sense), 'firstchild' to 'first' and 'lastchild' to 'add' (for consistency with ::load). Considering whether we should remove some of these options in favor of the use of ::load()... (Subs-Template.php)

I think I should feel offended... :lol:Then that's exactly the original definition of floating topics...Which also means we can't have both a topic ID of #1 and an album ID of #1. Or we have to ditch the id_topic key in favor of an (id_topic, board_type) key. Which I'm not sure would be as fast...?Definitely. I was still referring simply to the storing of data itself.A shorter wetem is what I'm looking at for now.Don't confuse me... :whistle:

I'm already confused enough with the merging (ahah) of ::load and ::layer... And actually I shouldn't do it, really. I think.

Take an example...

::load(array('layer' => array('block')), 'default', 'replace')

Okay, what do you do with this...?

- loadBlock() would do this: take the 'default' layer, empty it, except for its child layers. Then add the contents of the array to it. i.e. we would have <wrapper><default><layer><block /></layer></default></wrapper>.

- loadLayer() would do this: take the 'default' layer, and REPLACE it with the 'layer' layer. We would have this: <wrapper><layer></layer></wrapper>.

So, I went ahead and added a 'rename' value for ::load() not to get confused, but what to do in our example, where I'm providing contents for the layer? Should I also empty out the original layer and add data to it? Or should I just rename the layer, and don't bother with the provided contents...?
So much fun for me...

I guess I'll just keep the ::layer method for easy addition of container layers, like used to be done in SMF.
And I'll consider calls to ::load to be, well... Just a series of blocks.

Ah, it reminds me of the days when I would manually enter coordinates to generate my 3D objects in OpenGL for Kyodai Mahjongg... Was fun :P
Then I started generating my meshes with procedural methods. Just because I was unable to find a 'rounded corners cube' mesh on the Interwebs... Heck, I'm sure there are thousands of this online by now... But it wasn't commando-style!

rev 1087
(4 files, 8kb)

* Sorted the wetem methods to put the public ones at the front. Turned wetem into a final class and converted variables to private. Until we find a good reason to make wetem inheritable, it should remain locked from view. (Subs-Template.php)

* Commenazi. (Errors.php, Themes.php, Subs-Template.php, index.template.php)