Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate
summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGreg S <enimihil@gmail.com>2009-05-06 19:38:55 (GMT)
committer Greg S <enimihil@gmail.com>2009-05-06 19:38:55 (GMT)
commit96547e0bc16c96955829d61d5ac3a19ea46b8868 (patch)
tree4c083da1a1e8549babbda169bb7ef3e6651df962
parent0cc8a0559d02e1c9d3f21e95aa078f9d574bbb16 (diff)
Add some more documentation.
Added docs for extending the API.
-rw-r--r--doc/new_format.rst25
1 files changed, 25 insertions, 0 deletions
diff --git a/doc/new_format.rst b/doc/new_format.rst
new file mode 100644
index 0000000..42a8cdf
--- /dev/null
+++ b/doc/new_format.rst
@@ -0,0 +1,25 @@
+Writing a New Format for the API
+================================
+
+Writing a new format plugin for the question API is simple. All that needs to
+happen is to insert a string -> function pair into the
+``quizdata.formats.FORMATS`` dictionary. The function takes a file-like object
+to the data and returns a list of questions.
+
+The recommended implementation strategy is to make a module named
+``_format_[formatname]`` in the ``quizdata`` package and import the
+appropriate function in the ``quizdata.formats`` module to add to the
+dictionary.
+
+If parsing is required, the recommended tool is pyparsing, though XML/HTML
+would be better served by using a library like BeautifulSoup.
+
+New Question Types
+==================
+
+New Question types can be implemented as subclasses of the base Question type,
+or not. So long as the generic functions dealing with questions are also
+extended appropriately. Adding a new type is best left as an exercise to
+those reading the code, though it should be simple enough, as the required
+behavior of a question object is minimal. (Additional behavior for specific
+types of questions should be documented).