>> Though I do not agree completely with DHH's opinion about high level >> components, > I keep hearing about it, but never read it. Could you give me a > pointer?
http://www.loudthinking.com/arc/000335.html http://www.loudthinking.com/arc/000407.html http://www.loudthinking.com/arc/000528.html He has his points though he is a bit extreme. > I agree with you: this has to be avoided at all costs! > A lot of people in the Rails world are refugees from > "complex-hard-to-manage-and-Java-like things" ;-) > > There is a distinction to do though: is the complexity on the > framework or on its the users side? > > Example: the fact that I need to type 15 time as much code to read a > file > in Java rather than in Ruby, doesn't mean that the Ruby interpreter > is simpler than the JVM. It means that it does more for me. Of course. However, if you look at CORBA or SOAP then you see an example of each a "feature complete" component architecture and communication protocol. They are so complex that you need lots code to get the simplest things done with them if you want to use all of their features. In my opinion it will be very very hard to create a framework/API that allows to bick 3 but not only 2 points of the magic triangle: * flexibility * power * ease of use If you want high flexibility, you might either end up with a beast of CORBA (picking power) or an API that does not really define anything and the amount of code you have to write to use it is "easy" but there is a lot to do. >> I will certainly not try to stop you from doing it but in my opinion >> the mixin and override features of Ruby could do many things such a >> layer would do: Define some callback methods like ActiveRecord's >> callbacks and let users overwrite them in their current code. > > Right. This could work and it is one of the topic I would like > to discuss in higher detail. In the article > http://cicio.org/articles/engines_isolation > I already tried to point out that in the engine community is > understimating the conflict risks (poor namespace usage). > The approach you suggest could be OK if applied in a consistent way. Yes, namespaces reduce the possibility of conflicts. We would need to put *everything* in a namespace, though, not only controllers but also models, helpers etc. This would remove the "name conflict" errors. However, another problem with highly componentized and distributedly developed software is the one of dependency. If component A depends on components B (version 1) and C (version 2). However, component B depends on version 3 of component D and component C depends on version 2 of component D. The versions 2 and 3 of component D are not compatible, though. *Bang*. This is an analogy to Goedel's Theorem: Every computer system that is complex enough to be of interest contains possibilities to create contradictions. (Sorry for the very rough paraphrase). I know of my experience this happens all the time. If you use DarwinPorts under Mac Os X then you know this, too. :) >> While these systems can reduce the complexity of huge systems you >> have to get over an "entry complexity barrier" - lest you invest more >> time planning and implementing the required overhead such systems >> bring than you save compared with rewriting. > > You are right. My aim is to use the space for improvement that > we have _without loss of simplicity_. If there is not such a space, > I rather drop the topic. In my opinion adding "power" to a system as "simple" as Rails will always add complexity. Rails allows you to create applications fast and "scales up" pretty well in means of "supportable complexity of your application". However, you always have to keep in mind that the developers of Rails are of the opinion that less code is better than more as well as that less functionality is better than more in most cases (that could be seen as one of the more revolutional points of so called "Web 2.0"). So if you wanted to know what I would recommend: 1.) Put everything into its own namespace but don't break the possibility of a global namespace. This would require huge changes in the Rails code base and understanding Rails code is a bit more complicated than I thought when I looked at it first. Sure, it can be done. 2.) Drop the "global service registry" approach of things. This will make thing infinitely complex. Make it the user's responsibility to call things explicitely. Inversion of control might be a good thing for huge systems but it creates more problems than it solves for smaller systems IMO. 3.) Add a dependency system that allows you to install all dependencies, i.e. install the engines plugin when installing ActiveRBAC. This could be done with a "rails project gem repository" (minus the gem structure plus the Engine structure, of course). ./script/plugin is a good start. 4.) IMO the major one: Decide on a common layer for the most important things. Rails offers almost everything you need but authentication IMO. Select one authentication and authorization framework (this does not have to be ActiveRBAC though I would really like to see that :)) - or merge serveral existing ones into the "one". Maybe a common interface would be good here, too. But keep these interfaces informally described in documentation and don't wrap them into their own layer. Could everybody else give his opinion on what "common sub-application types" are the most important besides user and permission handling? 5.) Decide on best practice of how "big engines" should be structured so they are extensible. Create "the" Article,Image,File Management (CMS)/Wiki/Weblog/Image Gallery "base applications" on Engines. Make sure they are extensible and extensible in the same way. Don't overload applications. Maybe contain a unolingual and a multilingual branch of the CMS so people who need only to support on language don't have to stick with the complexity. You won't solve everybody's problem but if you solve the problem of 80% of all this is not bad. If I could drop the effort of writing the CMS part (for static pages like imprint) once for all by simply using the default CMS Engine, I would do so. I would not do so if there was no documentation, things were to complex (i.e. unnecessary stuff I won't need and I can't switch off). I would not use it if it was too simple and I could not extend it easily. I would love it if it did the basic things and I only had to hook in a "price" field for articles, for example. This is very very hard because: * Defining "best practice" for extending (and more important: for making the base things extensible) is hard since you don't want to restrict anyone but you want to make things consistent. * Making APIs consistent is hard. Most of the time I dislike other people's code it is because I would have done it differently and using it does not seem natural at me and it is itching. Yes, that's the "not built here syndrom". You have to streamline the "core engines" programming so they feel the same to developers. * You have to make things extensible easily. At the moment, you cannot easily add to Engine models without copy'n'pasting the old file. This has to change for the points described above to work. * You have to force yourself to cut down the features. Adding features is easier than cutting them out again. * People will bug you because they want a feature that is not included and you have to make clear to them that this is intended. * You must have very clear and extensive documentation and Howtos. Writing documentation sucks. Everybody hates it so you will have to do this :) Goodness, that's much more than I wanted to ramble on that topic. HTH Manuel _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
