Hi, at the moment it is quite difficult to combine multiple Rails apps, e.g. a forum and a wiki. Neither components nor engines provide a sufficient level of separation between the parts of the applications to make this considerably easier, because in the end everything becomes mixed up in the same namespace. A way to avoid this would be to create all the engine classes (models, controllers, helpers) inside a module. This would open a whole number of interesting possibilities: Controllers/Routing ================== Controller names of different applications do not collide, you can have a BooksController both in a wiki and in a book database. Routing a path directly to the controller of an engine could look like this: map.connect ''book/:id'', :module = "wiki_engine", :controller => "books", :action => "show" To delegate a path to the routing of the engine: map.connect ''wiki/:path'', :module = "wiki_engine" ...and the "path" part will be processed by the routes.rb of the engine. Models ===== If you need to "talk" to a model of another engine you could write WikiEngine::Book.find(xyz) If you want the WikiEngine and the BooksEngine to use the same "User" model: WikiEngine::User = BooksEngine::User = MyUserModel To prevent collision between table names you could assign a table prefix to an engine or make it use a seperate database connection: WikiEngine::table_prefix = ''wiki'' There might be problems I haven''t thought of, and changing Rails to deal with modules would probably be a lot of work. But on the other hand it could be a more general solution for both components and engines in the current form. I would really like to hear the core developers'' opinion on that. Andreas
Hi, at the moment it is quite difficult to combine multiple Rails apps, e.g. a forum and a wiki. Neither components nor engines provide a sufficient level of separation between the parts of the applications to make this considerably easier, because in the end everything becomes mixed up in the same namespace. A way to avoid this would be to create all the engine classes (models, controllers, helpers) inside a module. This would open a whole number of interesting possibilities: Controllers/Routing ================== Controller names of different applications do not collide, you can have a BooksController both in a wiki and in a book database. Routing a path directly to the controller of an engine could look like this: map.connect ''book/:id'', :module = "wiki_engine", :controller => "books", :action => "show" To delegate a path to the routing of the engine: map.connect ''wiki/:path'', :module = "wiki_engine" ...and the "path" part will be processed by the routes.rb of the engine. Models ===== If you need to "talk" to a model of another engine you could write WikiEngine::Book.find(xyz) If you want the WikiEngine and the BooksEngine to use the same "User" model: WikiEngine::User = BooksEngine::User = MyUserModel To prevent collision between table names you could assign a table prefix to an engine or make it use a seperate database connection: WikiEngine::table_prefix = ''wiki'' There might be problems I haven''t thought of, and changing Rails to deal with modules would probably be a lot of work. But on the other hand it could be a more general solution for both components and engines in the current form. I would really like to hear the core developers'' opinion on that. Andreas
I would love to be able to do this. The one sticking point that I''ve come across at the moment is the way that Rails'' dependencies automatically creates modules for ApplicationController subclasses. Continuing the WikiEngine example, intuitively you''d want to put your controllers underneath the WikiEngine module too. However, Rails automagically creates this module and throws a fit if it already exists. Typically within Engines/Plugins/Whatever we want to have some control over this module, for setting configuration options for example. There might be ways around this, I''ll have to look a bit more closely at how we can create normal modules that work cooperatively with those generated by the dependencies system. - james On 12/31/05, Andreas <usenet@andreas-s.net> wrote:> Hi, > > at the moment it is quite difficult to combine multiple Rails apps, e.g. > a forum and a wiki. Neither components nor engines provide a sufficient > level of separation between the parts of the applications to make this > considerably easier, because in the end everything becomes mixed up in > the same namespace. > > A way to avoid this would be to create all the engine classes (models, > controllers, helpers) inside a module. This would open a whole number of > interesting possibilities: > > Controllers/Routing > ==================> > Controller names of different applications do not collide, you can have > a BooksController both in a wiki and in a book database. > > Routing a path directly to the controller of an engine could look like this: > map.connect ''book/:id'', :module = "wiki_engine", :controller => > "books", :action => "show" > > To delegate a path to the routing of the engine: > map.connect ''wiki/:path'', :module = "wiki_engine" > ...and the "path" part will be processed by the routes.rb of the engine. > > Models > =====> > If you need to "talk" to a model of another engine you could write > WikiEngine::Book.find(xyz) > > If you want the WikiEngine and the BooksEngine to use the same "User" model: > WikiEngine::User = BooksEngine::User = MyUserModel > > To prevent collision between table names you could assign a table prefix > to an engine or make it use a seperate database connection: > WikiEngine::table_prefix = ''wiki'' > > > There might be problems I haven''t thought of, and changing Rails to deal > with modules would probably be a lot of work. But on the other hand it > could be a more general solution for both components and engines in the > current form. > > I would really like to hear the core developers'' opinion on that. > > Andreas > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
On 12/31/2005 James Adam <james.adam@gmail.com> wrote:> Continuing the WikiEngine example, intuitively you''d want to put your > controllers underneath the WikiEngine module too. However, Rails > automagically creates this module and throws a fit if it already > exists. Typically within Engines/Plugins/Whatever we want to have some > control over this module, for setting configuration options for > example.I''ve been thinking about this with some people at work, and I''m wondering if it''s possible to set up something dynamic. I understand that the /components tree is more or less depricated, and I''d really like to see something done with it along these lines. For example (and I don''t know exactly how feasable this is) it''d be really useful if one could pull a whole other app into a subdir of /components, and have Rails automatically scope it as it loads, based on the name of that folder. For example, /components/johns_wiki/app/models/page.rb defines Page, but gets loaded as JohnsWiki::Page. Same for controllers. A few extra routes in the parent app should handle any kind of URL munging that would be desired. Other stuff that would need to be looked at to get this working properly: Database - rake migrate from the host app should investigate components, and munge table names. From the above example, John''s Wiki defines a table named ''pages'', but the host app would translate that into ''johns_wiki_pages''. Tests - some way of running the components'' tests from parent app''s rake. Views - if the components location was a fallback, and the default location to look for rhtml templates was in the base /app/views, any layouts or whatnot could be overridden to provide an integrated look with the rest of the site. The real question is if this is even possible, or desirable... I think I would much rather do something like this than get into a mess of plugin/engine conversions from full apps. - Jamie Macey
> I understand that the /components tree is more or less depricated, and > I''d really like to see something done with it along these lines.Has this deprecation you speak of been written up anywhere or just your opinion? Just curious.
> Has this deprecation you speak of been written up anywhere or just > your opinion? Just curious.Components haven''t been formally or informally deprecated. However they''re not very widely used. The .14 release had a memory leak in components which didn''t get noticed for a few weeks. -- Cheers Koz
Obie Fernandez wrote:>>I understand that the /components tree is more or less depricated, and >>I''d really like to see something done with it along these lines. >> >> > >Has this deprecation you speak of been written up anywhere or just >your opinion? Just curious. > >I don''t think they are obsolete. But they sure have an efficiency problem. I have begun work on a patch that fixes that. -- stefan -- For rails performance tuning, see: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 1/4/06, Obie Fernandez <obiefernandez@gmail.com> wrote:> > I understand that the /components tree is more or less depricated, and > > I''d really like to see something done with it along these lines. > > Has this deprecation you speak of been written up anywhere or just > your opinion? Just curious.When I was looking into this sort of thing months ago (rails 0.9 era) and started asking around on IRC, the story I heard was that someone had a good idea for components, but it only got half-implemented, and nobody picked up the slack since then. At the time I was trying to figure out a way to get components to work, smartly, without needing uses_component_template_root in the models. I did get it mostly working, but scrapped my changes somewhere around 0.12 since the project I was doing it for at work got indefinitely delayed at the time. - Jamie