Kevin Carwile

Not really. It's a content item just like any other in IPS and therefore is locale specific (i.e. not translatable). Its the same as creating a topic, or a download, or a calendar event, etc.

Font styles can be changed via css through your theme editor. Display format can be changed from the appropriate app settings tab/screen in your collab category configuration.

In due time.

Fixed for next release. Not currently.

Until you need to decorate some of that decoupled abstract functionality. Then you'll see the problem. One approach lends to inconveniences, true. But the other way excludes possibilities.

Its a fundamental problem and an engineering trade off. Using traits to encapsulate functionality decouples that functionality from any particular class (which improves reusability), but at the same time locks it from being extended using the hooking system that has made the IPS4 platform so flexible (which decreases 3rd party extensibility). I think traits are a bigger negative to the platform than a positive. Having to switch from a decorator design pattern to an observer design pattern is a step backwards.

Any details? Or am I supposed to guess what your problem is?

I'm looking at my app on ipsguru.net. Looking good, looking good. So what are you talking about again?

Any app that follows the core IPS4 container/content design pattern is inherently compatible with GC without any additional integration needed. So the answer to that question depends on what standards that the "other addon" conforms to. That said, why dont you install both and give it a test and then let me know how it goes? I don't have the classifieds app to test myself.

Yes, owners can manage their own collabs. Replace the word collabs with the word clubs and problem is solved.

@kmk You can do that with roles inside a collab. Simply create roles for school 1, school 2, basketball dept, football dept, etc. Each role can have different levels of access to resources within the collab based on the permissions you assign. Objective complete.

Which features aren't already in collabs?

Right, so the question is if a slightly more organized codebase is worth trading for the openness and flexibility of the product to be extended in new ways. Because I can tell you right now. There is no way to hook into a trait to provide enhanced functionality without knowing the specific base class that is going to use it. So instead of having one hook on the base implementation, you have to hook into specific child classes that use it (which is not practical when your enhancement is abstract) such as Automation Rules, which needs to trigger an event for any arbitrary class that uses the trait. End result is either no enhancement of the base product, or way more hooks than necessary on every conceivable content item that may use it (how's that for a performance gain).

I don't like paying prices that don't need to be paid. The existing strategy of placing interface functionality in a base class, but allowing child classes to implement the interface to enable that functionality has allowed the "interior decorator" design pattern (the hooks system) to work well. By switching to traits, you trade the frameworks greatest strength for a relatively non-beneficial ability to decouple from the base class. That's not a very good tradeoff.

I agree. I can't think of any other way to remove the impedance that this introduces. Although, there is another problem that I can think of. You will not be operating internal to the class that uses the trait so therefore protected properties and methods will be unavailable to the external class.

With the decision to use traits in IPS 4.2, how are 3rd party apps supposed to extend any functionality contained within them? In an attempt to update Automation Rules for compatibility with IPS 4.2, I need to hook into an \IPS\Content\Reactable method to attach an event dispatcher so that rules can be triggered when content is reacted upon. By using traits, the functionality is now basically locked out of being extended or hooked into.

That is generally true. I'm sure its possible to find an exception configuration.

I don't see of any way to import vb4 social groups to IPS clubs. Where are you seeing that?

The can create their own pages in the sense that you can allow groups to use databases you have set up in the ACP. So they can create their own categories and records in those categories for that database. But configuring their own blocks and adding them to their collab is not currently possible due to technical limitations in the ability to control blocks visibility "per page" in core ips. Maybe when core improvements are made there...

It is. The dropdown menu for nodes when managing them from the ACP has an option to move it to a collab. Where do I start. GC provides intelligent and granular partitioning of existing site resources instead of trying to recreate them in some other form. Because of this approach, it allows groups to use all apps at their full strength, in their full form, including all configuration features of that app that get added or changed as it evolves.... inherently. Clubs on the other hand provides an alternate way for apps to offer up their configuration in "club mode". For example, create a forum in a "club" and you'll be able to set its name and description. Create a forum in GC and you set its name, description, icon, password, theme, link, post count pre-requisites, order, nesting level, permissions, and everything in between. Similarly, it supports all apps that follow the container/content model out of the box because it doesnt attempt to know how to intercede with its configuration. They really are two totally different approaches that result in two different products. Other key differences that I can see is that GC also partions the permissions system in its full capacity also. Meaning groups are able to define their own custom roles inside the group with all the same moderator permission granularity of the main site assigned to those roles inside the group, and permissions matrices for the group content set up based on those roles as well. Then theres the whole rules ECA integration. Group memberships and actions can be tied into automation quite easily if needed. Clubs will be a great way for sites to roll out some basic group participation facilities. And GC will remain the solution for when you want to empower your groups to collaborate using the full power of the IPS4 community suite.

No conflict. They work independent of each other. Although I have been tossing the idea around of setting GC up so collabs could have clubs inside of them. But that may be just getting too cute and/or redundant.

I'll look into that. Thanks for the report.

@mrbowers Are you talking about on 4.2?

4.2 compatibility fixes will be posted very soon. I'm just adding a few new features and other upgrades to GC while I'm at it to fill some gaps.

That will need to be edited in the theme. I'll look to change that though for the next update. Since collabs can have logos now, it makes sense.