Hi Mike - As a developer coming from developing solutions using Open Atrium, Commons has recently peaked my interest because many of the tools I'm used to in Open Atrium are now used in Drupal Commons. It looks like og_spaces is not one of the tools that has made it over and instead og_features has been chosen. I'm hoping you can elaborate on the advantages and disadvantages of using og_features as opposed to og_spaces.

Also, to get the conversation rolling, I noticed in the README under "What is missing" you've listed "Ability to make feature customizations, not just disable/enable (possible?)". Do you have an approach you think might work better than og_spaces use of strongarm's variable_get() overrides?

Comments

mstef’s picture

mstef commented

Hey RJ,

Great questions.. thanks for asking.

Spaces is an amazing module - there's no question about that. It's certainly one of the most interesting modules out there and definitely has good potential. One of the main problems with spaces, is that is starts to move Drupal away from the standard Drupal we're all used to. It's extremely confusing for novice Drupal admins to wrap their heads around how it works, and how to work with it to achieve the things they're used to doing in Drupal. There's no doubt that it's extremely powerful and versatile - it's just a little too developer-oriented, and seems more fit for a packaged Drupal application, rather than a normal distribution. One of the main focuses of Commons was to keep things as normal Drupal as possible, allowing for easy administration and customization.

OG Features was developed for Commons with the idea to have per-group functionality without the use of Spaces; and to be done as simply as possible. OG Features also has the benefit to allow a feature to pick which of it's components are actually inside a given group feature (as opposed to entire thing). That's helpful because features could contain things that aren't group-specific (ie, sitewide). Spaces also required pURL, which is also a great module, but was basically a disaster trying to get to work inside Commons (probably just from a lack of experience with it). I also haven't dove too deep, but I'm not sure how the Spaces+pURL system works when you're dealing with cross-group content, etc.

There really isn't an answer as to which solution you should use. OA did an amazing job using what it is - it's a wonderful application. The biggest thing that OA has that Commons is lacking, which ties into the Spaces conversation, is per-group layouts/blocks. And probably the next issue to tackle; I'm not sure what the approach is/should be just yet.

In regards to having og_features offer feature settings/customizations in each group, well, it was just an idea I had since I noticed that OA did the same. It would be a nice addition, but to be honest, I haven't yet put anything more thought to it than just that. I'd love to hear any ideas you might have about how to make this module better. I believe this module is turning out really great and can definitely improve. I've already used it in so many interesting ways...

I hope that helps a little. Let me know your thoughts and any other questions you might have, or things you'd like me to elaborate on.

R.J. Steinert’s picture

R.J. Steinert commented

Thanks for the great reply! A few responses to some of your points:

"[Spaces] starts to move Drupal away from the standard Drupal we're all used to"
For end-users this is true in some ways, but for developers, I think the idea of altering variable_get() is a very Drupal thing to do even though Drupal doesn't do that yet... :)

"[Spaces] is extremely confusing for novice Drupal admins to wrap their heads around how it works"
Definitely true when it comes to the variable system interacting with various things they wouldn't expect like the Spaces menu.

"OG Features also has the benefit to allow a feature to pick which of it's components are actually inside a given group feature (as opposed to entire thing)"
That's definitely nice to have. I've worked around this requirement when using Spaces by creating a specific Feature module for each Space type. IE Photo Gallery for OG Spaces, Photo Gallery for Site Wide Spaces, Photo Gallery for User Spaces.

"Spaces also required pURL"
Yes, that was true for Spaces-6.x-2.x, as of spaces-6.x-3.x pURL is no longer required.

"I'm not sure how the Spaces+pURL system works when you're dealing with cross-group content, etc."
miccolis explains why cross group content is not in OA here https://community.openatrium.com/issues/node/48#comment-81
and then my research/brainstorming here https://community.openatrium.com/issues/node/48#comment-6984
and lastly btopro is actively pursuing this for the e-learning management system Drupal profile called "ELMS" http://drupal.org/project/elms

"The biggest thing that OA has that Commons is lacking, which ties into the Spaces conversation, is per-group layouts/blocks"
Definitely a very useful feature when the groups in your site will have different missions and will want to focus on content/functionality from different features.

"In regards to having og_features offer feature settings/customizations in each group, well, it was just an idea I had since I noticed that OA did the same."
Not having variable_get() overrides per group is definitely not a deal breaker for feature developers. We can store our group specific settings with group nid foreign keys and shape our business logic to expect we have to look at what context we are in. It's just a little easier with variable_get() being overriden by spaces+strongarm and not having to worry about what the current "context" is. I wonder what the Development Seed guys would have to say on this...

mstef’s picture

mstef commented
Status: Active » Fixed

If anyone wants to continue this conversation, feel free to reopen.

Automatically closed -- issue fixed for 2 weeks with no activity.