I had the idea of one click generated spritemaps for quiet a while, but never had time to look into it and kept going on manually creating them by online service for my projects. When I read an article about command line css spriting, I was amazed, how easy the map can be built using ImageMagick and that it’s even possible to read width and height from the images. Nevertheless, the automated generation of the css code was still missing. Especially when the icon order changes, this is still annoying work.
This made me think…we know how to create the spritemap and can also read the width and height of each sprite with ImageMagick, so the only thing that is left, is to cycle through the sprites, read width or height from them and write the css code to a file. Then I dig out some of my Windows batch skills and came up with the following little batch script. It’s not that easy to understand, so I made some comments on the relevant lines.
In my case the css is for custom icons in jQuery Mobile. This example only runs with all files in one folder, but paths can be adapted easily, as well as the css output. Also further image optimization with tools like optipng, as described in the mentioned article, can be easily added.
I Hope this makes someone as much happy as I are, finally having found a fully automated solution. For me it’s a perfect solution, because I already use batch-scripts to merge and pack all css and js files with one click in eclipse and I just had to add this script to my existing batch file.
CakePHP caching depends all on controllers and given arguments. But, what if you want different cache files for conditions that don’t come along with the arguments, like session variables?
In my case, I simply wanted separate cache files for each user of my app, because some actions deliver different views for different users, and I didn’t want to pass the User.id to each action in every controller that was concerned.
So I had a look into the CacheHelper and noticed that the file name for cache files is just build from the controller name and given arguments. First I tried to make a modified version of CacheHelper for my app. I don’t remember what problems I ran into, but it just didn’t work out very well.
Then I came up with the idea to internally manipulate the URL, just before the cache is read and written. Somehow this lead me to the lib/Cake/Routing/Filter/CacheDispatcher.php, where I needed just a few lines of additional code to put the User.id into place, which worked like a charm and had no side effects.
You have to copy the original lib/Cake/Routing/Filter/CacheDispatcher.php into your app app/Routing/Filter/UserCacheDispatcher.php and add the following lines of code. To put the dispatcher into action you finally have to register it in the bootstrap.php and replace the core CacheDispatcher.
I wonder why this use case is not supported by CakePHP out of the box, or didn’t I just see it? Well, I am aware that this might not be the best solution, but it is at least a pretty simple and effective workaround. Any ideas on how to solve the problem in better ways are welcome.
I stumbled upon the problem that some cached files in CakePHP took alot more space than expected, and I read about a similar problem on StackOverflow
Well, I took a deeper look into this and it looks like the serialized data in viewVars is used for the nocache parts of the view. So the solution should be to place the part where the base64 data is output between nocache tags.
<!--nocache--><?php echo $base64Data; ?><!--/nocache-->
But doing this, I had the effect, that on some views it worked, on others it didn’t. A closer look into CakePHP revealed, that preg_match_all() is used to look for the nocache parts, which cannot handle a very large amount of data (may depend on server settings) and only finds nocache parts up to a certain amount of data. It doesn’t even throw an error, wich I checked with preg_last_error(). I read about rising pcre memory limits, but it didn’t work for me, so I had to find another solution for that problem.
In my case image data was retrieved from database and placed base64 encoded within the view in an image src tag (src=”data:image/png;base64,…”). My solution was to replace the data in the image src tag with a link to an extra action that delivers just the image data and caches it seperately. This also has the advantage, that the image can now be cached by browsers apart from the view.
The first thing I did, was to care about the image data not coming with the find, in order not to get serialized in the viewVars. But I still needed the information about if there actually was an image in the data, which brought me to setup a virtual field in my model. The virtual field does the following, if there is image data present in the field it holds 1 (TRUE), otherwise 0 (FALSE).
For the image to retrieve and use, I setup an extra action without view in my controller and cached the data manually. Unfortunately you also have to care about deleting it when your model gets deleted or updated, but you can easily do that in the model save and delete callbacks.
In the view the image src looks like this:
<img src="/your_controller/image/<? echo $id; ?>" />
Another idea would be to generally unset the viewVars if nocache parts aren’t used in a view. But I don’t know where to hook in for that.
I came across the problem, that I needed a sub-ticket plugin for Trac v1.0. I found the SubTicketPlugin for TRAC on trac-hacks.org but also the ChildTicketsPlugin, that comes along with a very neat progress meter for parent tickets, but unfortunately is not yet available for Trac v1.0.
Because I wanted it so much, I searched for a way of having such a progress meter with the SubTicketPlugin. Then finally I found a way of building a site template for Trac, where the progress meter is displayed conditionally. It’s not that easy to understand and also uses some inline python code to cover all conditions, but it should work without further explanation. Just place the site.html in the /templates folder of your trac project.
I also developed a custom report, showing the tickets and their sub-tickets.