I am using the Laravel 4 (beta) framework my new new application which is designed as an open source download and run this install script (e.g. blog, timetracker etc) type application.
I am wanting to allow the interface to be themed, which I can do in a couple of ways, but I am not sure which one to choose. Because I am using composer should I set the theme engine up to expect themes to be packages, or should I just manage the theme's internally? (aka have them sitting in a themes directory).
/-------------------------------------------------------------------------------\ | Internally Managed Themes | Packaged Themes | |---------------------------------------|---------------------------------------| | Easy for me to manage | Easy for theme developers to manage | |---------------------------------------|---------------------------------------| | Manual updates, or needs external | Automatic updates via composer update | | theme repo built | | |---------------------------------------|---------------------------------------| | Can do external theme with one click | Users need to update and manage | | install and removal for themes | composer.json for all theme installs | | | and removals | |---------------------------------------|---------------------------------------| | Assets must be static - Although this | Theme developers are free to use pre | | shouldn't be a as the assets couldn't | compilers and asset managers allowing | | really be dynamic when using this | for dynamic css etc based on a | | method | configuration or similar. | |---------------------------------------|---------------------------------------| | Need to write the code to publish all | Assets get put into the public | | the assets to the public directory | directory via artisan's asset:publish | | duplicating what already exists in | command or via the chosen asset | | the laravel framework | pre compiler | |---------------------------------------|---------------------------------------| | Easy to install themes both in the | Can't think of an easy way to manage | | custom theme repository and just zip | themes that will not be registered on | | archive themes | a composer repository | \-------------------------------------------------------------------------------/
So, from the list above it's a pretty even trade off, and the real question is, do I make it more complicated for me (and the end user of the script) to manage, but easier for the theme developers to do more. Or do I limit what the theme developers can do and make it easier for me and the end users to manage?
Wordpress and similar products allow users with very little technical skill to install a theme. If your market is similarly non-technical, you're going to want to go with "internal" themes. Using Composer pretty much limits you to a very technical audience.
(Unless you do something super-clever like having your app update the composer.json file. That would scare the heck out of me, but it would be one way to have the best of both systems. )