DRY up $content/group_module view

[ewinslow]

The blog and bookmarks modules are virtually identical, and I just found myself copy/pasting it for another plugin.

[cash]

Same with pages and files. Since it is only ever shown when the groups plugin is active, we could put the generic view in the groups plugin.

[ewinslow]

Not beta-essential

[cash]

I had a look at generalizing the group "widgets". The light version would be called like this:

elgg_view('groups/profile/module', array(
    'content' => $content,
    'all_link' => $all_link,
    'more_link' => $more_link,
));

It pulls the HTML out of the '<plugin>/group_module' views into the group module template. The big but is that it only saves two lines of code.

The more extreme generalization would look like this:

elgg_view('groups/profile/module', array(
    'type' => 'object',
    'subtype' => 'blog',
    'handler' => 'blog',
));

There would be basically no code in the '<plugin>/group_module' views but

• introduces more magic in that certain language strings must be defined
• passes a handler to a view

You can get rid of the magic by passing the string, but not passing the handler takes us back to the first one.

It might still be worth doing the first option even if it doesn't really save us any boilerplate for the sake of having a single view to override.

Thoughts?

[ewinslow]

I think your last point is significant. Having only one view to override is a big win for themers. That would mean they can theme all group modules without any knowledge as to which plugins are even installed in the system (assuming the plugins are coded properly).

I prefer the first approach. I'd also prefer the view be named groups/components/module, but that's not as big a deal as just having the view in the first place.

[cash]

Fixes #3139 DRYs up group modules

Changeset: 0594a363ae77c5427eb96a8753e644897fdc5491

[Cash Costello]

Merge pull request #49 from cash/dry_group_modules

Fixes #3139 DRYs up group modules

Changeset: 8565bdf9a471e541af576201a756b9da58e1c81b