[Python-modules-commits] [nevow] 02/08: Import nevow_0.12.0.orig.tar.gz
Tristan Seligmann
mithrandi at moszumanska.debian.org
Wed Feb 3 15:24:43 UTC 2016
This is an automated email from the git hooks/post-receive script.
mithrandi pushed a commit to branch master
in repository nevow.
commit 3d07d7fe88ac4f944b4c5078e7a8f428ef956a46
Author: Tristan Seligmann <mithrandi at debian.org>
Date: Wed Feb 3 16:41:57 2016 +0200
Import nevow_0.12.0.orig.tar.gz
---
PKG-INFO | 2 +-
doc/Makefile | 177 ++++++
doc/README | 5 -
doc/_static/.hidden | 0
doc/_templates/.hidden | 0
doc/conf.py | 267 +++++++++
doc/howto/chattutorial/concepts.rst | 132 +++++
doc/howto/chattutorial/concepts.xhtml | 136 -----
doc/howto/chattutorial/env.rst | 85 +++
doc/howto/chattutorial/env.xhtml | 122 ----
doc/howto/chattutorial/index.rst | 40 ++
doc/howto/chattutorial/index.xhtml | 56 --
doc/howto/chattutorial/intro.rst | 101 ++++
doc/howto/chattutorial/intro.xhtml | 106 ----
doc/howto/chattutorial/part00/index.rst | 213 +++++++
doc/howto/chattutorial/part00/index.xhtml | 230 -------
.../part00/listings/nevow/plugins/dropin.cache | 50 ++
doc/howto/chattutorial/part01/index.rst | 224 +++++++
doc/howto/chattutorial/part01/index.xhtml | 236 --------
.../part01/listings/nevow/plugins/dropin.cache | 50 ++
doc/howto/deployment.rst | 248 ++++++++
doc/howto/deployment.xhtml | 300 ----------
doc/howto/gettingstarted.rst | 70 +++
doc/howto/gettingstarted.xhtml | 110 ----
doc/howto/glossary.rst | 66 +++
doc/howto/glossary.xhtml | 82 ---
doc/howto/index.xhtml | 49 --
doc/howto/intro.rst | 262 ++++++++
doc/howto/intro.xhtml | 294 ---------
doc/howto/publishing.rst | 593 +++++++++++++++++++
doc/howto/publishing.xhtml | 658 ---------------------
doc/howto/stylesheet.css | 129 ----
doc/howto/template.tpl | 24 -
doc/howto/traversal.rst | 363 ++++++++++++
doc/howto/traversal.xhtml | 448 --------------
doc/howto/xmltemplates.rst | 319 ++++++++++
doc/howto/xmltemplates.xhtml | 407 -------------
doc/html/default.css | 209 -------
doc/index.rst | 46 ++
formless/test/test_freeform.py | 10 +-
nevow/_flat.py | 2 +-
nevow/_version.py | 4 +-
nevow/appserver.py | 45 +-
nevow/athena.py | 13 +-
nevow/flat/flatstan.py | 2 +-
nevow/js/Divmod/Runtime/__init__.js | 441 ++++++++------
nevow/js/Divmod/Test/TestObject.js | 23 +
nevow/js/Divmod/__init__.js | 12 +-
nevow/js/Nevow/Athena/Tests/__init__.js | 14 +-
nevow/js/Nevow/Athena/__init__.js | 7 +-
nevow/json.py | 2 +
nevow/test/test_appserver.py | 21 +
nevow/test/test_athena.py | 4 +-
nevow/test/test_json.py | 8 +
setup.py | 5 +
55 files changed, 3693 insertions(+), 3829 deletions(-)
diff --git a/PKG-INFO b/PKG-INFO
index 53d79b4..e9aaa58 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: Nevow
-Version: 0.11.1
+Version: 0.12.0
Summary: Web Application Construction Kit
Home-page: https://github.com/twisted/nevow
Author: Twisted Matrix Labs
diff --git a/doc/Makefile b/doc/Makefile
new file mode 100644
index 0000000..5a47fc0
--- /dev/null
+++ b/doc/Makefile
@@ -0,0 +1,177 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS =
+SPHINXBUILD = sphinx-build
+PAPER =
+BUILDDIR = build
+
+# User-friendly check for sphinx-build
+ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1)
+$(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/)
+endif
+
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+# the i18n builder cannot share the environment and doctrees with the others
+I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
+
+help:
+ @echo "Please use \`make <target>' where <target> is one of"
+ @echo " html to make standalone HTML files"
+ @echo " dirhtml to make HTML files named index.html in directories"
+ @echo " singlehtml to make a single large HTML file"
+ @echo " pickle to make pickle files"
+ @echo " json to make JSON files"
+ @echo " htmlhelp to make HTML files and a HTML help project"
+ @echo " qthelp to make HTML files and a qthelp project"
+ @echo " devhelp to make HTML files and a Devhelp project"
+ @echo " epub to make an epub"
+ @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+ @echo " latexpdf to make LaTeX files and run them through pdflatex"
+ @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx"
+ @echo " text to make text files"
+ @echo " man to make manual pages"
+ @echo " texinfo to make Texinfo files"
+ @echo " info to make Texinfo files and run them through makeinfo"
+ @echo " gettext to make PO message catalogs"
+ @echo " changes to make an overview of all changed/added/deprecated items"
+ @echo " xml to make Docutils-native XML files"
+ @echo " pseudoxml to make pseudoxml-XML files for display purposes"
+ @echo " linkcheck to check all external links for integrity"
+ @echo " doctest to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+ rm -rf $(BUILDDIR)/*
+
+html:
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+ @echo
+ @echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+ $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+ @echo
+ @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+ $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+ @echo
+ @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+ $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+ @echo
+ @echo "Build finished; now you can process the pickle files."
+
+json:
+ $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+ @echo
+ @echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+ $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+ @echo
+ @echo "Build finished; now you can run HTML Help Workshop with the" \
+ ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+ $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+ @echo
+ @echo "Build finished; now you can run "qcollectiongenerator" with the" \
+ ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+ @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Nevow.qhcp"
+ @echo "To view the help file:"
+ @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Nevow.qhc"
+
+devhelp:
+ $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+ @echo
+ @echo "Build finished."
+ @echo "To view the help file:"
+ @echo "# mkdir -p $$HOME/.local/share/devhelp/Nevow"
+ @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Nevow"
+ @echo "# devhelp"
+
+epub:
+ $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+ @echo
+ @echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo
+ @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+ @echo "Run \`make' in that directory to run these through (pdf)latex" \
+ "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo "Running LaTeX files through pdflatex..."
+ $(MAKE) -C $(BUILDDIR)/latex all-pdf
+ @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+latexpdfja:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+ @echo "Running LaTeX files through platex and dvipdfmx..."
+ $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja
+ @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+ $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+ @echo
+ @echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+ $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+ @echo
+ @echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+texinfo:
+ $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+ @echo
+ @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
+ @echo "Run \`make' in that directory to run these through makeinfo" \
+ "(use \`make info' here to do that automatically)."
+
+info:
+ $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
+ @echo "Running Texinfo files through makeinfo..."
+ make -C $(BUILDDIR)/texinfo info
+ @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
+
+gettext:
+ $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
+ @echo
+ @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
+
+changes:
+ $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+ @echo
+ @echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+ $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+ @echo
+ @echo "Link check complete; look for any errors in the above output " \
+ "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+ $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+ @echo "Testing of doctests in the sources finished, look at the " \
+ "results in $(BUILDDIR)/doctest/output.txt."
+
+xml:
+ $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml
+ @echo
+ @echo "Build finished. The XML files are in $(BUILDDIR)/xml."
+
+pseudoxml:
+ $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml
+ @echo
+ @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml."
diff --git a/doc/README b/doc/README
deleted file mode 100644
index ebaecec..0000000
--- a/doc/README
+++ /dev/null
@@ -1,5 +0,0 @@
-This is Nevow's documentation. The preferred format is Lore XHTML. You can
-generate the pretty version of the documentation with by running the
-following command in the howto directory:
-
- lore
diff --git a/doc/_static/.hidden b/doc/_static/.hidden
new file mode 100644
index 0000000..e69de29
diff --git a/doc/_templates/.hidden b/doc/_templates/.hidden
new file mode 100644
index 0000000..e69de29
diff --git a/doc/conf.py b/doc/conf.py
new file mode 100644
index 0000000..fd28eef
--- /dev/null
+++ b/doc/conf.py
@@ -0,0 +1,267 @@
+# -*- coding: utf-8 -*-
+#
+# Nevow documentation build configuration file, created by
+# sphinx-quickstart on Sun Jun 22 13:36:57 2014.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path.insert(0, os.path.abspath('..'))
+
+here = os.path.dirname(os.path.abspath(__file__))
+import versioneer
+versioneer.VCS = 'git'
+versioneer.versionfile_source = os.path.join(here, '../nevow/_version.py')
+versioneer.versionfile_build = '../nevow/_version.py'
+versioneer.tag_prefix = 'nevow-'
+versioneer.parentdir_prefix = 'Nevow-'
+
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'Nevow'
+copyright = u'2014, Twisted developers'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = versioneer.get_version()
+# The full version, including alpha/beta/rc tags.
+release = version
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = []
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Nevowdoc'
+
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+# author, documentclass [howto, manual, or own class]).
+latex_documents = [
+ ('index', 'Nevow.tex', u'Nevow Documentation',
+ u'Twisted developers', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+ ('index', 'nevow', u'Nevow Documentation',
+ [u'Twisted developers'], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+# dir menu entry, description, category)
+texinfo_documents = [
+ ('index', 'Nevow', u'Nevow Documentation',
+ u'Twisted developers', 'Nevow', 'One line description of project.',
+ 'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
diff --git a/doc/howto/chattutorial/concepts.rst b/doc/howto/chattutorial/concepts.rst
new file mode 100644
index 0000000..61d8300
--- /dev/null
+++ b/doc/howto/chattutorial/concepts.rst
@@ -0,0 +1,132 @@
+Concepts of Athena: AJAX, COMET, and Python
+===========================================
+
+Servers and Clients
+-------------------
+
+COMET applications can seem an almost impenetrable mess when one is
+first learning about them, much like when writing event-based desktop
+applications. However, there are some basic concepts that we can
+emphasize now to circumvent or alleviate most of the confusion.
+
+In principle, the problem is very simple:
+
+- We want out users to interact with a web page with out having to
+ refresh the page, and we want new data and/or views to be rendered in
+ response to our users' actions;
+- We want the ability to push updates to user pages from the server to
+ the browser, when the server has new data or views that are ready.
+
+As usual, the implementation of the solution is much more complicated
+than the statement of the problem, but hopefully the way that we have
+designed Athena will hide those implementation details while providing
+powerful tools to build the applications you envision. So, let's take a
+look at what you need to know about servers and clients when building
+Athena web applications.
+
+It is crucial that one understands that when we write Athena
+applications, we are doing a few different things:
+
+- Writing server code in Python that performs server actions
+- Writing server code in Python that makes remote calls to the browser
+- Writing browser code in JavaScript that performs browser actions
+- Writing browser code in JavaScript that makes remote calls to the
+ server
+
+Since server-on-server and client-on-client are rather common place and
+generally well understood, we will ignore those for now. As the other
+two are the focus of AJAX/COMET and thus also the primary domain of
+Athena, that is what we will discuss below.
+
+Browser-to-server calls are made by Athena via the now-famous
+XMLHttpRequest. Server-to-browser calls are opened by the browser ahead
+of time, and when the server is ready, the data is sent to the browser
+via that connection.
+
+JavaScript: Making Calls to the Server
+--------------------------------------
+
+When creating the JavaScript portion of our applications, we subclass an
+Athena JavaScript widget, which has a method named ``callRemote()``. By
+utilizing this method, we can send messages from our JavaScript client
+to the server (as long as the method we call exists in the server code).
+
+For example, in the chat application we will be building in this series
+of tutorials, we will have a JavaScript class called ``ChatterBox`` with
+a ``say()`` method, like the following:
+
+.. code-block:: javascript
+
+ function say(self, msg) {
+ self.callRemote("say", msg);
+ // Now show the text to the user somehow...
+ }
+
+This will make a remote call to the Python server code, executing the
+``say()`` method and passing the ``msg`` variable as a parameter.
+
+In Athena, the relationship between the browser code and the server code
+is established by declaring the JavaScript module in the Python server
+code, in the following manner:
+
+.. code-block:: python
+
+ class ChatterBox(LiveElement):
+ jsClass = u'ChatThing.ChatterBox'
+
+Additionally, in order for the JS to be able to make a call to remote
+Python code, the Python method has to be exposed. This is a security
+feature, implemented to ensure the JavaScript code can only call Python
+methods that have been specifically marked as safe. Appropriately
+enough, this is done in your Python class with the ``expose`` decorator:
+
+.. code-block:: python
+
+ def say(self, text):
+ for chatter in chatRoom:
+ chatter.youHeardSomething(text)
+ say = expose(say)
+
+Python: Making Calls to the Browser
+-----------------------------------
+
+Now what about the COMET side of the equation? If we want our server to
+update data in the browser, we need to be able to call JavaScript code
+from our Python server. We use a similar Python method as the JavaScript
+one (when making calls from the browser to the server), acquired when
+our Python class inherited from ``nevow.athena.LiveElement``:
+
+.. code-block:: python
+
+ def hear(self, sayer, text):
+ self.callRemote("hear", sayer, text)
+
+In order for this call to work, we need to have the ``hear()`` method
+defined in our ``ChatterBox`` JavaScript class, and that will look like
+this:
+
+.. code-block:: javascript
+
+ function hear(self, avatarName, text) {
+ // Here, you'd show the user some text.
+ }
+
+Unlike on our Python classes, no special annotations need to be made on
+the JavaScript side: all JavaScript methods on browser-side Widget
+objects are allowed to be called by the server. If you've sent code to
+the browser, you've already forfeited the ability to control when it's
+called. There wouldn't be a point to limiting the server's rights to run
+its code when the user can freely run it herself.
+
+Summary
+-------
+
+With the samples above, you should have a growing sense of how Python
+and JavaScript interact as servers and clients in the world of Athena.
+In particular, you should be getting a sense of how JavaScript and
+Python will be interacting in your Athena applications.
+
+This has just been a taste of Athena with a few peeks into the code we
+will be writing. We will cover these topics in greater detail in the
+following pages, within the context of creating a functional Athena
+application, complete with step-by-step instructions and rationale.
diff --git a/doc/howto/chattutorial/concepts.xhtml b/doc/howto/chattutorial/concepts.xhtml
deleted file mode 100644
index 5558e7f..0000000
--- a/doc/howto/chattutorial/concepts.xhtml
+++ /dev/null
@@ -1,136 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>Concepts</title>
- </head>
-<body>
-
-<h1>Concepts</h1>
-
-<h2>Servers and Clients</h2>
-
-<p>COMET applications can seem an almost impenetrable mess when one is first
-learning about them, much like when writing event-based desktop
-applications. However, there are some basic concepts that we can emphasize now
-to circumvent or alleviate most of the confusion.</p>
-
-<p>In principle, the problem is very simple:</p>
-<ul>
-<li>We want out users to interact with a <q>web page</q> with out having to refresh
-the page, and we want new data and/or views to be rendered in response to our
-users' actions;</li>
-<li>We want the ability to push updates to user pages from the server to the
-browser, when the server has new data or views that are ready.</li>
-</ul>
-
-<p>As usual, the implementation of the solution is much more complicated than
-the statement of the problem, but hopefully the way that we have designed
-Athena will hide those implementation details while providing powerful tools to
-build the applications you envision. So, let's take a look at what you need to
-know about servers and clients when building Athena web applications.</p>
-
-<p>It is crucial that one understands that when we write Athena applications,
-we are doing a few different things:</p>
-<ul>
-<li>Writing server code in Python that performs server actions</li>
-<li>Writing server code in Python that makes remote calls to the browser</li>
-<li>Writing browser code in JavaScript that performs browser actions</li>
-<li>Writing browser code in JavaScript that makes remote calls to the server</li>
-</ul>
-
-<p>Since server-on-server and client-on-client are rather common place and
-generally well understood, we will ignore those for now. As the other two
-are the focus of AJAX/COMET and thus also the primary domain of Athena, that is
-what we will discuss below.</p>
-
-<p>Browser-to-server calls are made by Athena via the now-famous
- XMLHttpRequest. Server-to-browser calls are opened by the browser ahead of
-time, and when the server is ready, the data is sent to the browser via that
-connection.</p>
-
-<h2>JavaScript: Making Calls to the Server</h2>
-
-<p>When creating the JavaScript portion of our applications, we subclass
-an Athena JavaScript widget, which has a method named
-<code>callRemote()</code>. By utilizing this method, we can send messages from
-our JavaScript client to the server (as long as the method we call exists in
-the server code).</p>
-
-<p>For example, in the chat application we will be building in this series
-of tutorials, we will have a JavaScript class called <code>ChatterBox</code> with a
-<code>say()</code> method, like the following:</p>
-<pre>
-function say(self, msg) {
- self.callRemote("say", msg);
- // Now show the text to the user somehow...
-}
-</pre>
-<p>This will make a remote call to the Python server code, executing the
-<code>say()</code> method and passing the <code>msg</code> variable as a
-parameter.</p>
-
-<p>In Athena, the relationship between the browser code and the server code is
-established by declaring the JavaScript module in the Python server code, in
-the following manner:</p>
-<pre class="python">
-class ChatterBox(LiveElement):
- jsClass = u'ChatThing.ChatterBox'
-</pre>
-<p>Additionally, in order for the JS to be able to make a call to remote Python
-code, the Python method has to be exposed. This is a security feature,
-implemented to ensure the JavaScript code can only call Python methods that
-have been specifically marked as safe. Appropriately enough, this is done in
-your Python class with the <code>expose</code> decorator:</p>
-
-<pre class="python">
-def say(self, text):
- for chatter in chatRoom:
- chatter.youHeardSomething(text)
-say = expose(say)
-</pre>
-
-<h2>Python: Making Calls to the Browser</h2>
-
-<p>Now what about the COMET side of the equation? If we want our server to
-update data in the browser, we need to be able to call JavaScript code from our
-Python server. We use a similar Python method as the JavaScript one (when
-making calls from the browser to the server), acquired when our Python class
-inherited from <code>nevow.athena.LiveElement</code>:</p>
-
-<pre class="python">
-def hear(self, sayer, text):
- self.callRemote("hear", sayer, text)
-</pre>
-
-<p>In order for this call to work, we need to have the <code>hear()</code>
-method defined in our <code>ChatterBox</code> JavaScript class, and that will
-look like this:</p>
-<pre>
-function hear(self, avatarName, text) {
- // Here, you'd show the user some text.
-}
-</pre>
-
-<p>Unlike on our Python classes, no special annotations need to be made on the
-JavaScript side: all JavaScript methods on browser-side Widget objects are
-allowed to be called by the server. If you've sent code to the browser, you've
-already forfeited the ability to control when it's called. There wouldn't be a
-point to limiting the server's rights to run its code when the user can freely
-run it herself.</p>
-
-<h2>Summary</h2>
-
-<p>With the samples above, you should have a growing sense of how Python and
-JavaScript interact as servers and clients in the world of Athena. In
-particular, you should be getting a sense of how JavaScript and Python will be
-interacting in your Athena applications.</p>
-
-<p>This has just been a taste of Athena with a few peeks into the code we
-will be writing. We will cover these topics in greater detail in the following
-pages, within the context of creating a functional Athena application,
-complete with step-by-step instructions and rationale.</p>
-
-</body>
-</html>
diff --git a/doc/howto/chattutorial/env.rst b/doc/howto/chattutorial/env.rst
new file mode 100644
index 0000000..718c0a9
--- /dev/null
+++ b/doc/howto/chattutorial/env.rst
@@ -0,0 +1,85 @@
+Setting Up the Tutorial Environment and Running Tutorial Source Code
+====================================================================
+
+To run this tutorial, you need to have nevow available to python and
+you'll need the files in the doc/howto tree. You don't even have to
+install nevow; the examples will run within the source tree.
+
+Combinator: The Divmod Way
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Using SVN with
+`Combinator <http://divmod.org/trac/wiki/DivmodCombinator>`__ is the
+best way to try out the example code in-place (and hop between other SVN
+branches in the future). This is how we develop and test our
+applications at Divmod. If you have a system installation of Twisted
+that you don't want to update or interfere with, you can use this method
+without installing anything.
+
+1. Create a projects directory or change to some other test directory of
+ your choice::
+
+ $ mkdir ~/Projects
+ $ cd ~/Projects
+
+2. If you don't have the `twisted
+ library <http://twistedmatrix.com/trac/>`__, check it out now::
+
+ $ svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk Twisted/trunk
+
+3. Then get Combinator and Nevow (and the rest of Divmod). See the
+ `Combinator
+ Tutorial <http://divmod.org/trac/wiki/CombinatorTutorial>`__ for more
+ about these special checkout paths.::
+
+ $ svn co http://divmod.org/svn/Divmod/trunk Divmod/trunk
+
+4. Set up the Combinator environment in this shell. You'll need this
+ step in any future test shells since it adjusts PATH and PYTHONPATH::
+
+ $ eval ``python Divmod/trunk/Combinator/environment.py``
+ $ # (some "link:" lines are normal)
+
+5. Register both the Twisted and Divmod (and thus Nevow+Athena)
+ codebases with Combinator::
+
+ $ chbranch Twisted trunk
+ $ chbranch Divmod trunk
+
+6. You can check to see if your environment is ready to go by running
+ the tutorial tests (from any directory, after executing the previous
+ command)::
+
+ $ trial nevow.test.test\_howtolistings
+
+If they all pass, you're ready to begin the tutorial.
+
+Standard distutils Installation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you don't want to manage branches and environments with Combinator,
+you can install our code in the standard ``site-packages`` directory.
+You'll still need the source tree so you can use the files in doc/howto.
+
+For those that would prefer the old way, here's how you do it:
+
+1. Create a projects directory::
+
+ $ mkdir ~/Projects
+ $ cd ~/Projects
+
+2. Checkout and install the latest Twisted::
+
+ $ svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk Twisted
+ $ cd Twisted
+ $ sudo python setup.py install
+ $ cd ../
+
+3. Checkout and install Nevow::
+
+ $ svn co http://divmod.org/svn/Divmod/trunk/Nevow Nevow
+ $ cd Nevow
+ $ sudo python setup.py install
+ $ cd ../
+
+
diff --git a/doc/howto/chattutorial/env.xhtml b/doc/howto/chattutorial/env.xhtml
deleted file mode 100644
index e721ab2..0000000
--- a/doc/howto/chattutorial/env.xhtml
+++ /dev/null
@@ -1,122 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
-"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>Setting up an Environment</title>
- </head>
-<body>
-
-<h1>Setting up an Environment</h1>
-
-<h2>Install</h2>
-
-To run this tutorial, you need to have nevow available to python and
-you'll need the files in the doc/howto tree. You don't even have to
-install nevow; the examples will run within the source tree.
-
-
-<h3>Combinator: The Divmod Way</h3>
-
-<p>Using SVN
-with <a href="http://divmod.org/trac/wiki/DivmodCombinator">Combinator</a>
-is the best way to try out the example code in-place (and hop between
-other SVN branches in the future). This is how we develop and test our
-applications at Divmod. If you have a system installation of Twisted
-that you don't want to update or interfere with, you can use this
-method without installing anything.
-</p>
-
-<ol>
-
-<li>Create a projects directory or change to some other test directory
-of your choice:
-<pre class="shell">
-$ mkdir ~/Projects
-$ cd ~/Projects
-</pre>
-</li>
-
-
-<li>If you don't have the
-<a href="http://twistedmatrix.com/trac/">twisted library</a>, check it out now:
-<pre class="shell">
-$ svn co svn://svn.twistedmatrix.com/svn/Twisted/trunk Twisted/trunk
-</pre>
-</li>
-
-<li>Then get Combinator and Nevow (and the rest of Divmod). See the
-<a href="http://divmod.org/trac/wiki/CombinatorTutorial">Combinator
-Tutorial</a> for more about these special checkout paths.
-<pre class="shell">
-$ svn co http://divmod.org/svn/Divmod/trunk Divmod/trunk
-</pre>
-</li>
-
-<li>Set up the Combinator environment in this shell. You'll need this
-step in any future test shells since it adjusts PATH and PYTHONPATH:
-<pre class="shell">
-$ eval `python Divmod/trunk/Combinator/environment.py`
-(some "link:" lines are normal)
-</pre>
-</li>
-
-<li>Register both the Twisted and Divmod (and thus Nevow+Athena) codebases with
-Combinator:
-<pre class="shell">
-$ chbranch Twisted trunk
-$ chbranch Divmod trunk
-</pre>
-</li>
-
-<li>You can check to see if your environment is ready to go by running the
-tutorial tests (from any directory, after executing the previous command):
-<pre class="shell">
-$ trial nevow.test.test_howtolistings
... 7420 lines suppressed ...
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/nevow.git
More information about the Python-modules-commits
mailing list