(I was dreaming when I wrote this, forgive me if it goes astray...) There have been a few threads lately about componentization, railets, boxcars, etc. And we all seem to have a vague feeling that "we need more", but I''m not sure we''ve stated the problem clearly yet. Yet everyone is writing their own everything, and that''s such a duplication of effort, and a community-wide violation of DRY. I think we all agree we would like to have a standard authentication/authorization model, at least as an option. ActiveRBAC seems like it''s the farthest along, and browsing over the mailing list, it seems to me that becoming The Standard is a core, achievable goal, especially if it folds in ModelSecurity-like features. Other than that, what is it we want? I had a recent conversation implying the need for some type of polymorphism for partials, so that end-apps could override partials from components, etc. Many things that should be components are instead released as generators; is this the reason why? I picture some more generic, hierarchical form of the content_for_layout idiom. Then there''s the acts_as_* group of AR extensions; David''s already hinted that the reason they''re not folded into core is because he wants to think of a more generic way for them to interact. The thread about "railets" talked about portal-specific components - weather, RSS, slashboxes, etc. That seems like an interesting but contained problem, which may or many not impact most Rails users - seems like we''re focused more on specific apps that wouldn''t necessarily have been done in web space, like project management, or on tightly-focused e-commerce ventures. I haven''t noticed people trying to create the next my.yahoo.com with Rails. (Corollary: unlike the vB-baseds portals that keep sprouting up, Rails apps seem to start from the functional requirements, one of which may or may not be community. Community-based apps often start from a message board, and try to figure out what functionality that enables.) But still, there are some general Rails memes that could do well in most any full app. Other than authentication/authorization, which components need to interact with which others in a standardized way? Markup is one; RedCloth and BlueCloth are great examples of that. Relatedly, wikis seem to pop up in nearly every context these days (see Trac), and there are so many different wiki syntaxes that a plug-compatible wiki component seems useful. What else? Many people would like a layer other than ActiveRecord, but that may be too embedded to be a generic, pluggable component. Overall, it seems like we''re talking about two separate but related problems: 1. We need generic ways for specific components to provide standard *services*, like authentication, markup, wiki processing, acts_as_foo. 2. We need a generic way to let these components be *locally customized* without requiring generators. And either one of these might require Rails additions, or it might simply require consensus on the idioms used to provide it. So... what''s your wish list for services and their customization? Maybe if we can nail down the question, we can start coming up with answers. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
On Sep 29, 2005, at 12:24 PM, Jay Levitt wrote:> > Overall, it seems like we''re talking about two separate but related > problems: > > 1. We need generic ways for specific components to provide standard > *services*, like authentication, markup, wiki processing, acts_as_foo. > > 2. We need a generic way to let these components be *locally > customized* > without requiring generators. > > And either one of these might require Rails additions, or it might > simply require consensus on the idioms used to provide it. > > So... what''s your wish list for services and their customization? > Maybe > if we can nail down the question, we can start coming up with answers.Please check out the excellent work being done by Jamis on Ticket #2335 [1]. Do install that and start hammering on it, making it do what you want it to do, find its weaknesses and post them to the ticket. This does not yet cover Components, but we''re looking for ways to move them into the scheme. Components are currently pretty limited in scope and capability and it''s easy to hit a wall with them. I don''t know that they''ll be overhauled before 1.0, but it will happen. [1] http://dev.rubyonrails.com/ticket/2335 -- Scott Barron Lunchbox Software http://lunchboxsoftware.com http://lunchroom.lunchboxsoftware.com http://rubyi.st
Hi <snip>> Overall, it seems like we''re talking about two separate but related > problems: > > 1. We need generic ways for specific components to provide standard > *services*, like authentication, markup, wiki processing, acts_as_foo. > > 2. We need a generic way to let these components be *locally > customized* > without requiring generators.<snip> As the author of ActiveRBAC I could not agree more with your idea. The "big thing" that could happen to RoR is a component system allowing for more or less pluggable components/modules. However, I don''t think that the "selling point" of such a system should be drag & drop installation of plugins on the framework level - these things are more useable for CMS systems - but the component features of Ruby On Rails could need some extension. The "missing" things for RoR to support components better include the following IMO: * A central authentication and permission layer would be good and ActiveRBAC is trying to become that. This is the most important point since auth/perm is "orthogonal" to about all other component/ application features and required everywhere. Additionally, components could provide a list of roles and permissions they use. Then, a "./script/component" script could automatically add these roles and permissions to the auth/perm database on installation and remove them on deinstallation again. * A common way to override templates and messages in components. In ActiveRBAC, I currently give the option to set another template root so you can replace all templates at once or none. Component controllers could search "/app/components" first, if there is a "controller_name/action_name" template and let that override the default template. Overriding messages is not *that* a major point but every component should allow for i18n. Maybe MultilingualRails is a good choice here. * A common way to configure the components. ActiveRBAC currently does this by having an ActiveRbac::Configuration class that works as a "configuration service". It requires "config/active_rbac_config.rb" where you can do things like: ActiveRbac::Configuration.controllers[:template_root] = ''/foo'' All controllers in the ActiveRBAC component extend ActiveRbac::ComponentController in a similar way all your controllers normally would extend ApplicationController. This class provides a "config" method that returns the ActiveRbac::Configuration class. You can then access configuration the following way: class ActiveRbac::MyController < ActiveRbac::ComponentController layout config.controller[:layout] def index @some_text = config.controller[:some_value] end end This seems very lightweight and straightforward to me. Something like this could become "best practice" and instead of "config/ active_rbac_config", "config/component_config.rb" could be used to configure components. I do not see the requirement for a configuration class in the framework itself. * A way to express dependency. Components should be able to depend on ruby versions, other components, ruby library and ruby extensions like database drivers. Dependency options could include "require", "suggest", "related" depending on how close the component is coupled with the library. This, again, could be done pretty lightweight with a "Component" module mixed into ComponentController classes. Ruby saves us from needing a gem like framework here again. A "./script/ component" script could come in handy for automatic updating, installing, deinstalling etc. * A common way to plug in components into the URI structure for applications. While this could be done manually with copying and pasting lines from some install documentation some overrideable "magic" would come in handy. I guess there are more things desireable, but these are the major things that occured to me when writing ActiveRBAC. In my opinion, a component system for RoR should and can be lightweight because many things can be done elegantly with the Ruby language that would require a bloated system with Java and other systems. Regards Manuel Holtgrewe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 10:39 AM, Manuel Holtgrewe wrote:> The "missing" things for RoR to support components better include > the following IMO: > * A central authentication and permission layer would be good and > ActiveRBAC is trying to become that. > * A common way to override templates and messages in components. > * A common way to configure the components. > * A way to express dependency. > * A common way to plug in components into the URI structure for > applications.You''ve described a CMS built on Rails. Best, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDPDO5AQHALep9HFYRAn+JAKCu2kQbWDaMd4Q1/eRQHGUnEtp1dQCg1kv2 9RCF+gPIGyrHNwITWUs1Hj8=mgFK -----END PGP SIGNATURE-----
Hi> You''ve described a CMS built on Rails.I don''t think I agree here completely. A "CMS" is a Content Management System. My points do neither include content or management at all. Of course, such a component system could easily support a content management system (and arguably a CMS should be modular and extensible through such a system. Many CMS have precisely these points but I do not think they are limited to content management systems. Regards Manuel Holtgrewe
In article <68CC2BF7-CE79-4474-B3B3-63FF8981E2D1-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>, jeremy- w7CzD/W5Ocjk1uMJSBkQmQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> On Sep 29, 2005, at 10:39 AM, Manuel Holtgrewe wrote: > > The "missing" things for RoR to support components better include > > the following IMO: > > * A central authentication and permission layer would be good and > > ActiveRBAC is trying to become that. > > * A common way to override templates and messages in components. > > * A common way to configure the components. > > * A way to express dependency. > > * A common way to plug in components into the URI structure for > > applications. > > You''ve described a CMS built on Rails.I don''t see why any of these is useful solely, or even mainly, for a CMS; in fact, it strikes me that if he came up with these thoughts while writing ActiveRBAC, which has nothing to do with a CMS, that''s empirical evidence that they''re useful for much more. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
In article <d6fcbf59de02305587c0f76f9ff53e3b-HDQKq3lYuGDk1uMJSBkQmQ@public.gmane.org>, scott- HDQKq3lYuGDk1uMJSBkQmQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> Please check out the excellent work being done by Jamis on Ticket #2335 > [1]. > Do install that and start hammering on it, making it do what you want > it to do, > find its weaknesses and post them to the ticket.This is the second time in as many days that someone has taken a simple request of mine and gone ahead and previously coded it. If this sort of thing keeps up, I''m just going to stop developing anything and start posting here instead... I think I see a business model. Nice work, Jamis, and I''ll check it out shortly! -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 29, 2005, at 11:51 AM, Jay Levitt wrote:> In article <68CC2BF7-CE79-4474-B3B3-63FF8981E2D1-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>, > jeremy- > w7CzD/W5Ocjk1uMJSBkQmQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says... >> On Sep 29, 2005, at 10:39 AM, Manuel Holtgrewe wrote: >>> The "missing" things for RoR to support components better include >>> the following IMO: >>> * A central authentication and permission layer would be good and >>> ActiveRBAC is trying to become that. >>> * A common way to override templates and messages in components. >>> * A common way to configure the components. >>> * A way to express dependency. >>> * A common way to plug in components into the URI structure for >>> applications. >> >> You''ve described a CMS built on Rails. > > I don''t see why any of these is useful solely, or even mainly, for a > CMS; in fact, it strikes me that if he came up with these thoughts > while > writing ActiveRBAC, which has nothing to do with a CMS, that''s > empirical > evidence that they''re useful for much more.They aren''t; I was being glib. But, empirically, the heart of what most CMS provide are the features described above. CMS typically means website-builder these days. This boils down to a nice way of plugging parts together. Best, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDPDpKAQHALep9HFYRAsUVAJ0azzbeoxZC/TUu/Hx+zQnyfty4zACdFqC0 PbrhbH36qCx1X8EKbO5IaIA=BiuM -----END PGP SIGNATURE-----
In article <5960DCAE-C4C1-4170-8724-FC0271C65D7D-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>, jeremy- w7CzD/W5Ocjk1uMJSBkQmQ-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> They aren''t; I was being glib. But, empirically, the heart of what > most CMS provide are the features described above.By that standard, what he''s built is also a web browser and Photoshop.. :) I just want to make sure we don''t relegate the idea of plugins to the CMS/portal basket, as happened in the VB world. There are plenty of functions that would be useful in many app-centric Rails apps that people reinvent every day because it''s easier than integrating something else. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
Jay Levitt wrote:>1. We need generic ways for specific components to provide standard >*services*, like authentication, markup, wiki processing, acts_as_foo. > >2. We need a generic way to let these components be *locally customized* >without requiring generators. > >And either one of these might require Rails additions, or it might >simply require consensus on the idioms used to provide it. > >Relating to point #2: component migrations would help to avoid generators. At the moment ActiveRBAC requires its own generators to be installed, which simply create the necessary migrations in RAILS_ROOT/db/migrations. If ''rake migrate'' looked for separate migrations per component (e.g., RAILS_ROOT/components/active_rbac/migrations), that would obviate the need for these generators; each component could maintain it''s own set of migrations under version control. Then, installing or updating a component (and its backing tables) to the latest version would be a case of "svn update && rake migrate". This would require changes to the migrate rake target and another column in schema_info to store the component name. Anyone else like this idea? Kevin E. Hunt