Convenience over configuration (not instead of)
Obviously I was asked why I haven’t done all that withing the already existing FacebookBundle which is multi purpose of which a canvas app could be just one.
The simple reason is: I couldn’t get it to work for me the way I wanted.
The slightly longer explanation is: I was overwhelmed by the sheer number of possible combinations of the security component even withing the FacebookBundle and for most of the time I didn’t understand what I was doing.
After endless hours of trying the only way I could think of was starting from scratch implementing my requirements within controllers and templates and then start refactoring it down to the security layers.
My bundle should now be a simple drop-in solution with very little configuration and no obvious possibilities of settings. Still you can if you want ignore the security pre-configuration of it and do your own if you feel expert enough. But that’s where bundles responsibilities will end and you will be on your own.
However I think that CaeferFacebookCanvasAppBundle can still be merged into FacebookBundle. To keep the convenience value the following two things should be done.
- For each use case there should be a recipe documentation that starts with an abstract of its objective and then moves on to explain what needs to be done to make it happen.
- For each of those use cases the usual configuration should exist as a preconfigured settings file that can simply be included and then extended where it needs to be.
Will I do it?
Well not alone that’s for sure as this is not only a time issue but a matter of understanding the other purposes of FacebookBundle but I’d be willing to help. I would just require the above things so that using FacebookBundle for the canvas app purpose is as convenient as is CaeferFacebookCanvasAppBundle.