Rails 3.0 migration

ideas and discussions related to migrating crabgrass to rails 3.0, may evolve into committee

Rails 3.0 links

Rails 3.0: Release Notes
Rails Plugins Compatibility Tracking
Peepcode screencast - Rails 3 Upgrade
On the way to Rails 3 - a link list
Rails 3.0 Beta: 36 Links and Resources To Get You Going

Architectural changes

As Engines change with rails it looks like we

  • either have patch the new rails versions with the apply mixin to model changes that allows for mods and tools to work the way we do
  • or change the cg architecture to not require this.

Approaches

Pancake

pancake allows for a collection of application stacks to be running in a single application. Parts of the core app would be pushed into mounted stacks so that mods can be replaced by stacks that are optional.

refinery style

Refinery is a CMS that comes with most code in vendor/plugins and libs. The app itself is written for the specific needs then.

Modularity

Both approaches would include splitting cg into a number of modules that each take care of a certain aspect of cg and then are put together. Partly we already do that in terms of the groups with groups_extensions, users with user_extensions and the like.

dependencies

One thing i am unsure about is how to approach dependencies in this… Say for example Membership – would that be part of the group module? If so… does it depend on the existance of users? Probably. So would there be an order in which different modules could depend on each other?

My first take on this would be

  • Users – make sense without groups or pages
  • Pages – do we make these depend on the existance of users? I would like these to be independent from groups.
  • Groups – depend on users. should they also depend on pages? Group_participation definitly does.

step by step

The Modularity outlined above does require lot’s of thought and very likely refactoring. Lots of it has already been put into the way cg is split up today with the extensions – but never the less what would a first baby step look like?

baby step… stacks for mods

If we are moving in the direction of pancake. Why not have the core of cg as one huge stack to start with. We might still break it into smaller pieces later on. Then next thing could be to have the mods turned into stacks. These would be easy to switch on and off.

extend default behaviour

It might be hard to change behaviour on a defined url in core cg. For example with an admin mod it would be easy to have /admin/… point to the special admin features and have this in a stack of its own. But what about the moderator links on the pages themselves? the pages would still remain on a url outside of the moderation stack.

hooks

We could use hooks to extend the different menues we have on pages group settings and the like. This way we don’t need to overwrite these but “just” attach our new links to the hooks.

observers

Observers are another way to change the behaviour of certain aspects of the app without changing the code itself.

 
elf Pavlik
2010-02-26

maybe someone can create a committee for this issue?
 
 
azul
2010-02-28

wrote down some of the email references (pancake and refinery cms) and started brainstorming about architecture.
 
   
elf Pavlik
2010-03-01 2010-03-01

I would like to leverage use of Rack heavily so after taking first look at Pancake it gets me way more excited than Refinery.

With your question about assuming existence of User model in other modules. First of all I feel somehow allergic to referring to People as Users, and myself always use Person model. Sometimes I even think to don’t use applications with User model just make a fork of them with the only difference in User renamed to Person =0

IMHO
Person == Conscious Being Co creating The Cosmos
Person != DB record (User)

In my opinion all applications and models which will be used by people can safety assuming their (our ;) existence. And of course with implementation flexible enough that if someone wants to call People – Users one still can do that. Maybe I will even make ‘separatistic’ application build around Elf model ;)