• 1 Rails 3.0 links
• 2 Architectural changes
• 3 Approaches
• 3.1 Pancake
• 3.2 refinery style
• 4 Modularity
• 4.1 dependencies
• 5 step by step
• 5.1 baby step… stacks for mods
• 5.2 extend default behaviour
• 5.2.1 hooks
• 5.2.2 observers

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.