Misago + Django App Merge?

Integration with existing projects with glue scriptsis not supported and will never be.

In future Misago will provide API gateway that will enable other apps to fetch certain data from forums in order to display it page and tell it to automatically create discussion threads for articles.

Then consider this problem: You have saloon and truck. How are you going to merge them into one car without heavy modifications in both of them?

The reason why "nobody" big does this "well" is simply because there is no way to do it "well" (as in elegantly and efficiently). You either limit featureset delivering only one thing (say, forums and posts) that integrates well because it has no expectations towards sessions/permissions/users system, or complete solution that delivers package of closely tied features coming from many domains (users, permissions, sessions) that makes it extremely hard to replace parts of system with parts from other system.

I've gave their code a skim and from what I see they are not really integrating with other stuff. Instead they are using their own content framework to act as either Q&A or Forum based on active tab of their site.

Currently only thing I can surely say about rolling in django.auth is that I don't mind it as long as user accounts behavior remains same as it is now. This probably will mean duplication of user groups/permissions functionality as Misago takes different approach to user permissions than Django, but if others don't mind that, then all right. Misago models already enforce custom app prefix ("misago_") which means Misago models won't conflict with other apps models.

Other things are matters that are not for discussion like dropping Misago admin for Django one for Misago models or dropping Jinja as templating engine. Also off table is fragmentation of Misago reuseable apps that can be used alone. Disabling some features by removing their misago.* entries from INSTALLED_APPS may be possible, but is not goal. Same can be said about adding only picked few apps from misago to your project. Adding misago.forums to your INSTALLED_APPS will not work and it is not my design goal to make it work.

Only problems I see that would need solving are:

1. Template engine conflicts - Misago uses Django_Jinja for templates
2. Storing templates - Misago stores templates outside of apps to make them easy to discover for those interested in customizing them, but this may make templates collide with other apps
3. Static files conflicts
4. Context processors conflicts
5. Middlewares conflicts

However Misago is still in development, it's not complete, it's being changed frequently, integrating Misago with other Django projects will have to wait for feature complete stage before I'll be willing to get serious about it.

For now, I've changed roadmap a little by adding milestone for code refactoring to make it compliant with Django way for laying app, use django.auth and django.sessions as well as make misago-native settings easier to merge into exisiting django projects:

github.com/rafalp/Misago/issues?milestone=8&state=open

I've tought about this a lot recently and I am convinced that this is not an healthy usecase for Misago. It's simply too complex to integrate with existing projects without forcing major amount of work to be put in both project and Misago's codebase in order to make them work together.

What I am considering instead is making it easier to use existing Django apps as extensions for Misago. So if you want to add, say, galleries to Misago, you pick existing Django app, throw it in, modify templates to fit your design/link to new features and enable django admin to be able to admin your newly installed app.

Once you have learn'ed how Misago is setup and how it differs from Django, Misago itself could become "higher-level" foundation for building sites around Misago forums.

Hey, let's actually turn this into dev discussion. :smile:

To sum up current situation: Many folks showing interest in Misago do it because Misago is Django-powered. They then realize Misago cuts itself from Django ecosystem and find that turn-off for them.

I admit that decision to turn back on Django world was mistake. Over time Django has grown impressive collection of ready apps around it and it would be awesome if it was possible to use them in process of building your site.

This is currently impossible as Misago is violating Django "contract", however during next code cleanup steps will be taken to change that.

I'm still disliking Django Admin and Django permissions, but they are de facto standard 3rd party app developers expect to be present when they are developing their apps. So while Misago will keep its own Admin component and permissions framework, Auth component will be build upon Django's one and User model will be 100% compatible with Django Admin, Groups and Permissions, so when you decide to use 3rd party apps, all dependencies will already be here for you. Just turn on Django admin and make sure it's using different admin link than Misago one.

Only "gotcha" I could think of here would be adding fields and features to Misago user model. If you edit model itself, you will break Misago's migrations so you will probably want to roll in custom extra profiles with 1:1 relation to this model + signals to keep stuff in sync.

In addition, Misago uses Jinja2 for its templates, which allows for different approach to adding features to templates. Those features will need to be implemented again as django tags or filters for those who will want to stick to Django templates in their apps.

Also implementation of some things will change in the spirit of "get outta ma way", so they shouldn't get in your way and surprise you when you are writing your site.

Naturally, working as stand-alone app still remains important use-case for Misago, so language-agnostic integration layer is still planned for those who want to integrate with solutions from outside of Django or even Python world.

Thanks for taking minute to take the voice in this thread, @Walkman

My concern back when I was writing that lied in fact that Misago defines massive amount of variables via context processors, but looking at this file now, plenty of those variables will go away when Misago apps are dropped and Django counterparts are used in their stead, and other variables are not that generic to be likely to collide with 3rd party apps.

As for templates and statics, currently I'm convinced I'll put them all into same misago/ directory that will hold Django apps used by project. Then some magic in default config will register those directories automagically on django boot.

And yes, while originaly I've disliked idea for namespacing them for making dir tree too deep, that's simplest and nicest solution for the problem, so it will go in.

Preffered approach to customising Misago looks will be adding your own template/static dir to config before misago ones, and creating custom version of tiles that template loader/static collector will use instead of default ones.

I've decided to bite it in Misago 0.6 and here's what I've done so far:

• dropped Jinja 2 templates for sake of Django templates
• moved templates to 'misago/' dir
• moved links under 'misago:' namespace
• moved default assets to 'misago/' dir
• added 'shared_403_error_handler' and 'shared_404_error_handler' decorators that can be used by project defining its own error handlers but still wishing for 403/404 errors raised by forum links to be handled by Misago

Other things on todo are dropping Misago sessions/messages for sake of Django ones, and making Misago auth component based on Django's auth framework. The goal is to minimalise number of places Misago may conflict with Django apps or other projects. Django admin will also be supported for those who want to use it to admin their apps, but Misago will keep its own admin panel.

Yep, all those things will land in 0.6 release which is big cleanup of existing codebase.

When's 0.6 going to happen? Not sooner than Django 1.7. 0.6 will change a lot about models so I would like to have one annoying update (data & south deprecation) instead of two.