我正在使用Laravel 4(测试版(框架我的新应用程序，它被设计为开源下载并运行此安装脚本(例如博客、时间跟踪器等(类型的应用程序。
我想让界面有主题，我可以用几种方式来做，但我不确定该选择哪一种。因为我使用composer，我应该设置主题引擎以期望主题是包，还是应该只在内部管理主题？(也就是说，将它们放在主题目录中(。
/-------------------------------------------------------------------------------''|内部托管主题|打包主题||---------------------------------------|---------------------------------------||易于管理|易于主题开发人员管理||---------------------------------------|---------------------------------------||手动更新，或需要外部|通过composer更新自动更新||已构建主题回购|||---------------------------------------|---------------------------------------||一键即可完成外部主题|用户需要更新和管理||安装和删除主题|composer.json用于所有主题安装|||和删除||---------------------------------------|---------------------------------------||资产必须是静态的-尽管这|主题开发人员可以自由使用||不应该是一个，因为资产不能|编译器和资产管理器允许||当使用this|用于基于||方法|配置或类似方法||---------------------------------------|---------------------------------------||需要编写代码才能发布所有|资产公开||资产到公共目录|通过artisan的资产目录：publish||复制|命令中已存在的内容或通过所选资源||laravel框架预编译器||---------------------------------------|---------------------------------------||易于安装的主题都在|想不出简单的管理方法||自定义主题存储库和仅zip |不会在上注册的主题||归档主题| composer存储库|''-------------------------------------------------------------------------------/
因此，从上面的列表来看，这是一个相当公平的权衡，真正的问题是，我是不是让我(和脚本的最终用户(管理起来更复杂，但让主题开发人员更容易做更多。还是我限制了主题开发人员的能力，让我和最终用户更容易管理？
Wordpress和类似的产品允许技术水平很低的用户安装主题。如果你的市场同样是非技术性的，你会想选择"内部"主题。使用Composer在很大程度上限制了你的技术受众。
(除非你做了一些非常聪明的事情，比如让你的应用程序更新composer.json文件。这会吓到我，但这是两个系统都最好的一种方法。(