What you should keep in mind when developing an Engine: ## Keep it focused Don't try and solve 1000, 100, or even 10 problems. Do one thing, pick one strategy, and do it cleanly and clearly.
## Convention over configuration Don't add configuration until YOU need it, and even then think hard about whether or not it's the right thing to do. Engines aren't all-terrain vehicles - they should expect to be allowed to do their own thing to the greater extent, and your application, being more flexible, should cope with how the engine works [1]. ## Make it modular Try and put code into modules wherever you can - it helps with namespacing, and makes it simpler to override code in the case of models. ## Document like your life depends on it If you are anticipating that ANYONE else might be wanting to use this code, make sure that you've got a great set of documentation (READMEs, RDoc, the works) to support it. You'll save yourself a lot of time in front of an email client if you do. ... those are a few things to bear in mind, I guess. But here's the doozy: ## Screw the community - write it for yourself. It's only through need that you discover what features are really important, and only through the need for reuse that you get a deeper understanding of which aspects of your code can afford to be a bit more flexible. Write your engine with YOUR needs in mind, and don't try and anticipate problems until you hit them yourself. Once you have a solid understanding of what you're trying to do, then by all means let other people in on the project. But always bear in mind that code is only really useful when it has a purpose, and if you're not using it yourself then how can you really understand what it should do? ..... OK, here's some more practical advice: * Put your controllers into modules. * Provide a sensible set of routes for the user to use, and use them religiously for redirects and link_to calls in your own views [2] * Document! (Yeah, I already said that, but it's crucial) * Put model code in modules * Try and provide a set of useful partials, rather than a smaller set of views, as these are easier to reuse. Good luck! - james [1] People email me asking how to get the login engine to work with their application, which has been designed to use Account models rather than Users. The short answer is... you can't. Sure, there are hacks and ways around this, but your life is a lot simpler if your application has been designed in harmony with the external code it's going to interact with, rather than trying to shoehorn everything together after the fact. Don't try and please everyone, because design by committee produces camels, not racehorses (http://www.pfc.org.uk/medical/mmacvw.htm). [2] There's no automatic mechanism for including routes with an engine, but simply provide some that can by copy-pasted into the application's routes.rb file. That's fine and possibly even preferable. On 5/14/06, Joshua Muheim <[EMAIL PROTECTED]> wrote: > Hi all > > I'd like to begin with clean development of engines that I will be able > to re-use and give to the Rails community. > Now my question: what should I always keep in mind when writing code for > an engine? I'm thinking here about stuff like that I shouldn't hard-code > table names etc. > > And by the way: Isn't it quite dangerous to hard-code model names, too? > We're nearly forced to do this, I know, but it could be quite often the > case that the name of an engine's model is the same like the name of > another model, right? That's quite dangerous... :-/ > > Thanks for infos! :-) > Joshua > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > engine-users mailing list > [email protected] > http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org > -- * J * ~ _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
