incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brondsema" <>
Subject [allura:tickets] #6896 Developer architecture docs
Date Tue, 10 Dec 2013 17:19:18 GMT
Here's a few paragraphs that I have used in private conversations to help explain how to get
started in Allura:

> To run our test suite, you can run ./run_tests in the top-level of the allura code. 
That is a wrapper around "nosetests" which you can use to run tests for individual packages
or files.

> covers some aspects.  Besides that,
the top-level directories are for each separate tool, so there's some organization there.
 The Allura directory has the main code, which dispatches out to each tool as needed.  And
individual tools will use common classes and functions from the Allura package.  

> The entry point for everything is in Allura/allura/controllers/  The controllers
use object dispatch, see
 So every method and attribute in a controller maps to a URL.  Pretty quickly, though, it
gets dynamic and dispatches to neighborhoods which dispatch to projects which dispatch to
tools.  Each tool's entry point is going to be in a file named something like
 In it there's a ForgeWikiApp which defines the tool.  That class specifies self.root = RootController()
so the RootController class is where you'll find all the URL handling for a wiki.  At the
end of the day, using `grep` or some other search tool is often key to finding where something
is :)

> As far as tech goes, mongodb is probably the best thing to learn.  It is used throughout
Allura.  We use a library called Ming, on top of pymongo, to map to objects and such.


** [tickets:#6896] Developer architecture docs**

**Status:** open
**Labels:** docs 
**Created:** Tue Nov 19, 2013 08:28 PM UTC by Dave Brondsema
**Last Updated:** Tue Dec 03, 2013 07:50 PM UTC
**Owner:** Tim Van Steenburgh

It'd be useful to have some high-level docs for developers that are getting started with Allura.
 And update/overhaul our current developer-oriented doc pages.  I think we should cover things
like: how the code is organized, what technology is used (paster, TG, EW, jinja, etc), how
to log & debug, how tests work, etc.


Sent from because is subscribed to

To unsubscribe from further messages, a project admin can change settings at
 Or, if this is a mailing list, you can unsubscribe from the mailing list.
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message