Subject: Re: Yet another reason to use salted passwords
Newsgroups: gmane.comp.lang.ruby.rails
Date: 2005-11-11 12:56:13 GMT (2 years, 33 weeks, 4 days, 20 hours and 20 minutes ago)
Engines fill a fairly specific need that we (my team) have, which is the development of multiple distinct Rails applications which share common components (authentication, reporting, importing data from hellish Excel), and ensuring that a means to apply patches & bug fixes across each of these applications, including models, controllers and views with the *minimum* of developer time spend on managing those updates. Need to roll-back to a previous version of the Reporting system? Just change the SVN external and *everything* within the Engine goes back to the way it was. With generators (less so with those that come with plugins, but this still holds true), the code would have to be regenerated back into the /app directory. As far as I'm aware, the only means for producing a common set of views across a number of rails applications at the moment is by using a generator (either a normal one, or one that comes within a plugin). If such generators existed and were so impeccably tailored to our (my team's) present and future needs, obviously we would never need to think about updating the generated code and the whole issue would disappear. Of course, this isn't the case. Plugins with piggy-back generators go a HUGE way towards resolving this issue, but they still betray their generator colours by their inherently painful upgrade cycle: GeneratorDeveloper: 'New version! Many bugs killed dead! Everybody LEVEL UP!!' CoderDude: 'Crap, I'm going to have to merge my views & other stuff with this latest new version of 'SuperPlugin+Generator to get these fixes, but then I did make my own patch for some of them.. I hope that none of their bug fixes squash the behaviour that I expect from my own modified system.... OK here goes.... OK these are the files that might change.... [a few hours later].... right, I think I've merged all my customisations.... [runs the server] Oh Crap! Something didn't go right there. I better hope I remembered to commit all my changes to SVN, or I'm a-gunna be screeewed!' Not to mention that CoderDude has blue-chip clients breathing down his neck for deadlines. Put simply and bluntly: We <3 Rails, but generators just don't cut the mustard for our some of our (my team's) more "quasi enterprise" development needs. Hence Engines. Most Rails developers, teams and projects might not be in the same situation as us, and for the Lone Code, generators are undoubtedly fine. But that's life, you choose the tools most appropriate for your needs, and if the tools don't exist yet, you write them yourself. Engines have not recieved the blessing of the RoR core team, and I wouldn't expect any different, because it would be madness to include them in the core Rails. It's a mechanism far too easily [ab]used for things it's not actually suitable for. I did speak to Jamis (cc'd to DHH) about them quite some time ago, before plugins existed in a released form. Their advice was to reimplement our mechanism as a plugin, and if anything we were doing could not be achieved in this way, they would re-examine their plugin mechanism to see what could be adapted. As it turns out, we can do everything we need within their plugins architecture, so we have a happy coexistance - Rails stays clean, but is flexibly enough to support our (hopefully not too outlandish) needs. It's not like we're forking the project or taking digging our heels in and taking a stand against anything. What was this thread about again? My head feels a bit dizzy... On 11/11/05, Deirdre Saoirse Moen <deirdre@...> wrote: > I've talked this over with DHH in IRC, therefore I'm pretty sure I > understand his perspective. > > In short, plugins and generators are sanctioned, engines are not. > > On Nov 11, 2005, at 3:17 AM, Trevor Squires wrote: > > > I can't speak for the core team but my impression is that a plugin > > (which Engines is) is a 'sanctioned' way to distribute extensions > > to rails without having to pester the core team to include your > > extensions in rails itself. > > > > As an example, I don't recall seeing the asset_timestamping plugin > > announced on the ROR weblog but I *do* recall seeing an email from > > Jamis saying he intended on using it... > > > > Regards, > > Trevor > > > > On 11-Nov-05, at 2:27 AM, Deirdre Saoirse Moen wrote: > > > >> On Nov 10, 2005, at 7:30 PM, Francois Beausoleil wrote: > >> > >>> If you don't mind the new dependencies, LoginEngine installs in > >>> two steps: > >> > >> Personally, I more mind the fact that engines are an approach not > >> sanctioned by the core team. (note that no announcement of engines > >> ever took place on the ror weblog) > > -- > _Deirdre http://deirdre.net > > > _______________________________________________ > Rails mailing list > Rails@... > http://lists.rubyonrails.org/mailman/listinfo/rails >