Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Each "application" should be small -- a single reusable entity plus a few associated tables. We have about 5 plus/minus 2 tables per application model. Most of our half-dozen applications are smaller than 5 tables. One has zero tables in the model. </p> <p>Each application should be designed to be one reusable concept. In our case, each application is a piece of the overall site; the applications could be removed and replaced separately.</p> <p>Indeed, that's our strategy. As our requirements expand and mature, we can remove and replace applications independently from each other.</p> <p>It's okay to have applications depend on each other. However, the dependency has to be limited to the obvious things like "models" and "forms". Also, applications can depend on the names in each other's URL's. Consequently, your named URL's must have a form like "application-view" so the <code>reverse</code> function or the <code>{% url %}</code> tag can find them properly.</p> <p>Each application should contain it's own batch commands (usually via a formal Command that can be found by the <code>django-admin</code> script.</p> <p>Finally, anything that's more complex than a simple model or form that's shared probably doesn't belong to either application, but needs to be a separate shared library. For example, we use <a href="http://www.lexicon.net/sjmachin/xlrd.htm" rel="noreferrer">XLRD</a>, but wrap parts of it in our own class so it's more like the built-in <code>csv</code> module. This wrapper for XLRD isn't a proper part of any one application, to it's a separate module, outside the Django applications.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload