{
    "info": {
        "author": "John D'Ambrosio",
        "author_email": "john@alternate.io",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 2 - Pre-Alpha",
            "Environment :: Web Environment",
            "Framework :: Django",
            "Framework :: Django :: 1.10",
            "Intended Audience :: Developers",
            "License :: OSI Approved :: MIT License",
            "Operating System :: OS Independent",
            "Programming Language :: Python",
            "Programming Language :: Python :: 2",
            "Programming Language :: Python :: 2.7",
            "Programming Language :: Python :: 3",
            "Programming Language :: Python :: 3.4",
            "Programming Language :: Python :: 3.5",
            "Topic :: Internet :: WWW/HTTP",
            "Topic :: Internet :: WWW/HTTP :: Dynamic Content"
        ],
        "description": "==========\nfoundation\n==========\n\nThe Problem\n-----------\n\n**Django** clearly defines the following paradigms (amongst others):\n\n- Object-Relational Mapping (ORM) via Models\n- Request Routing via URLs\n- Data Binding via Forms\n- Request-to-Response Mapping via Views\n- Data Presentation via Templates\n\nWhile this explicit control over the design and function of each component is\noptimal for many use cases, one could argue that it runs afould of Django's\nmost desirable design principle: \"Don't Repeat Yourself\" (DRY).  More\nto the point, while Django ships with an admin app that most new users rave\nabout, there is no obvious way to expose a front-end without a fair amount of\nwork (especially when auth or comprehension of model interrelationships is\ndesired) that could be simplified greatly if there was a central class through\nwhich those interrelationships were managed.\n\nMany approaches set out to solve this through class methods on the Models or\ntheir Managers, but that runs counter to the spirit of segregating the Model\n(intended to be a representation of the state of the DB) from logic (typically\nhoused in Views or Forms).  At the same time, each of those pieces is intended\nto only have a comprehension of a single Model and not the interrelationships\nbetween said Models, resulting, for instance, in an inability to have a given\nimplementation accomodate more than one relation that a developer may desire\nto expose to the end-user.\n\nA Solution\n----------\n\n**foundation** sets out to provide a single Backend per Django Site (website)\nwith Controllers specified per-model and the interrelationships between those\nControllers serving as:\n\n- the Model (DB) access layer (via Model Manager and QuerySet)\n- the View generation *and* access layer (via Class-Based Views which are, in\n  their own right, Controllers)\n- the Form(Set) generation layer\n- the access-control layer\n- the URL specification layer\n\nThis design is inspired by Django's own admin app, as well as the design\npatterns of other MVC platforms.  It aims to re-use as much work from admin\nout of laziness and, more importantly, a belief of mine that the admin should\nbe sitting atop the foundation, not the all-to-often mistake new users make of\nattempting to expose a front-end from within admin.\n\nHow it works\n------------\n\nIf you are not already familiar with how Django sets itself up and processes a\nrequest, here are two links of interest:\n\n- `Initialization Process`_\n- `Processing a Request`_\n\n.. _`Initialization Process`: https://docs.djangoproject.com/en/1.10/ref/applications/#initialization-process\n.. _`Processing a Request`: https://docs.djangoproject.com/en/1.10/topics/http/urls/#how-django-processes-a-request\n\nIn addition to the above, foundation does the following during initialization:\n\n- foundation should be installed under all project apps to ensure the Backend\n  instance is in a good state prior to being referenced.  Additionally, the\n  app config file is a good place to instantiate your own Backend subclass if\n  you want to ensure any behaviors are baked into the backend used site-wide.\n- Once applications are ready, the foundation application's ready signal will\n  fire, which will autodiscover all of the controllers modules/packages in each\n  installed app.  Additionally, permission creation for any new models will be\n  initiated if that feature is enabled, or you can manage that in your own app\n  code where appropriate (or if you implement your own permissions scheme).\n- Finally, the URL configuration(s) are configured.  For many sites, this means\n  you can replace the settings ROOT_URLCONF with a path to your backend's \"urls\"\n  attribute, although you may append it to the list of urlpatterns in the\n  project \"urls\" module to provide flexibility in adding other url specs (e.g.\n  admin).  When the \"urls\" attribute is accessed, it will perform a single pass\n  through all of the Controllers to accumulate the appropriate URL paths in\n  namespaced patterns.  At this time, all of the class-based view (CBV) base\n  classes will also be constructed, which will in turn be generated into\n  callables just-in-time (JIT) by calling their \"as_view\" method (same as stock\n  Django).\n\nSince it is operating entirely within the context of a CBV at this point, the\nrest of what foundation does is essentially overriding stock django CBV\nmethods, although there are some important behaviors to note that are possible\nbecause of the controller interrelationships.  Most notably, the Django CBV\n\"dispatch\" behavior has been universally extended by two components.\n\n#. A \"get_handler\" method is provided which allows for a given view to handle\n   a request using other than the CBV's standard HTTP-method-named methods.\n\n#. A \"handle_common\" method is provided which allows for activities common to\n   some or all HTTP methods (e.g. auth, QS grooming) to be performed prior to\n   calling downstream methods to remove redundancy and clutter from those\n   methods.\n\nIn trying to keep with some of the paradigms set forth in django-admin, this\nmeans that for any controller- (and thus, model-) aware view, that a view \"mode\"\nis set (e.g. add, edit, view) as well as an \"edit\" and \"add\" flag to\nspecifically indicate whether the view is used for editing or creation.  These\nwill likely move further down the stack to only be present in \"html-form-aware\"\nviews and better accommodate AJAX and RESTful views.\n\nAdditionally, handle_common is where a common layer of authentication and\naccess-control logic occurs.  This ensures downstream views are guaranteed to\nhave a common logical layer invoked prior to serving a response.  By default,\nthe access control ships with awareness of predefined (and overridable) \"public\"\nand \"private\" named views (e.g. list and view are public while add, edit, and\ndelete are private).  Additionally, it provides a contextual switch so that\nsuperusers must elect to \"act\" as superusers, otherwise they will be subject to\nthe same rules as non-superusers.",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://github.com/altio/foundation",
        "keywords": "",
        "license": "MIT License",
        "maintainer": "",
        "maintainer_email": "",
        "name": "foundation",
        "package_url": "https://pypi.org/project/foundation/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/foundation/",
        "project_urls": {
            "Homepage": "https://github.com/altio/foundation"
        },
        "release_url": "https://pypi.org/project/foundation/0.1.0a0.dev1/",
        "requires_dist": null,
        "requires_python": "",
        "summary": "A generic website backend implemented in Django using Controllers.",
        "version": "0.1.0a0.dev1"
    },
    "last_serial": 2642382,
    "releases": {
        "0.1.0a0.dev1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "5239baf559573c500d4f385c5a23ef93",
                    "sha256": "ee9900cf0492db3388a6c2815153bc7f28009239717278fd798a0767ea1d001e"
                },
                "downloads": -1,
                "filename": "foundation-0.1.0a0.dev1.tar.gz",
                "has_sig": false,
                "md5_digest": "5239baf559573c500d4f385c5a23ef93",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 50785,
                "upload_time": "2017-02-14T22:31:12",
                "url": "https://files.pythonhosted.org/packages/3c/c2/244eeb1737a5998a165307c787207dffaed352ea45e2bc3c9bfec05cf5d1/foundation-0.1.0a0.dev1.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "5239baf559573c500d4f385c5a23ef93",
                "sha256": "ee9900cf0492db3388a6c2815153bc7f28009239717278fd798a0767ea1d001e"
            },
            "downloads": -1,
            "filename": "foundation-0.1.0a0.dev1.tar.gz",
            "has_sig": false,
            "md5_digest": "5239baf559573c500d4f385c5a23ef93",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 50785,
            "upload_time": "2017-02-14T22:31:12",
            "url": "https://files.pythonhosted.org/packages/3c/c2/244eeb1737a5998a165307c787207dffaed352ea45e2bc3c9bfec05cf5d1/foundation-0.1.0a0.dev1.tar.gz"
        }
    ]
}