That has to go in the wall of fame. A milestone as it will. A core commiter wanting Engines as a feature of their own app infrastructure? I love it :)
As far as feature #2 goes, it would need to be outside of the plugin code/checkout. The best feature of an engine is the ability to override whatever you want through a linear stack track. A key concept of an engine is that the code can be used with an external and have whatever changes you personally need overriden in your own app such as /config/initializers/ and such. It would be sad to see this feature sacrificed due to implementation. I like the about.yml files. I still use them in all my plugins. They could surely be used as you mentioned, and probably even more uses to come out of it. Doesn't hurt anything by being there? Only helps as far as I see it. On 1/31/08, Sven Fuchs <[EMAIL PROTECTED]> wrote: > > Hi James, > > like I mentioned a while back Rick asked me regarding Engines as a > basis for Mephisto plugins. > > Mephisto comes with its own implementation of plugins that share > controllers, views, routes, schemas (migrations) etc. as well as some > config stuff. Rick asked me to look into using Engines instead and he > suggested this as a feature for Mephisto 1.0 > > I believe Mephisto could benefit from using all the major Engines > functionality. But there are some features that aren't currently > supported by Engines and I'd like to discuss to what extend these > could possibly be added to Engines instead of having them in Mephisto. > > These are: > > 1. About info: we've omitted about.yml from Engines for Rails 2.0 > recently and you already mentioned that this could possibly be > restored. On the one hand Rick said that he doesn't really care about > this, but on the other hand people actually seem to use this > information (e.g. the plugin authors website is displayed in the > Mephisto admin interface and people use this link to lookup > information about the plugin). > > 2. Configuration info: Mephisto provides means to configure a plugin > through an option directive. E.g. in a feedback form plugin there > might be an option to configure the confirmation message that's > displayed when the feedback for has been submitted (bad example but > you get the idea). The option and its default value is defined in the > plugin, it's current value is pulled from the database if a record is > present (otherwise the default value is used). Mephisto could switch > from using ActiveRecord as a storage for plugin configuration data to > something else, e.g. another YAML file, Ruby code or whatever. > > A possible solution for both requirements that I personally like could > be: > > With Rails 2.0 plugins we can do all the about and configuration stuff > from within init.rb because this file is evaluated within the plugin's > scope. Because init.rb is overwritten when the plugin get's > reinstalled (so the config customization would get lost) we could look > for a (e.g.) config.rb file and evaluate it alongside with the plugin > init.rb file if it's present. This config.rb file would allow to > define something like: > > author 'James' > version '1.0' > website 'http://...' > > option :feedback_confirm_msg, 'Thanks!' > option :foo, 'bar' > > What do you think? > > > -- > sven fuchs [EMAIL PROTECTED] > artweb design http://www.artweb-design.de > grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone) > d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile) > > > > _______________________________________________ > Engine-Developers mailing list > [email protected] > > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org > -- Nathaniel Steven Henry Brown 604-724-6624
_______________________________________________ Engine-Developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
