Hi Andrey, I don't have very much that I can usefully add to your ideas, save a few comments on what you've said about engines:
On 3/7/06, Andrey Tarantsov <[EMAIL PROTECTED]> wrote: > Now, engines are completely opposite to this. You add a LoginEngine and > your application gets very complex login logic at once, without you > having a slightest idea on how it works or how it can be customized. ....this is always the case when you take code from an outside source. The onus is on you to examine it, and understand how it will interact with your application. But distributing black-box components is NOT the purpose of the engines plugin, but rather a secondary effect with unique benefits and of course, some unique drawbacks. > What's more, there are no building blocks for this — if you don't like > anything lying deeply inside LoginEngine, your only option is to rewrite > all or most of it. This is too bad. This is both true and not true. You can override elements within an engine at the method and view/partial level - very easily I might add - so what you say above is false if you are applying it to engines in general. The LoginEngine itself, however, does have aspects where it's implementation doesn't lend itself well to being overridden. That's because it's only an *example*, and represents the minimum amount of work I had to do to transform the authentication-system-du-jour (at the time) into an engine for the purposes of illustrating what it is that Engines are, and why they might be useful to some folks. To make this absolutely clear, the point of engines is NOT so I can write a bunch of components for you guys to plug together in weird and wonderful ways. It's so YOU can develop your applications in a modular way and reuse those modules across your applications as YOU determine might be appropriate. The community sharing is essentially an afterthought, but if you're written something that other people find useful then that presents a not-inconsiderable secondary bonus. Producing engines for the world at large is not, for me at least, a quest to give birth to something that will work for everyone. If you find yourself having to rewrite a lot of some component, chances are you would be better off not using it. However, at the same time you might realise that you're going to need this new module, including its views and other assets, in your next project. The point of the engines plugin, and the 'engines' development technique - to help you do exactly that. Regarding the LoginEngine in particular, I have no doubt that a better, more modular login system can be developed and used in place of the LoginEngine, but lets please be clear when we're talking about engine development, and be sure to distinguish it from the particular implementation within a given engine. Engines != [LoginEngine, UserEngine]. As a final note which relates somewhat more directly to your ideas, I think you're right to bring focus on testing and engines, but it should be borne in mind that there's absolutely nothing stopping a developer from writing their own set of fixtures in the application root, and a corresponding set of methods to test any methods they have changed or added. They should hopefully not have to test everything (no need for a test_user_present_in_session_after_login or anything like that) - just what's appropriate for their application (test_non_admin_user_can_edit_wiki_page or whatever). Perhaps the upcoming integration testing will light a clearer path to modular testing nirvana... Sorry if this doesn't seem quite on-topic, I just feel it's essential not to bring criticisms of the LoginEngine's "lack of modularity" against engines in general. If, as I hope, you are simply chastising the poor implementation of that engine, believe me that you are not alone in feeling this way. Onwards and upwards. Good luck exploring your modular methods idea! - james _______________________________________________ engine-developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
