• Aug. 27, 2013, 8:58 p.m.

    @nitely has noted that Misago code organisation is undjangoish, which makes getting into it for those working with other Django projects problematic.

    Little bit of history

    Misago was born from "practice project" that I have created when I started learning Django roughly one and half years ago. Back then I had no experience about laying out large projects, which eventually resulted in Misago becoming incomprehensible behemoth of 44 applications.

    In development it is extremely important to be able to move around code quickly and sheer number of tiny interlocking apps made looking up module contents or implementation details chore. This made me come to wrong conclusion that Django philosophy for laying out projects is ultimately flawed and unfit for large projects. This is when I have looked at other "large" Django projects for inspiration for better code layout, ultimately landing with what Misago has now.

    As time moved I was making more Django software gaining experience and better understanding of how Django Apps should work. I was still unsatisfied with Misago code organization and started to seriously think about better solution.

    Misago Now

    Currently Misago code layout is anything but Django-like. If I was to associate it with any patterns, I would say it looks like it was done in CodeIgniter or some other closely tied framework from old times.

    Views and Forms are either bundled together or laying alone in misago.apps with rest of misago.* namespace being reserved to models, fixtures and other modules that provide features to Misago views or each other. There is simply no clarity here for those coming from other Django projects.

    Say I'm curious where is Board Index view defined. I go into misago directory and there is no obvious place to look further. If misago was project's namespace, I would then search for an app like "home", "index" or "boardindex". If misago was an app namespace, I would look for misago.views module to search in for in. But this is not the case now.

    Rethinking code organization

    Misago is too complex to use "app" approach that is used by, say, AskBot. If we went down that path Misago would ultimately end repeating original problem of being slow to navigate with humongous misago.forms and misago.views namespaces consisting either dozens of filies or few files with thousands lines of code. Both of those approaches are unacceptable for me.

    Only alternative is to take "project" approach with misago namespace reserved for applications and everything not qualifying as app (no models or linked views) going into misago.utils namespace.

    (This post will be edited as I come up with new things to share.)

  • Members 3 posts
    Sept. 1, 2013, 2:46 a.m.

    I support this code refactoring :dragon:
    Still planning to integrate this nice forum with my website.

  • Oct. 15, 2013, 8:08 p.m.

    I think I'm more or less settled on how code in project will be laid out in 0.5 release.

    As proposed before, all one app approach will be dropped for few one-domain oriented apps providing set of functionalities and existing under 'misago' namespace. This approach is already used by Django itself, storing apps under 'django.contrib' namespace.

    So, within Misago there will be 13 namespaces or "apps":

    • misago.acl - ACL talks to Forums and Users, providing both with permissions sets
    • misago.admin - Admin UI stuff (views, helpers, widgets)
    • misago.analytics - Admin Stats generators
    • misago.conf - Misago settings provider/admin
    • misago.forums - Forums
    • misago.forumtypes - Forums types abstraction widgets and forums admin
    • misago.search - Search forum types
    • misago.privatethreads - Private Toreador
    • misago.reports - Content Reports
    • misago.ui - Forum frontend UI stuff (views, helpers, widgets)
    • misago.users - Users (register, activate, signin, bans, profiles, admin, news feeds, etc ect)
    • misago.utils - Utilities & helpers

    There will be also be three extra directories inside this directory:

    • locale - translations
    • static - misago static stuff
    • templates - default templates

    Those three paths will be automatically set in config, so you don't have to set them up yourself. If you want to change misago looks, you'll download archive containing static and templates dirs with new files, put them wherever you want and edit your settings.py to look for assets and templates in those new dirs before ones in 'misago/' directory.

  • Oct. 16, 2013, 8:13 p.m.

    Small change of plans. 0.5 and 0.6 places were changed. 0.5 will be extra moderation tools and 0.6 will code cleanup/refactoring. That way Misago will be feature-complete when final code cleanup happens, and so I will know what usecases new architecture and apis have to cover.