The documentation for the SonataAdminBundle mentions how to expose services inside your Admin class using XML:
But unfortunately it doesn’t detail how to do it YAML. Turns out its pretty straightforward, the “gotcha” of course being you need to add the “@” to indicate a service:
Recently we were using Behat on a new project with the Symfony2 extension. It took a bit to get it up and running correctly as the docs (for the extension setup) seem to be incorrect. First place the behat.yml directly in the project root. Second, when using the “@” notation to reference your bundle you need to be sure to enclose it in quotes. For example, ‘bin/behat –init “@MyBundle”‘. Without the quotes it will not be parsed correctly and will not setup the structure as you want.
If you are running into the following error:
Most likely the initial setup didn’t go correctly. We kept having that issue whenever we added the behat.yml to our root directory, but then didn’t use the quotes to enclose the @MyBundle. Hopefully this saves you the headache!
I’ve shot over a pull request to the main behat repo for the extension so it hopefully will be fixed soon:
Happy testing!
A few days ago, a friend of mine reached out asking for a good solution for securely transferring a relatively large (~1GB) file to several of her prospective clients. Strangely, even in 2013 the options for transferring such a large file in a reliable manner is pretty limited. I looked into services like YouSendIt, WeTransfer, and SendThisFile but they all suffer from similar limitations. Most of them have a <1GB file size limit, their payment plans are monthly subscription based instead of pay as you go, and they don’t offer custom domains or access control. Apart from these services, there is also the trusty old school option of using an FTP server but that raises the issue of having to maintain your own FTP server, using a non-intuitive FTP client, and still being locked into paying a monthly fee instead of “pay as you go". Stepping back and looking at the issue from a different angle, it then became clear that the S3 component of Amazon’s Web Service offering is actually an ideal solution for this problem. The S3 piece of AWS is basically a flexible “cloud based” storage solution that lets you programmatically upload files, store them indefinitely, and then serve them as you please. Looking at the issues we’re trying to overcome, S3 satisfies all of them out of the box. S3 has a single file size limit of 5 Terabytes, files can be served off a custom domain like archives.setfive.com, billing is pay as you go depending on the resources you use, and S3 supports access control so you have fine grained access over who can download files and for how long. So how do you actually use S3?
Anyway, thats a quick rundown of how to use Amazon’s S3 service for file transfers. The pricing is also *very* cheap compared to traditional “large file transfer” services.
Check out some other useful links about S3:
A few days ago I ran across 2012: A Year in PHP which is a blog post highlighting what changed in PHP during 2012 and what upcoming changes we can expect in 2013. The post sparked a lively discussion on Hacker News which unfortunately basically devolved into a mix of anti-PHP rants and some “meta” commentary. Anyway, as someone that uses PHP daily I started thinking about what irks me about PHP and what would fix it. Thinking through the issues, it feels like fixing PHP’s type system by making primitives real objects would significantly improve the readability, consistency, and attractiveness of the language.
This one is subjective but I think one of the reasons that PHP code looks so ugly is because the procedural array_* and str* functions look jarring mixed in with object oriented code.
Check out this snippet from the Doctrine ORM framework. Even though the code is “object oriented” and nicely spaced, the array_* and str* functions are a serious eye sore. In addition to looking “off”, the procedural functions have inconsistent argument ordering which leads to “needle or haystack?” bugs.
So what would I switch to? How about a fluent interface replacement for the array and string functions that operate as if they were real objects.
PHP arrays are in a funny place in terms of how they interact with the standard library and the syntax of PHP. Arrays in PHP are a primitive type and they are arguably the de-facto data structure for most PHP applications. Like strings though, arrays aren’t objects so programmers are stuck using the procedural array_* functions to manipulate arrays. Similar to above, if they were actually objects we could do away with the procedural functions and manipulate arrays with object oriented style functions.
Another array related issue is “foreach hell”, a situation where the easiest way to accomplish a few array related tasks is to run a “for each” over the list which then leaves the code with a tangled mess of collection variables and for each loops of varying lengths. PHP has array_* functions to mitigate this but it wasn’t until the proper introduction of closures and anonymous functions that they became practical to use. Unfortunately, since arrays aren’t objects you can’t really chain any of the functions and the code ends up looking as bad if not worse. If arrays were actually objects, PHP code could easily adopt functional techniques like Javascript’s UnderscoreJS which are usually cleaner and easier to follow.
Compounding the “foreach” issues is the existence of the Iterator interface which allows PHP classes to specifcy that they can be traversed using a foreach loop. This introduces a frustrating limitation in the sense that you can make an object “look” like an array but since the array_* functions only operate on the primitive array type, you can’t leverage any of them on iterable objects. If arrays were actually objects, additional interfaces could be specified to allow some subset of the array_* functions to work on a given class.
In true PHP fashion, arrays as objects actually “sort of” exist within the Standard PHP Library (SPL) Datastructures extension. The SplFixedArray provides a fixed length, integer only array data structure that is actually a PHP object. The problem is you can’t easily just “switch” between using an array versus one of the SPL data structures since they aren’t subsets or supersets of regular primitive arrays, they are PHP classes making them difficult to convert between.
Unlike Java or Javascript, PHP objects don’t all “share” or extend from a common ancestor. In Java, every object extends the Object class and in Javascript every object is connected in the Prototpe chain to the Object prototype. What this shared inheritance fosters is that generic programming is significantly easier because introspection and reflection is more straightforward. Comparatively, check out PHP’s Reflection class to see how much of a disaster introspection and reflection in PHP.
Unfortunately, I don’t know anything about how primitives PHP types work internally so I can’t speak to how difficult it would be to implement these changes. From a compatibility standpoint, it would naively seem like these changes could be made without seriously breaking backwards compatibility while slowly phasing out the old primitive types. On the whole, as long as we don’t end up with Java’s type boxing issues I think we’ll be in a much better place with PHP as a language.
Earlier today, I was adding a “slider” UI element to a project that was using Twitter Bootstrap as well as jQuery UI. Although they weren’t designed to work together, the two projects generally stay out of each other’s way since their CSS classes are namespaced pretty well.
Since jQuery UI was already loaded I naturally decided to just use the jQuery UI slider control to power the slider. One of the limitations with the jQuery UI slider is that it has no native way to show the current slider value over the slider handle, as a developer you have to display that number somewhere. Fortunately, the control has the event hooks neccesary to make this happen – specifically the slide event which is triggered everytime the slider is moved.
With Bootstrap also loaded, I decided to try and use the tooltip plugin to dynamically display the current value of the slider above the handle. Getting the initual tooltip setup was pretty straightforward. Check it out here.
But the issue is that even with the “slide” event, the Bootstrap tooltip plugin has no exposed method to force a reposition. The only way to get a tooltip to reposition itself is to hide it and then show it again. Obviously, that’s less than ideal since you get a noticible “jump” as the tooltip is hid and then shown again.
With this issue in mind, I decided to take a look at how the Tooltip plugin actually does the positioning. It turns out it’s really simple, the relevant code is on GitHub. Ok, so its easy to reposition them but how do you get the “right” tooltip div incase you have multiple sliders? Looking through the code, the Tooltip plugin actually uses the jQuery.data() function to store config options and additionally stores a reference to the correct div there. Getting a handle to the correct div is as easy as $(“#slider .ui-slider-handle:first”).data(“tooltip”).$tip
Looking at the actual plugin code, it’s simple enough to just copy that out and use it to reposition the tooltips. Check it out in action at http://jsfiddle.net/cqVPM/7/
Anyway, let me know if you run into any issues in the comments.