Skip to content

P
pylibs
Commit 5664f5f3 authored by root's avatar root
Browse files
Options

Add nevow for py3

parent 7fb41afc
Hide whitespace changes
Inline Side-by-side
Showing with 59066 additions and 1 deletion

Too many changes to show.
Plain diff Email patch

To preserve performance only 351 of 351+ files are displayed.

TxScheduling/txscheduling/cron.py
View file @ 5664f5f3
......@@ -12,8 +12,9 @@ from txscheduling.interfaces import ISchedule
txscheduling.interface.ISchedule interface along with two useful
functions for parsing cron lines. """
@zope.interface.implementer(ISchedule)
class CronSchedule(object):
zope.interface.implements(ISchedule)
#zope.interface.implements(ISchedule)
_minutes = None
_hours = None
......
nevow/.gitattributes 0 → 100644
View file @ 5664f5f3
nevow/_version.py export-subst
nevow/.gitignore 0 → 100644
View file @ 5664f5f3
*.pyc
*.egg-info
*.cache
*.swp
_trial_temp
build
nevow/.travis.yml 0 → 100644
View file @ 5664f5f3
sudo: false
language: "python"
python:
- "pypy"
- "2.7"
env:
#
# The `MODE` environment variable will control the kind of Nevow installation
# being tested. See below for the precise meaning of each mode.
#
#
# The `TWISTED` environment variable will give a (shell expression which
# evaluates to) a Twisted requirement string which can be used to select a
# version of Twisted to install. This lets the test suite run against
# multiple versions of Twisted. As a cop out, this configuration only
# actually tests the minimum supported version of Twisted, the latest release
# of Twisted, and the master@HEAD version of Twisted.
#
# For expediency, all combinations of `MODE` and `TWISTED` are not tested.
# The "wheel" MODE is (arbitrarily) selected and all values of `TWISTED` are
# exercised in that mode.
#
- MODE=inplace
- MODE=source
- MODE=sdist
- MODE=wheel
- MODE=wheel
TWISTED='echo twisted'
- MODE=wheel
TWISTED='echo -n "twisted=="; python -c "from setup import _MINIMUM_TWISTED_VERSION; print _MINIMUM_TWISTED_VERSION"'
- MODE=wheel
TWISTED='echo git+https://github.com/twisted/twisted.git'
install:
- "python setup.py --version"
- |
# If appropriate, install a specific version of Twisted.
if [ -v TWISTED ]; then
pip install "$(eval ${TWISTED})"
fi
- |
if [ "${MODE}" == "wheel" ]; then
# Build and install a wheel of Nevow.
pip install wheel
python setup.py bdist_wheel
# Install whatever was just built. The filename is tricky to figure
# out because wheels mangle the version in certain ways. Replicate
# some of that mangling here.
pip install dist/Nevow-"$(python setup.py --version | tr - _)"-py2-none-any.whl
# Also install the extra documentation requirements. Unfortunately, it
# seems pip doesn't automatically handle that case when installing from
# a built file.
pip install Sphinx
elif [ "${MODE}" == "sdist" ]; then
# Build and install a normal source distribution
python setup.py sdist
pip install dist/Nevow-"$(python setup.py --version)".tar.gz
# Also install the extra documentation requirements. Unfortunately, it
# seems pip doesn't automatically handle that case when installing from
# a built file.
pip install Sphinx
elif [ "${MODE}" == "inplace" ]; then
# Don't actually install anything. Just update the environment to make
# the source in the git checkout importable. Then run the tests
# directly against that. This is kind of a "control" case. These
# results should be very similar to the results for any of the
# installation cases.
# Note that we also install the documentation requirements.
pip install --editable '.[doc]'
elif [ "${MODE}" == "source" ]; then
# Install directly from the git checkout.
pip install '.'
# Also install the extra documentation requirements. Unfortunately, it
# seems this can't be specified to the install command above.
pip install Sphinx
fi
script:
- "trial formless nevow"
- "make -C doc html"
nevow/ChangeLog 0 → 100644
View file @ 5664f5f3
2006-06-12 Glyph Lefkowitz <glyph@divmod.com>
* Nevow 0.9.0: see NEWS.txt for details.
2006-04-07 Jp Calderone <exarkun@divmod.com>
* Nevow 0.8.0 released
2006-03-30 Tommi Virtanen <tv@twistedmatrix.com>
* nevow/static.py: Fix handling of range requests on static files.
2006-03-30 Jp Calderone <exarkun@divmod.com>
* formless/freeform-defaults.css, formless/annotate.py: Style and
feedback improvements.
2006-03-29 Jp Calderone <exarkun@divmod.com>
* examples/formbuilder/: Apply Cory Dodt's patch to make this
example work again.
2006-03-27 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Add getInitialArguments method which will be
invoked during rendering and may return a list or tuple of objects
which will be be passed to the client-side Widget's __init__ method.
2006-03-24 Allen Short <washort@divmod.com>
* Upgrade MochiKit to 1.2
2006-03-17 Tristan Seligmann <mithrandi@mithrandi.za.net>
* Remove usage of twisted.python.components.Interface from formless.
Convert TypedInterface to zope.interface.
2006-03-17 Jp Calderone <exarkun@divmod.com>
* nevow/json.py: Improve (hopefully correct this time ;) unicode
support.
2006-03-08 Valentino Volonghi <dialtone@divmod.com>
* Remove usage of twisted.python.components.Interface from nevow.
Remove compyCompat.
2006-02-28 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Make the "Connection: Close" header of Athena
transport responses optional (toggleable by a flag on LivePage) to
allow TCP connection setup overhead to be avoided.
2006-02-15 Tristan Seligmann <mithrandi@mithrandi.za.net>
* nevow/athena.js, nevow/athena.py: Pass JavaScript call-stack
information back to the server and include it in logged tracebacks
(Firefox only).
2006-02-14 Jp Calderone <exarkun@divmod.com>
* nevow/util.py: Delete a bunch of code duplicated from Twisted.
2006-02-06 Glyph Lefkowitz <glyph@twistedmatrix.com>
* nevow/athena.py, nevow/athena.js: Pop up an obnoxious widget when
an Athena connection is lost.
2006-02-06 Jp Calderone <exarkun@divmod.com>
* nevow/runtime.js: Add Platform.getPage, a wrapper around the
browser-provided HTTP request function.
2006-02-01 Tristan Seligmann <mithrandi@mithrandi.za.net>
* nevow/athena.js: Add support for <athena:handler> element, a
declarative mechanism for attaching event handlers to nodes.
2006-02-01 Tristan Seligmann <mithrandi@mithrandi.za.net>
* bin/nit: Test collector/runner for Athena widgets.
2006-02-01 Jp Calderone <exarkun@divmod.com>
* nevow/defer.js: Deferred implementation to replace MochiKit
Deferreds.
2006-01-21 Valentino Volonghi <dialtone@divmod.com>
* nevow/rend.py, formless/webform.py: Support Deferreds returned
from bind_ methods.
2006-01-21 Valentino Volonghi <dialtone@divmod.com>
* nevow/flat/flatstan.py: Fix macros inside of other specials.
2006-01-19 Jp Calderone <exarkun@divmod.com>
* nevow/athena.js: Added Divmod.Class.methods() for defining
multiple methods at once.
2006-01-19 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py, nevow/athena.js: Support the addition of
LiveFragment instances to a page after the initial render pass.
2006-01-15 Jp Calderone <exarkun@divmod.com>
* nevow/athena.js: Introduced new form of Divmod.Class.method() for
adding methods to JavaScript classes. Added a child-window based
log viewer.
2006-01-08 Valentino Volonghi <dialtone@divmod.com>
* examples/hello/hellohtml.py: Removed htmlfile usage
* nevow/loaders.py: Deprecated htmlfile/htmlstr
2006-01-08 Glyph Lefkowitz <glyph@twistedmatrix.com>
* nevow/test/, formless/test/: Removed all usage of trial's
deferredResult() and util.wait() functions.
2006-01-04 Glyph Lefkowitz <glyph@twistedmatrix.com>
* nevow/athena.py: Added fragment and widget nesting. On the
server side, this documents and provides a supported way of
setting the magical required "page" attribute. On the client
side, this provides a convenient hook for multiple widgets within
a page to communicate with each other.
2005-12-26 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Added athena.js and MochiKit.js to the dictionary
returned by allJavascriptModules(), allowing them to be referenced
using the JS import mechanism, in turn allowing them both to be
served from a single site-wide URL, rather than once per page.
2005-12-22 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Remove Python 2.4 dependencies.
2005-12-21 Jp Calderone <exarkun@divmod.com>
* Nevow 0.7.0 released
2005-12-18 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Server-side processing of .js files to allow for
an import directive. Imported JavaScript modules are inserted into
the page during the render process in dependency order.
* nevow/widget.js: Athena Widgets class and support code definitions
moved here.
2005-12-13 Matt Goodall <matt@pollenation.net>
* nevow/athena.js: Improved IE compatibility.
2005-12-05 Jp Calderone <exarkun@divmod.com>
* nevow/athena.js: Added Divmod.Class object which provides a
class-based object model for JavaScript programs. Added
Nevow.Athena.Widget, a base class for "Live Widgets" - JavaScript
classes which can control a particular section of a LivePage and can
communicate with corresponding LiveFragment instances on the server.
* nevow/athena.py: Added a callRemote method to LiveFragment - this
allows the server to invoke methods on particular Widgets on the
client.
2005-12-03 Jp Calderone <exarkun@divmod.com>
* nevow/rend.py: Fixed a bug in xmlfile caching which could lead to
a corrupt loader cache.
2005-11-29 Jp Calderone <exarkun@divmod.com>
* nevow/appserver.py: Removed "support" (which consisted of logging
an error message and continuing) for returning objects which do not
provide IResource.
2005-11-26 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py, nevow/athena.js: Use POST for the LivePage
transport, rather than GET.
* nevow/json.py: Fix a bug in JSON support for floating points.
2005-11-25 Jp Calderone <exarkun@divmod.com>
* nevow/athena.js: Go live by default.
2005-11-22 Glyph Lefkowitz <glyph@divmod.com>
* nevow/guard.py: Removed __session_just_startd__.
2005-11-15 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: Added LiveFragment - base class for Fragments
which may cooperatively share a single LivePage connection.
2005-11-09 Jp Calderone <exarkun@divmod.com>
* Athena JavaScript API unified into a pseudo-namespace hierarchy.
2005-11-07 Jp Calderone <exarkun@divmod.com>
* JSON serializer now quotes dict/object keys.
2005-11-02 Jp Calderone <exarkun@divmod.com>
* Nevow 0.6.0 released
2005-09-21 Jp Calderone <exarkun@divmod.com>
* nevow/athena.py: New implementation of LivePage with a
data-centric API: generation of JavaScript on the server is highly
discouraged, instead an API for passing around simple or complex
data structures is provided.
2005-08-01 Matt Goodall <matt@pollenation.net>
egg-ify the distribution. "python setup.py bdist_egg" will now build
a .egg in dist for Python 2.3 and Python 2.4.
2005-07-14 Donovan Preston <dp@divmod.org>
* It's no longer necessary to specify addSlash = True on
the root resource. nevow.appserver.NevowSite automatically
sets it on the first argument you pass to it (the root
resource).
2005-07-12 Donovan Preston <dp@divmod.org>
* Usability improvements for formless at the expense of
purity of abstraction. Since the only thing anybody uses
formless for is rendering web forms, make it a little easier
to do common things. For example:
- _nevow_carryover_ does not get appended to URLs unless absolutely
necessary (because you return a value from an autocallable)
- TypedInterface is being deprecated in favor of using
IConfigurable directly, and an IConfigurable implementation
on Fragment/Page that is easy to use. To expose a "foo" method
on a page which takes a "bar" string and a "baz" integer, do this:
def bind_foo(self, ctx):
return [('bar', String()), ('baz', Integer())]
Previously, you would have had to create a TypedInterface,
declare foo and the types of the arguments in the class body,
declare that foo is autocallable, and declare that your Page
class __implements__ the interface. Now, just implement
bind_foo to return an IBinding or a list which can be munged
into one.
- It is possible to return a Page from an autocallable to have
that page displayed directly after posting the autocallable.
The URL that is used is freeform_hand, which means that the
Page goes into your "hand" in the session. The hand can only
hold one value, the most recent return result of an autocallable.
This isn't very back-button friendly but it makes it super
easy to put together a multi-step wizard interface.
See examples/tests/testformless.py and the /testformless on
the example server to see how to do this.
- It is possible to return a URL instance from an autocallable
to have the user redirected to that page after posting the
form successfully. This replaces and deprecates the old,
whacko method of setting IRedirectAfterPost on the Request.
See examples/tests/testformless.py and the /formless_redirector
on the example server to see how to do this.
* There is now livetest coverage of the formless examples,
including posting forms and checking erroneous conditions.
2005-07-06 Donovan Preston <dp@divmod.org>
* Major non-backwards-compatible improvements to livepage. Changes
are designed to avoid an uncollectable garbage problem which was
inherent in the previous design.
The livepage javascript glue now includes a global object named
"server". This object has a "handle" method which takes at least
one argument, a string indicating the name of the handler to
invoke on the server. When called by client-side javascript,
LivePage.locateHandler is invoked. locateHandler should return
a callable which will be called with a context indicating
which client is invoking the method, and any additional arguments
which were passed to server.handle, as strings.
The default implementation of LivePage.locateHandler looks for
a correspondingly named "handle_*" method. Using livepage is
now as simple as subclassing LivePage and providing handle_*
methods:
class Foo(LivePage):
def handle_bar(self, ctx, something):
print "something!", something
And calling server.handle in javascript:
<a onclick="server.handle('bar', 'here is something')">Click me</a>
The previous behavior of registering closures or other callables
as event handlers and then embedding them in the page is still
available using the IClientHandle.transient method. These one-
shot handlers are only invokable by the client once before being
garbage collected on the server. This makes it possible to
implement temporary dialog boxes and the like.
2005-04-09 Tommi Virtanen <tv@twistedmatrix.com>
* Allow remembering ILogger to specify an alternate access logging
method.
2005-04-06 Matt Goodall <matt@pollenation.net>
* Added optional context argument to Page's renderString and
renderSynchronously methods. This provides a site-like context that is
useful when rendering multiple pages that need common remembered data.
2005-3-23 Donovan Preston <dp@divmod.org>
* Releasing 0.4.1
2005-3-22 Donovan Preston <dp@divmod.org>
* Releasing 0.4
2005-02-22 Matt Goodall <matt@pollenation.net>
* Added a "data" renderer (rend.data) that replaces the tag's content
with the current data. i.e. <p n:data="name" n:render="data">Foo Bar</p>.
2005-02-17 Matt Goodall <matt@pollenation.net>
* Added i18n - a gettext-like mechanism for marking translatable content
in an application's Python modules by wrapping a string in _(). Standard
Python gettext tools can be used to generate translation files.
Translation happens during rendering and depends on a list of languages
found in the context. By default, the browser's preferred languages are
used. The default behaviour can be overridden by remembering the languages
as inevow.ILanguages in the context; allowing the language to be selected
from user preferences, for example.
2005-02-08 Matt Goodall <matt@pollenation.net>
* Extended the IDocFactory interface's load method to accept an optional
context.
The current loaders do not use the context but future loaders may, i.e. one
that loads a localised template based on some language in the context.
2005-01-01 Donovan Preston <dp@divmod.org>
* Rewrote LivePage quoting code to be much more correct; added many unit
tests. Some older livepage code must be changed to use the
livepage.literal object instead of passing normal strings to handler or
the LivePage client APIs.
* Added nevow.livepage module, LivePage, and ILivePage. The name liveevil
is deprecated.
2004-12-23 Phil Frost <indigo@bitglue.com>
* Added support for formless to return unicode objects. annotate.String
and subclasses (Text, Password, etc.) take a 'unicode' parameter to
enable unicode, like so:
| annotate.String(unicode=True)
The coerced value will then be a unicode object.
2004-12-16 Matt Goodall <matt@pollenation.net>
* Added ObjectContainer - a data directive accessor for retrieving an
attribute of an object. If the current data in the context (the IData) is an
object you can register ObjectContainer as the IContainer adapter for the
object's class and Nevow will automatically look inside the object to fetch
the attribute.
Note: ObjectContainer is *not* registered as the adapter for all object
types. You must explicitly register the adapter for application classes as
needed.
2004-12-08 Matt Goodall <matt@pollenation.net>
* Applied the foom/mesozoic patch to make Page.remember work correctly and
without the hack. You can now use the method reliably to remember objects at
Page construction time or any other time before the PageContext is created.
The remembered objects can be found from the context in the usual way.
class MyPage(rend.Page):
def __init__(self, original):
# Make original available as ISomething(ctx) for later.
self.remember(original, ISomething)
rend.Page.__init__(self, original)
* Added a similar remember method for NevowSite (and made a SiteContext
object the ultimate parent). You can know remember objects on the site and
have them available anywhere there's a context. A typical use case is making
some object store available to the site. This was often achieved using a
wrapper resource but now it's as easy as:
store = makeStore()
site = NevowSite(rootResource)
site.remember(store, IStore)
2004-12-08 Matt Goodall <matt@pollenation.net>
* Renamed URL.fromRequest to URL.fromContext. URL.fromRequest was a little
confusing - the URL it returned only included the segments that had been
consumed so far by the locateChild process and not the whole URL as the name
might suggest. Eventually, fromRequest will change to return a full URL but,
for now, its use is deprecated.
* Renamed URL.parent to URL.parentdir. URL.parent() was logically equivalent
to '..' and so removed more segments than expected. URL.parent's use is now
deprecated and in a future release will be changed to remove exactly one
segment.
* Improve URL.click to normalise any segments of '.' or '..'. Browsers
normalise the URL so, according to the docstring, click should too.
2004-12-04 Donovan Preston <dp@divmod.org>
* Added macros! This is the same patch as the one I attached to my
"Macros in Nevow" mail, with the addition of an IMacroFactory,
a MacroFactory implementation on rend.Page, and macro directive
support. Macros are like render functions that take only the
context (no data parameter) and run only once during the lifetime
of a template loader. Here is an example of the difference between
a macro and a renderer:
>>> class Bumper(object):
... num = 0
... def bump(self):
... self.num += 1
... return self.num
...
>>> staysTheSame = Bumper()
>>> changes = Bumper()
>>> from nevow import flat, tags, loaders
>>> document = loaders.stan([tags.invisible(macro=lambda ctx: staysTheSame.bump()), tags.invisible(render=lambda ctx, data: changes.bump())])
>>> flat.flatten(document)
'11'
>>> flat.flatten(document)
'12'
>>> flat.flatten(document)
'13'
2004-12-01 Donovan Preston <dp@divmod.org>
* Added __iter__ to nevow.stan.slot to prevent infinite loops by
trying to do "for x in slot('foo'): print x".
* Added an IGettable adapter for nevow.stan.slot. It is now possible
to specify a slot as the data for a node, so the following example
would work:
from nevow import rend, tags
def fillEm(ctx, data):
ctx.fillSlots('value', [1, 2])
return ctx.tag
tags.html(render=fillEm)[
tags.ul(data=tags.slot('value'), render=rend.sequence)[
tags.li(pattern='item')[
str ]]]
2004-09-26 Donovan Preston <dp@divmod.org>
* Added nevow.inevow.IQ interface, an interface for querying the
stan DOM. Eventually, this interface will contain APIs for doing
traditional DOM introspection, such as iterating children,
examining tag names, and examining attributes. For now, it contains
only the patternGenerator, onePattern, and allPatterns APIs. These
APIs have been deprecated from Context.
The main benefit of this is the ability to do:
IQ(loaders.xmlfile(...)).patternGenerator(...)
which would be nice for creating "pattern library" files containing
common skin idioms which can then be copied and used throughout
the app.
2004-09-25 Donovan Preston <dp@divmod.org>
* Chatola received a major facelift, bringing it from cool demo
up to almost a full fledged web-based chat server. The helper API
LiveEvil.call(...) was added, which deprecates
LiveEvil.sendScript(callJS(...))
2004-09-23 Tommi Virtanen <tv@twistedmatrix.com>
* Make guard.SessionWrapper store its URL location in all requests it
passes to its children. This allows the children know where to post
the __login__ and __logout__ forms, even deep inside the resource
tree (fixes issue59).
* Guard now works as a non-root resource, with help from the above
change. Semantics of __login__ clarified in unit tests; if your guard
is at /foo, posting to /foo/__login__ redirects to /foo, and posting
to /foo/__login__/ redirects to /foo/. The two unit tests that failed
earlier now pass (with that change in their __login__ URLs).
* If URL-based sessions are used, login no longer loses session
information due to redirect to / (fixes issue56).
2004-09-20 Matt Goodall <matt@pollenation.net>
* Added URL.secure() method to make switching between http and
https easier.
2004-09-08 Donovan Preston <dp@divmod.org>
* Nevow now includes a very simple proof-of-concept WSGI Application
implementation, and can be used with no Twisted dependency. Nevow can
also be used to write CGIs, either using a simple CGI WSGI gateway
(which supports URL traversal), or by using Page.renderString (which does not).
* Two new context interfaces, ICurrentSegments and IRemainingSegments,
replace the need to examine the Request prepath and postpath attributes
directly.
* ISerializable is deprecated, and has been replaced with a simple
Flattener registry. nevow.flat.registerFlattener and
nevow.flat.getFlattener have been added to support this.
2004-09-06 Donovan Preston <dp@divmod.org>
* BACKWARDS INCOMPATIBLE CHANGE. Page.configurable_ *always* returns
self, and a new Page.configurable_original *always* returns
self.original. If you were relying on Page.configurable_'s
introspection behavior and are now getting errors about adapting
to IConfigurable, change your renderForms() calls to:
renderForms('original')
This causes Page.configurable_original to be invoked and
introspected for form rendering.
2004-08-23 Donovan Preston <dp@divmod.org>
* LivePage uses a simpler implementation strategy which requires
the browser to make one request per output event. As a result,
LivePage now works on Mozilla, Safari, and Internet Explorer Windows.
2004-08-05 Donovan Preston <dp@divmod.org>
* Implemented support for IFoo(ctx) synonym syntax. It does the
same thing as ctx.locate(IFoo)
* Removed Resource Generators, a feature of NevowSite that nobody
used and wasn't really useful.
* Changed all inevow.IResource apis to take a Context object
where they used to take the request. Remembering objects in
PageContexts is now much easier, and fewer hacks are required to
build the context chain. The context chain now looks like:
SiteContext->RequestContext->PageContext(s)->WovenContext(s)
2004-7-28 Donovan Preston <dp@divmod.org>
* Parameterize data_* methods in the same way as render_* methods.
Patch by k3mper.
For example, <div nevow:data="foo bar,baz" /> will cause
data_foo(self, bar, baz) to be called with the strings "bar" and
"baz". This data method should return a callable taking ctx, data.
The return value of this callable will be remembered as IData at
this point in the context stack.
* Added list-slicing support to ListContainer. You may now use
list slicing syntax in a data directive in addition to a simple
index. For example:
def data_aList(self, ctx, data):
return ["Buckle", "My", "Shoe"]
<div nevow:data="aList">
<span nevow:data="1:-1" nevow:render="string" />
</div>
Will render as <div><span>My</span></div>
2004-7-20 Matt Goodall <matt@pollenation.net>
* Modified sax loader to retain doctypes, comments and xmlns attributes.
It's now possible to build XHTML valid pages :).
xmlns attributes are always kept but there are options to ignore the doctype
and comment (at the request of foom, not sure why yet). Right now, the default
is to retain doctypes and comments but you can use the ignoreDocType and
ignoreComment args to the xml loaders and flatsax parse functions. This bit
may change.
* Add a URL -> IResource adapter that performs a HTTP redirect. URLs can then
be returned from locateChild().
2004-06-07 Donovan Preston <dp@divmod.org>
* Added nevow.canvas, an experimental module similar to LivePage
which provides a Python server-side API for drawing arbitrary lines,
curves, and text in the browser. The implementation is socket-based
and asynchronous, so the server can issue drawing commands to the
client at any time.
The idea is to provide a server-side API to the Python programmer
and shield them from implementation details, but the current
implementation uses a pre-compiled Flash movie (which never changes;
we are not generating Flash bytecodes). An implementation using SVG
or Safari's Canvas (nevow.canvas was written before the Safari Canvas
announcement) would be possible.
2004-05-26 Donovan Preston <dp@divmod.org>
* Add URLOverlay.keep, an API which lets you specify which query args
will be carried on from the current page render into the new URL.
2004-05-24 Matt Goodall <matt@pollenation.net>
* Extracted Fragment from Page. Hopefully, it will make it more obvious
that embedding an object with data_ and render_ methods in a stan tree is
possible without using something as "heavy" as Page which is really meant
to be a web resource.
2004-05-23 Donovan Preston <dp@divmod.org>
* Added some useful APIs to LiveEvil for manipulating the client-side
page:
- flt(stan): Flatten some stan, quoting apostrophes as
as appropriate for embedding in javascript
- set(what, to): Set the contents of the client-side node
with the id 'what' to the stan 'to'.
- append(where, what): Append the stan 'what' to the client-
side node with the id 'where'
- alert(what): Show an alert to the user with the text "what"
2004-05-19 Jonathan Simms <slyphon@divmod.com>
* 0.2 released.
2004-05-14 Donovan Preston <dp@divmod.org>
* nevow.url.URLPath is renamed nevow.url.URL
* URL objects are now lazier about casting things to strings; they will
keep track of path segments in a list and defer to the nevow rendering
machinery to do the conversion; This means you can do things like
here.child(deferred) or here.child(function)
* URL objects have a better api for manipulating query arguments
- add(key, value=None) adds a new query arg at the end; the value may
be None if only a query key needs to be added
- replace(key, value) removes all occurrences of 'key' and inserts a
new (key, value) at the same location as the previous first
occurrence of key
- clear() clears all args
2004-05-06 Donovan Preston <dp@divmod.org>
* Merged freeform-patterned branch, a large formless/freeform refactor.
It is now possible to influence the rendering of forms by providing
"patterns" to renderForms.
* Formless is now a top-level package. Freeform has been renamed
formless.webform. It should be possible to use formless outside
the context of nevow for doing things such as validating network
input based on method argument type annotations.
* TypedInterface, autocallable, and all the Typed subclasses are now
in the formless.annotate module.
2004-04-30 Donovan Preston <dp@divmod.org>
* Created nevow.blocks, a module containing helpful code for working
around display: inline-block bugs in Mozilla.
2004-04-27 Donovan Preston <dp@divmod.org>
* IRenderer.__call__ was renamed IRenderer.rend to be more explicit.
2004-04-21 Donovan Preston <dp@divmod.org>
* Implemented nevow.flat.flatten and nevow.flat.precompile, functions
useful for using stan outside of the context of Page classes. Useful
for generating some XML or even raw text; use it any time you want
to convert a tree data structure into a contiguous string!
import random
import string
from nevow import flat
def letters(howMany):
for i in range(howMany):
yield ' ', string.letters[i], '\n'
def outline():
for i in range(5):
yield i, '\n'
yield letters(random.choice(range(7)))
yield '\n'
print flat.flatten(outline())
2004-04-20 Donovan Preston <dp@divmod.org>
* guard sessions are no longer required to use formless.
2004-04-19 Donovan Preston <dp@divmod.org>
* Implemented lazy context factories. It is now possible to register
an adapter against various *Context classes and an interface. They
will be invoked if *Context.locate(interface) is called.
Implemented a lazy ISession adapter against RequestContext, making
it possible to do ctx.locate(ISession), which is nice.
2004-04-16 Donovan Preston <dp@divmod.org>
* Added nevow.entities module, a module containing literals for all of
the valid XHTML entities. For example:
def render_nbsp(self, ctx, data):
from nevow import entities
return entities.nbsp
nevow/LICENSE 0 → 100644
View file @ 5664f5f3
Copyright (c) 2004
Donovan Preston
Matt Goodall
James Y. Knight
Glyph Lefkowitz
JP Calderone
Allen Short
Alex Levy
Justin Johnson
Christopher Armstrong
Jonathan Simms
Phil Frost
Tommi Virtanen
Michal Pasternak
Valentino Volonghi
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
nevow/MANIFEST.in 0 → 100644
View file @ 5664f5f3
include ChangeLog
include LICENSE
include formless/freeform-default.css
include nevow/Canvas.swf
include nevow/athena_private/*.png
include debian/*
recursive-include twisted *.py
recursive-include nevow *.css *.js
include bin/nevow-xmlgettext
graft doc
recursive-include examples *.css *.gif *.html *.jpg *.js *.py *.png *.tac *.mo *.po *.pot *.xml *.sql *.xul
include examples/i18n/update-l10n
include examples/files/words
include examples/pastebin/data
include examples/pastebin/static/robots.txt
include examples/pastebin/TODO
include extras/xhtml-nevow.rnc
include nevow/Canvas.fla
include nevow/canvas.as
include win32/*
prune */.svn
prune doc/html/*.html
include versioneer.py
include nevow/_version.py
nevow/NEWS.rst 0 → 100644
View file @ 5664f5f3
Nevow 0.14.4 (2018-06-13)
=========================
Bugfixes
--------
- Divmod.Runtime.getAttribute now works again on newer Microsoft Edge versions.
(#102)
Nevow 0.14.3 (2017-07-26)
=========================
Bugfixes
--------
- Athena will now time requests out client-side rather than waiting forever (up
to the browser timeout, at least) for a server response that may never come.
(#98)
Misc
----
- #96
Nevow 0.14.2 (2016-08-29)
=========================
Re-release of 0.14.2 due to a release engineering mistake.
No changes other than the version number.
Nevow 0.14.1 (2016-08-29)
=========================
Features
--------
- Nevow will now correctly map the MIME type of SVG files even if the
platform registry does not have such a mapping. (#88)
- Athena no longer logs widget instantiation on initial page load.
(#92)
Bugfixes
--------
- Nevow's test suite is now compatible with Twisted 16.3. (#82)
- Athena will no longer cause spurious errors resulting from page
disconnection. (#84)
- Athena will now ignore responses to already-responded remote calls
during page shutdown. (#86)
Improved Documentation
----------------------
- Nevow's NEWS file is now generated from news fragments by towncrier.
(#81)
0.14.0 (2016-05-08):
- Fixed compatibility with Twisted 16.1.
- nevow.page rendering speed was increased by about 7% on CPython (2.7.11)
and 58% on PyPy (5.0.1).
0.13.0 (2016-02-16):
- nevow.appserver.Request.headers and received_headers are now deprecated to
follow suit with Twisted; older versions of Nevow will not be compatible
with Twisted 16.0.0 due to these being removed in Twisted.
- nevow.testutil.FakeRequest had similar changes made to assist with
compatibility in test code, and there should be no Nevow code left that
touches the deprecated APIs, but any application code using the old APIs
should be migrated.
- Some very ancient, deprecated things were removed: nevow.canvas,
nevow.livepage, nevow.livetest, nevow.taglibrary (except for the Athena
version of nevow.taglibrary.tabbedPane), nevow.wsgi, and zomne.
0.12.0 (2015-12-16):
- Responses are no longer finished if the connection went away, avoiding an
error message that this used to cause.
- Detach all children on detach (previously only every other child was
detached due to a bug).
- The documentation is now in Sphinx format instead of Lore format.
- Nevow templates now have attributes serialized in a stable order (the
ordering is lexicographic).
- The Athena runtime now works on Internet Explorer versions higher than 7.
- Athena can now handle messages containing `undefined` (this deserializes to
`None`, same as `null`; previously an error would occur).
- Athena no longer logs about receiving duplicate messages (there is nothing
the user / developer can do about these, so the log message didn't serve
any purpose other than flooding your logs).
- connectionMade on Athena widgets is now always invoked before any remote
calls are handled (previously some remote calls might be handled before
connectionMade was invoked).
0.11.1 (2014-06-21):
- The athena-widget twistd plugin is now distributed in the wheel package.
0.11.0 (2014-06-20):
- nevow.json now always emits escaped forms of U+2028 and U+2029.
- formless now works with recent versions of zope.interface without
triggering warnings.
- Several problems in the test suite which resulted in failing tests when
using recent versions of Twisted are now fixed.
- The JavaScript API Divmod.UnitTest.TestCase.assertThrows now accepts
variable arguments to be passed on to the API under test.
- Nevow now unconditionally depends on setuptools for packaging.
- Nevow now uses python-versioneer for version management.
- Nevow now requires Twisted 13.0 or newer.
- The dangerous testing helper module nevow.test.segfault has been removed.
- Nevow is now hosted on Github: https://github.com/twisted/nevow
- Nevow now uses travis-ci for continuous integration:
https://travis-ci.org/twisted/nevow
0.10.0 (2009-11-25):
- Added a system for CSS dependency declarations similar to the one in
Athena for JavaScript.
- Fix Athena's transport cleanup on page unload in Internet Explorer.
- Fix nit's results coloring in Internet Explorer.
- Added an API for declaring JavaScript classes which involves less
repetition than the existing Divmod.Class.subclass API.
- Added human-readable formatting for the new flattener's error reporting;
rendering error stacks will now display lines from Python code as well
as stan and XML templates.
- Override the setuptools sdist command with the original distutils sdist
command to avoid setuptools' version number transformation.
- Added support for default values for slots in XML templates.
- Fixed a problem with setup.py which led to css files not being
installed.
- Removed the old Chatola example and replaced it with a link to the new
chat example.
- Sped up some of the JavaScript dependency calculations.
0.9.33 (2008-12-09):
- Add error handling to the integration between the old flattener
and the new flattener so that if the new flattener fails with an
exception or a Failure the error is propagated properly to the old
flattener which invoked it.
- Changed nit so that it doesn't use private `twistd` APIs and
instead just sets up a server and runs the reactor. This makes
nit work with all versions of Twisted supported by Nevow.
- Changed Nevow's setup.py to use setuptools if setuptools is
available. This has the user-facing consequence of installing
Nevow as an egg if setuptools is available at installation time
and of making Nevow installable using the `easy_install´ tool.
- TabbedPane naively set DOM attributes, making it unusable in
Internet Explorer 6 and 7. Introduced a reliable method for
setting DOM node attributes, with name mangling, to address the
issue.
0.9.32 (2008-08-12):
- A resource wrapper for on-the-fly gzip compression has been added.
- A twistd plugin, 'athena-widget', is now available for serving
single Athena widgets.
- Basic Athena support for Safari added.
- Added file name, line number, and column number information to
slots and tags parsed from XML files in order to make debugging
template/renderer interactions simpler.
- A context-free flattener has been added. Fragment and its
subclasses are now deprecated in favor of Element.
- Javascript classes derived from the tabbedpane class can now
override how tab selection is handled.
0.9.31 (2008-02-06):
- Fixed Guard's request parameter save/restore feature to not
clobber request state after login succeeds when a session has
already been negotiated.
- Added a hook to nevow.guard.SessionWrapper which allows the
domain parameter of the session cookie to be specified.
0.9.30 (2008-01-16):
- Change DeferredSerializer so that it passes failures from the
Deferred being serialized on to the Deferred returned by the
flattening function. Without this behavior, the Deferred
returned by the flattening function is never fired when a
Deferred which fails is serialized.
0.9.29 (2008-01-02):
- Prevent NevowSite.handleSegment from raising IndexError in certain
situations.
- Deprecated wsgi and zomne modules.
0.9.28 (2007-12-10):
- Added two APIs to Athena, one for creating the string used as the id
attribute of the top node of a widget and one for creating the string
used as the id attribute of a node which had an id attribute in the
widget's template document.
0.9.27 (2007-11-27):
- Unicode URLs now supported.
0.9.26 (2007-11-02):
- url.URL.path now correctly escapes segments in the string it
evaluates to.
- inevow.IAthenaTransportable added, along with support for
serialization of custom types for server-to-client Athena
messages.
- Global client-side behaviour is now customizable via a client
PageWidget class.
0.9.25 (2007-10-16):
- The Athena message queue implementation has been improved, fixing problems
masked by bugs in Firebug/YSlow.
0.9.24 (2007-09-05):
- ESC key no longer disconnects Athena connections.
- Fixed a bug where URLs with quote characters will cause the Athena
connection to be lost.
- Fixed 'twistd athena-widget' to create a fresh widget instance for each
hit.
0.9.23 (2007-08-01):
- Fixed install script to include all JavaScript files.
0.9.22 (2007-07-06):
- Mock DOM implementation for easier browser testing added.
- JavaScript source files are now read using universal newlines mode.
- athena.AutoJSPackage now excludes dotfiles.
- url.URL now properly subclassable.
- User-agent parsing added to Athena, to detect known-unsupported browsers.
0.9.21 (2007-06-06):
- Debug logging messages from the reliable message delivery queue
disabled.
0.9.20 (2007-05-24):
- Athena now no longer holds more than one idle transport open to
the browser.
0.9.19 (2007-04-27):
- Changed the styling of the progressbar to work on IE6.
- Athena.Widget.detach added, to allow widgets to cleanly be removed
from a page.
- Athena.Widget.callLater added, a wrapper around setTimeout and
clearTimeout.
- 'athena-widget' twistd command added, for starting a server which
serves a single LiveFragment or LiveElement.
0.9.18 (2007-02-23):
- Athena 'connection lost' notification now styleable via the
'nevow-connection-lost' CSS class.
- The 'runjstests' script has been removed, now that JS tests can be
run with trial.
0.9.17 (2006-12-08):
- More efficient JSON string parsing.
- Give FakeRequests a default status code of OK. Accept all of
FakeRequest.__init__'s arguments in the __init__ of
AccumulatingFakeRequest.
0.9.16 (2006-11-17):
- Updated nit to work with Twisted trunk.
- Athena module import caching has been fixed.
0.9.15 (2006-11-08):
- Changed _LiveMixin rendering to be idempotent to support the case
where a transport hiccup causes a LiveFragment or LiveElement to
be sent to the browser multiple times.
- Improvements to the tests.
0.9.14 (2006-10-31):
- Support code for running non-browser javascript tests has been added.
- Added a workaround for nodeById on widgets not yet added to the document in
IE.
- Athena will now invoke the nodeInserted method (if it exists) on a widget
that it instantiates statically.
- ID rewriting, similar to existing rewriting support for 'id' attributes,
has been added in 'for' and 'headers' attributes of 'label' and 'td'/'th'
elements, respectively.
0.9.13 (2006-10-21):
- Adjust non-selected panes in tabbedpane to be further out of the viewport.
- Convert to using the Javascript module plugin system for Nevow-provided
modules.
0.9.12 (2006-10-17):
- Added id rewriting for LiveElement and LiveFragment, such that id
attributes in a widget template are rewritten so that they are unique to
the widget instance. A client-side API, Nevow.Athena.Widget.nodeById(),
is provided to allow location of these nodes.
0.9.11 (2006-10-10):
- Fixed dynamic widget instantiation in IE.
- Added support for correctly quoting the values of slots which are used as
attributes.
0.9.10 (2006-10-05):
- Minor update to nevow.testutil.
0.9.9 (2006-09-26):
- Several nit changes, including the addition of the "check" method to
Failure, and the addition of an "assertFailure" method.
- The ability to pass Python exceptions to Javascript has been added to
Athena.
- Dynamic module import has been added for the cases where it is necessary
to dynamically add a widget to an existing page.
0.9.8 (2009-09-20):
- A bug in nit that caused it to fail if there were too many tests in a
test case, and swallow failures in some cases, has been fixed.
- Widgets can no longer be added to a page after render time using
Divmod.Runtime.Platform.{set,append}NodeContent. Instead, they must be
added using Nevow.Athena.Widget.addChildWidgetFromWidgetInfo.
0.9.7 (2009-09-12):
- Automatic Athena event handler registration is fixed for all supported browsers
and is no longer document-sensitive (ie, it works inside tables now).
- Nit has gained a new assertion method, assertIn.
0.9.6 (2008-08-30):
- Fixed a bug in the IE implementation of the runtime.js node fetching
functions.
0.9.5 (2006-08-22):
- Instance attributes can now be exposed to Athena with nevow.utils.Expose
and Expose.exposedMethodNames() no longer returns unexposed names.
0.9.4 (2006-08-14):
- Added test method discovery to nit test cases, so multiple test methods
may be put in a single test case.
- use XPath for certain DOM traversals when available. This yields
significant speedups on Opera.
- Made Divmod.Runtime.Platform.getAttribute deal with IE attribute
name-mangling properly.
- Javascript logging is now done in Firebug 0.4 style rather than 0.3.
- Some cases where Deferred-returning render methods raised
exceptions or buried failures were fixed.
- Removed MochiKit. The pieces Nevow depends on have been moved to
Divmod.Base in nevow/base.js.
- Various doc fixes.
0.9.3 (2006-07-17):
- Page rendering now supports preprocessors.
0.9.2 (2006-07-08):
- Fixes to the typeahead demo.
- Elements are now automatically serialized by json, just like Fragments.
0.9.1 (2006-07-05):
- Made nevow.athena.expose the mandatory means of publishing a method to
the browser. The allowedMethods dictionary will no longer be respected.
- Added nevow.page.Element and nevow.athena.LiveElement: these are
preferred over nevow.rend.Fragment and nevow.athena.LiveFragment for all
new development.
0.9.0 (2006-06-12):
- Fixed a bug where nested fragment sending rarely worked.
- Sending large strings in Athena arguments and results is now faster due to
less unnecessary unicode character quoting.
- Module objects are now automatically created for all Athena imports.
- Better error reporting for fragments which are rendered without a parent.
- Disconnect notifiers in Athena pages will no longer clobber each other.
- Many optimizations to javascript initialization.
- Javascript packages are now defined with less boilerplate: a filesystem
convention similar to Python's for module naming, plus one declaration in a
Nevow plugin which indicates the directory, rather than a declaration for
each module.
- Updated README to refer to Athena rather than LivePage
nevow/README.rst 0 → 100644
View file @ 5664f5f3
Divmod Nevow
============
Divmod Nevow is a web application construction kit written in Python. It is
designed to allow the programmer to express as much of the view logic as
desired in Python, and includes a pure Python XML expression syntax named stan
to facilitate this. However it also provides rich support for designer-edited
templates, using a very small XML attribute language to provide bi-directional
template manipulation capability.
Nevow also includes Divmod Athena, a "two way web" or "`COMET`_"
implementation, providing a two-way bridge between Python code on the server
and JavaScript code on the client. Modular portions of a page, known as
"athena fragments" in the server python and "athena widgets" in the client
javascript, can be individually developed and placed on any Nevow-rendered page
with a small template renderer. Athena abstracts the intricacies of HTTP
communication, session security, and browser-specific bugs behind a simple
remote-method-call interface, where individual widgets or fragments can call
remote methods on their client or server peer with one method: "callRemote".
Installation
------------
Before installing Nevow, you should install `Twisted`_, unless you are going to
write very simple CGI applications. Nevow integrates fully with the twisted.web
server providing easy deployment.
Nevow uses the standard distutils method of installation::
python setup.py install
If you do not have Twisted installed, you can run a subset of the tests using
the test.py script. If you have twisted installed, the test.py script will
issue the following trial command::
trial -v nevow.test formless.test
.. _`Twisted`: http://twistedmatrix.com/
Documentation
-------------
More detailed introductory documentation is available in the doc/ directory,
along with the beginnings of a reference manual. A large number of examples are
available in the examples/ directory. These examples require Twisted to run. A
tac file (twisted application configuration) can be started by invoking twistd,
the twisted daemon::
twistd -noy foo.tac
More Information
----------------
Information about `Nevow commits`_ is available on GitHub.
The Nevow git repository can be checked out using::
git clone https://github.com/twisted/nevow.git
Discussion of Nevow occurs on the `twisted.web mailing list`_. The Nevow
developers are also often available for real-time help on the `#twisted.web
channel`_ on irc.freenode.net.
.. _`Nevow commits`: https://github.com/twisted/nevow/commits/master
.. _`twisted.web mailing list`: http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
.. _`#twisted.web channel`: irc://irc.freenode.net/#twisted.web
.. _`COMET`: http://alex.dojotoolkit.org/?p=545
nevow/benchmarks/fragmentvselement.py 0 → 100644
View file @ 5664f5f3
from twisted.internet import reactor
from twisted.internet.defer import succeed
from nevow.appserver import NevowSite
from nevow.rend import Page, Fragment
from nevow.page import Element, renderer
from nevow.loaders import stan
from nevow.tags import directive, div, span
class Static:
docFactory = stan("Hello, world. " * 100)
class StaticFragment(Static, Fragment):
pass
class StaticElement(Static, Element):
pass
class Tiny:
docFactory = stan(div(render=directive("foo")))
class TinyFragment(Tiny, Fragment):
def render_foo(self, ctx, data):
return ctx.tag[span["result"]]
class TinyElement(Tiny, Element):
def foo(self, request, tag):
return tag[span["result"]]
renderer(foo)
class Huge:
docFactory = stan(div[[
div(render=directive("foo"))
for x in range(100)]])
class HugeFragment(Huge, Fragment):
def render_foo(self, ctx, data):
return ctx.tag[span["Hello, ", "world", "!"]]
class HugeElement(Huge, Element):
def foo(self, request, tag):
return tag[span["Hello, ", "world", "!"]]
renderer(foo)
class Nested:
docFactory = stan(div(render=directive("foo")))
def __init__(self, count=6):
self.count = count
class NestedFragment(Nested, Fragment):
def render_foo(self, ctx, data):
if self.count:
return span[NestedFragment(self.count - 1)]
return ctx.tag["Hello"]
class NestedElement(Nested, Element):
def foo(self, request, tag):
if self.count:
return span[NestedFragment(self.count - 1)]
return tag["Hello"]
renderer(foo)
class Deferred:
docFactory = stan(div(render=directive('foo')))
class DeferredFragment(Deferred, Fragment):
def render_foo(self, ctx, data):
return ctx.tag[succeed("foo")]
class DeferredElement(Deferred, Element):
def foo(self, request, tag):
return tag[succeed("foo")]
renderer(foo)
class Compare(Page):
def __init__(self, fragment, element):
self.fragment = fragment
self.element = element
def child_fragment(self, ctx):
return Page(docFactory=stan(self.fragment))
def child_element(self, ctx):
return Page(docFactory=stan(self.element))
class Root(Page):
def child_static(self, ctx):
return Compare(StaticFragment(), StaticElement())
def child_tiny(self, ctx):
return Compare(TinyFragment(), TinyElement())
def child_huge(self, ctx):
return Compare(HugeFragment(), HugeElement())
def child_nested(self, ctx):
return Compare(NestedFragment(), NestedElement())
def child_deferred(self, ctx):
return Compare(DeferredFragment(), DeferredElement())
if __name__ == '__main__':
reactor.listenTCP(8080, NevowSite(Root()))
reactor.run()
nevow/benchmarks/json_string_tokenizer.py 0 → 100644
View file @ 5664f5f3
from __future__ import print_statement, division, absolute_import
from time import time
from twisted.python.usage import Options
from nevow.json import serialize, parse
if __name__ == '__main__':
from json_string_tokenizer import main
raise SystemExit(main())
class StringTokenizer(Options):
optParameters = [
('iterations', 'i', '1000', 'Number of iterations for which to run the benchmark.'),
('scale', 's', '100', 'Factor determining the overall input size.')]
def postOptions(self):
self['iterations'] = int(self['iterations'])
self['scale'] = int(self['scale'])
BASE = 'Hello, world. "Quotes".'
def benchmark(iterations, scale):
"""
Deserialize a string C{iterations} times. Make the string longer based
on C{scale}.
Prints the mean time per parse call.
"""
s = serialize(BASE * scale)
before = time()
for i in range(iterations):
parse(s)
after = time()
print((after - before) / iterations, 'per call')
def main(args=None):
"""
Benchmark nevow.json string parsing, maybe with some parameters.
"""
options = StringTokenizer()
options.parseOptions(args)
benchmark(options['iterations'], options['scale'])
nevow/bin/nevow-xmlgettext 0 → 100755
View file @ 5664f5f3
#!/usr/bin/env python
from nevow.scripts.xmlgettext import run
run()
nevow/bin/nit 0 → 100755
View file @ 5664f5f3
#!/usr/bin/python
from nevow.scripts.nit import run
run()
nevow/debian/changelog 0 → 100644
View file @ 5664f5f3
nevow (0.6.0-1.snapshot) unstable; urgency=low
* SVN snapshot.
-- Tommi Virtanen <tv@debian.org> Sun, 6 Nov 2005 20:45:27 +0200
nevow (0.6.0-1) unstable; urgency=low
* New upstream version. (Closes: #336027)
* Acknowledge NMU (Closes: #319230), but please be more careful in the
future; no NMU patch was sent to BTS
* Remove setupcommon.pyc when cleaning, or dpkg-source will see a binary
file content change.
* Run unit tests when building.
* Clean build tree, distutils fails to remove all of it.
* Change priority to extra, as twisted is extra and nevow depends on it.
-- Tommi Virtanen <tv@debian.org> Sun, 6 Nov 2005 20:26:39 +0200
nevow (0.4.1-1.1) unstable; urgency=low
* NMU
* Add missing build depends in python2.4-dev (Closes: #319230)
* lintian error: fix package description indent for list items.
-- Bastian Kleineidam <calvin@debian.org> Sat, 13 Aug 2005 18:48:20 +0200
nevow (0.4.1-1) unstable; urgency=low
* New upstream version.
* Python 2.4 support.
* Not using upstream tarball as it is too broken compared to
SVN tag; specifically it is missing nevow/Canvas.fla, which
is considered source code.
-- Tommi Virtanen <tv@debian.org> Mon, 27 Jun 2005 15:35:57 +0200
nevow (0.3.0-1) unstable; urgency=low
* New upstream version.
-- Tommi Virtanen <tv@debian.org> Thu, 30 Sep 2004 12:12:44 +0300
nevow (0.2.0-2) unstable; urgency=low
* Build-depend on both python2.3-dev and python-dev, it seems that is
what cdbs wants. (Closes: #257911)
-- Tommi Virtanen <tv@debian.org> Tue, 13 Jul 2004 16:39:17 +0300
nevow (0.2.0-1) unstable; urgency=low
* Initial Release.
-- Tommi Virtanen <tv@debian.org> Tue, 29 Jun 2004 10:26:36 +0300
nevow/debian/control 0 → 100644
View file @ 5664f5f3
Source: nevow
Section: devel
Priority: extra
Maintainer: Tommi Virtanen <tv@debian.org>
Standards-Version: 3.6.2
Build-Depends-Indep: python-dev, python2.3-dev, python2.4-dev, cdbs, debhelper (>= 4.1.68)
Package: python-nevow
Architecture: all
Depends: python (>= 2.3), python (<< 2.4), python2.3-nevow
Description: Web application templating system for Python and Twisted
This is a dummy package that only depends on python2.3-nevow.
Package: python2.3-nevow
Architecture: all
Depends: python2.3, python2.3-twisted
Description: Web application templating system for Python and Twisted
Nevow's main focus is on separating the HTML template from both the
business logic and the display logic, while allowing the programmer
to write pure Python code as much as possible. It separates your code
into 'data' and 'render' functions, a simplified implementation of
traditional MVC. It has various parts which can be used individually
or as a whole, integrated web solution:
.
- XHTML templates: contain no programming logic, only nodes tagged
with nevow attributes
- data/render methods: simplified MVC
- stan: An s-expression-like syntax for expressing xml in pure python
- formless: For describing the types of objects which may be passed
to methods of your classes, validating and coercing string input from
either web or command-line sources, and calling your methods
automatically once validation passes
- freeform: For rendering web forms based on formless type
descriptions, accepting form posts and passing them to formless
validators, and rendering error forms in the event validation fails
- livepage: Cross-browser JavaScript glue for sending client side
events to the server and server side events to the client after the
page has loaded, without causing the entire page to refresh
Package: python2.4-nevow
Architecture: all
Depends: python2.4, python2.4-twisted
Description: Web application templating system for Python and Twisted
Nevow's main focus is on separating the HTML template from both the
business logic and the display logic, while allowing the programmer
to write pure Python code as much as possible. It separates your code
into 'data' and 'render' functions, a simplified implementation of
traditional MVC. It has various parts which can be used individually
or as a whole, integrated web solution:
.
- XHTML templates: contain no programming logic, only nodes tagged
with nevow attributes
- data/render methods: simplified MVC
- stan: An s-expression-like syntax for expressing xml in pure python
- formless: For describing the types of objects which may be passed
to methods of your classes, validating and coercing string input from
either web or command-line sources, and calling your methods
automatically once validation passes
- freeform: For rendering web forms based on formless type
descriptions, accepting form posts and passing them to formless
validators, and rendering error forms in the event validation fails
- livepage: Cross-browser JavaScript glue for sending client side
events to the server and server side events to the client after the
page has loaded, without causing the entire page to refresh
nevow/debian/copyright 0 → 100644
View file @ 5664f5f3
This package was debianized by Tommi Virtanen tv@debian.org on
Sun, 28 Mar 2004 16:44:10 +0300.
It was originally downloaded from http://www.divmod.org/Home/Projects/Nevow/
Upstream Author: Donovan Preston et al <dp@divmod.org>
Copyright:
# See the file LICENSE at the top of the source tree.
nevow/debian/python2.3-nevow.manpages 0 → 100644
View file @ 5664f5f3
doc/man/nevow-xmlgettext.1
nevow/debian/python2.4-nevow.manpages 0 → 100644
View file @ 5664f5f3
doc/man/nevow-xmlgettext.1
nevow/debian/rules 0 → 100755
View file @ 5664f5f3
#!/usr/bin/make -f
# -*- mode: makefile; coding: utf-8 -*-
# Copyright © 2002,2003 Colin Walters <walters@debian.org>
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/python-distutils.mk
DEB_INSTALL_DOCS_python2.3-nevow := doc/*
DEB_INSTALL_EXAMPLES_python2.3-nevow := examples/*
DEB_INSTALL_DOCS_python2.4-nevow := doc/*
DEB_INSTALL_EXAMPLES_python2.4-nevow := examples/*
DEB_DH_ALWAYS_EXCLUDE := .svn
docdir = debian/$(1)/usr/share/doc/$(1)
binary-post-install/%::
grep -v '^# See the file LICENSE' \
'$(call docdir,$*)/copyright' \
>'$(call docdir,$*)/copyright.tmp'
cat LICENSE \
>>'$(call docdir,$*)/copyright.tmp'
mv \
'$(call docdir,$*)/copyright.tmp' \
'$(call docdir,$*)/copyright'
# see http://bugs.debian.org/295906
cdbs_python_ver = $(filter-out -%,$(subst -, -,$(patsubst python%,%,$(cdbs_curpkg))))
$(patsubst %,binary-post-install/%,$(DEB_PYTHON_REAL_LIB_PACKAGES)):: binary-post-install/%:
set -e; for file in debian/$(cdbs_curpkg)/usr/bin/*; do \
sed '1s|.*|#!/usr/bin/python$(cdbs_python_ver)|' $$file >\
"$${file}$(cdbs_python_ver)";\
rm -- "$$file";\
chmod 755 "$${file}$(cdbs_python_ver)";\
mv "debian/$(cdbs_curpkg)/usr/share/man/man1/$$(basename "$$file").1" \
"debian/$(cdbs_curpkg)/usr/share/man/man1/$$(basename "$$file")$(cdbs_python_ver).1";\
done
binary-post-install/python2.3-nevow::
set -e; for file in debian/$(cdbs_curpkg)/usr/bin/*;\
do target="$$(echo "$$file" | sed 's/$(cdbs_python_ver)$$//')";\
ln -s "$$(basename "$$file")" "$$target";\
manname="$$(basename "$$target").1.gz";\
ln -s "$$(basename "$$file").1.gz" \
"debian/$(cdbs_curpkg)/usr/share/man/man1/$$manname";\
done
clean::
rm -f setupcommon.pyc
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
TRIAL=trial$(cdbs_python_ver)
TOPMODULES:=nevow formless
$(patsubst %,binary-post-install/%,$(DEB_PYTHON_REAL_LIB_PACKAGES)):: binary-post-install/%:
PYTHONPATH='debian/$(cdbs_curpkg)/usr/lib/python$(cdbs_python_ver)/site-packages/' \
'$(TRIAL)' --bwverbose -R $(TOPMODULES)
# Importing the modules generates .pyc files, and dh_python (which
# normally cleans them) has already been run. Remove them manually.
find 'debian/$(cdbs_curpkg)' -name '*.py[co]' -print0 \
| xargs -0 rm -f --
endif
clean::
rm -rf _trial_temp
# distutils is sloppy and only cleans with the default python version,
# leaving all the other stuff still in build
clean::
rm -rf build
nevow/doc/Makefile 0 → 100644
View file @ 5664f5f3
# 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."
nevow/doc/conf.py 0 → 100644
View file @ 5664f5f3
# -*- 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('..'))
from nevow import __version__
# -- 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 = 'Nevow'
copyright = '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 = __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', 'Nevow Documentation',
'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', 'Nevow Documentation',
['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', 'Nevow Documentation',
'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
nevow/doc/howto/chattutorial/concepts.rst 0 → 100644
View file @ 5664f5f3
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.
nevow/doc/howto/chattutorial/env.rst 0 → 100644
View file @ 5664f5f3
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 ../
nevow/doc/howto/chattutorial/index.rst 0 → 100644
View file @ 5664f5f3
Nevow Athena from Scratch, or The Evolution of a Chat Application
=================================================================
The Chat Tutorial Series
------------------------
Athena is the JavaScript engine behind Nevow, providing a great deal of
resources and power to the developer of asynchronous web applications.
To demonstrate this, we are using a web chat application as our primary
example in this tutorial. The tutorial is split into several parts: a
few introductory pages and then independent (but related) tutorials of
increasing complexity.
.. toctree::
:maxdepth: 2
intro
concepts
env
part00/index
part01/index
History
-------
Nevow's predecessor was Woven (and prior to that, WebMVC). Woven had
something called ``LivePage`` that was doing DOM manipulation as far
back as 2002. In early 2003, Woven event handlers supported sending
JavaScript back to the user's browser, allowing pages to be updated in
response to user-generated events. The earliest publicly visible
revisions of Nevow made use of XHR (XMLHttpRequest) in early 2004. These
facts are notable because Nevow was using AJAX a year before the term
was coined in 2005 and had working code in 2002 and 2003 that predated
Netscape publishing articles on what they called Inner Browsing where
all navigation takes place withing a single page.
Again taking the lead, Athena offers features which developers cannot
find elsewhere. In this series, we attempt to expose these excellent
qualities to the world of application developers.
nevow/doc/howto/chattutorial/intro.rst 0 → 100644
View file @ 5664f5f3
Introduction
============
Who is this tutorial for?
-------------------------
This tutorial is for people who want to build interactive client-server
functionality where a web-browser is the client. It will show you how to
build a live, interactive chat application that requires nothing more
than a web browser that supports JavaScript.
The interesting thing about a chat application, which shows why Nevow
Athena is special, is that it involves two-way communication. In other
words, it involves not only the recently-popular AJAX (the web browser
sending commands to the server without loading a new page) but also the
trickier and, in our opinion, somewhat cooler technique known as COMET
(the web server sending commands to the *browser*).
Who is this tutorial *not* for?
-------------------------------
Nevow Athena is *not* for people who want a normal web application
framework. If you want one of those, you should use non-
Athena-\ `Nevow <http://divmod.org/trac/wiki/DivmodNevow>`__,
`Django <http://www.djangoproject.com/>`__,
`TurboGears <http://turbogears.org/>`__, or maybe even `Ruby On
Rails <http://rubyonrails.org/>`__. Athena doesn't work in terms of
pages, links, or HTTP requests and responses; it is a client-server
framework that works in terms of widgets, JavaScript objects, and
symmetric asynchronous message queues.
However, as alluded to above, Athena is part of a larger framework,
Nevow, which can be used to build more general-purpose and traditional
web applications.
AJAX
----
AJAX isn't a technology in and of itself, bur rather an amalgam of
technologies used together in order to accomplish the goal of making web
applications more responsive than traditional delivery and interactive
mechanisms, such as HTML forms submitted to a server.
In particular, AJAX consists of the following:
- Asynchronous communications from a user's browser to a server
- JavaScript
- Exchanged data (usually XML or JSON)
COMET
-----
Historically, the focus of AJAX technologies was user-event driven.
However, with the need to update the user's browser with events
generated at the server, a solution more sophisticated than AJAX was
needed; this has been dubbed COMET. Athena is implemented using both
AJAX and COMET techniques, and therefore allows two-way browser <->
server communications.
Athena Basics
-------------
We've provided brief background information on AJAX/COMET, but what is
the purpose of Athena? What makes Athena different than other solutions?
Here are a few key points that should help with these questions:
- Athena exists to make writing COMET web applications easy.
- Athena is written in Python and JavaScript
- It is written to be used with Nevow, a
`Twisted <http://twistedmatrix.com/>`__-based web framework.
- Similar to Twisted's `Perspective
Broker <http://twistedmatrix.com/projects/core/documentation/howto/pb-intro.html>`__,
Athena employs remote calls.
Athena was written by Twisted and Divmod developers (in addition to
contributing members of the community) in order to bring the outdated
and Nevow-incompatible Woven LivePage technology to Nevow. In addition,
it was an opportunity to improve upon the original design and
incorporate new features to address the growing needs of developers.
Target Applications
-------------------
Good candidates for Athena web applications would include those where
the application needs to respond to user input and/or updates from
servers, such as the following:
- conference software (e.g. whiteboard, shared text, chat, etc.)
- mail clients
- interactive, multi-player games
- social networking tools
- office applications (e.g., spreadsheets, word processors, etc.)
Target Developers
-----------------
Anyone who wants to create interactive, web-based applications is a
potential Nevow/Athena user. It's best to have some background in
writing web applications, and in addition, to know how to use Nevow.
However, we hope that this tutorial will be just as useful for beginners
as experienced developers.
nevow/doc/howto/chattutorial/part00/index.rst 0 → 100644
View file @ 5664f5f3
Toy Echo Application
====================
What is an "Echo Application?"
------------------------------
Our first foray into building an Athena application will be an easy
venture: we want to type something in an input box and have it echoed
back to us on the same page, without having to reload anything. Why?
Well, our eventual goal is to have a working chat server, with all sorts
of technical bells and whistles (persistent storage, authentication,
etc.), but that's a bit heady for right now. Many of the same principles
which we will eventually employ in our chat application exist for a
simple case of sending textual messages between a web browser and a
server. This is the essence of our "Echo" application.
Mental Preparation
------------------
In the :doc:`../intro` and the :doc:`../concepts` pages, we had a
refresher on AJAX and COMET and we learned a little bit about what that
looks like for Athena. But as we sit down to actually write an Athena
application, what do we need to wrap our heads around?
Given the introductory knowledge we have, we know that we will need to
write some JavaScript, some Python, and if our past experience in
developing web applications is any guide, some form of template. This
indeed is the case, but here's something big: we're not working with
pages and page templates; we're working with "elements", or parts of the
DOM tree. We will not be creating page resources; we will be creating
just the parts of a "traditional" page that will be dynamic and
interactive.
Architecture
------------
Now that we've pumped ourselves up and before we start clacking away at
the keyboard, we need to get pointed in the right direction. We need a
plan. Here's what we know:
1. We will have a server that:
- serves dynamic elements in a resource accessible via a URL;
- communicates with a client.
2. We will have a client that:
- communicates with the server;
- updates its DOM tree.
The user experience of this application will be the following:
1. they will type text in an input on a form; and
2. the typed text will be rendered to a different part of the page upon
hitting a submit button.
We will not simply write user input to a ``div`` with JavaScript DOM
manipulation, but will instead pass data like we expect will be
necessary when we write our chat application. After all, it's probably
best to build towards our goal. In order to accomplish this, the
application will do something like the following:
1. JavaScript client code will extract user input and send it to our
server;
2. Python code will receive messages from the client;
3. Python code will send messages to the client; and
4. a template file (or ``stan`` code) will be used for presentation.
Let the Coding Begin
--------------------
In a future installment, we will outline the development process from
the perspective of test-driven development, in order to not only show
how to write unit tests for Athena (Python and JavaScript), but to
encourage good programming practices while working with Athena. For now,
though, we will just dive right in.
Presentation
~~~~~~~~~~~~
Let's start with the easy bit: what our app will look like. Here is the
template for our echo application:
.. literalinclude:: listings/echothing/template.html
:language: html
:linenos:
Things to note:
- This is not a complete HTML document, but is an XHTML template for an
"element".
- The name space declarations in the top ``div`` tag are necessary for
the operation of Athena.
- When we hit the "Send" button, our JavaScript class will call the
``doSay()`` method.
Writing the Client
~~~~~~~~~~~~~~~~~~
Next up is the JavaScript. We need to send our data to the server. In a
full chat application, it would be necessary to send the data to the
server so that we could propagate the message to all connected clients.
In this case, with the simple echo, we're not going to do anything with
the data that gets sent to the server, except send it back, of course.
Our JavaScript will need to do several things:
1. import required modules;
2. inherit ``callRemote`` functionality from the base ``Widget`` class;
3. setup convenience attributes;
4. implement the ``doSay()`` method we put in our template above; and
5. implement a method for updating the DOM with data it receives from
the server:
.. literalinclude:: listings/echothing/js/EchoThing.js
:language: javascript
:linenos:
Points to note:
- Those import statements aren't just pretty: they are necessary! In
Athena, you need to treat those like you treat the import statements
in Python.
- The attributes set in the ``__init__()`` method are for convenience
when we reference them in other methods.
- Note the ``callRemote()`` method in ``doSay()``, As mentioned in the
`Concepts <../concepts.html>`__ section, this is how JavaScript is
communicating with our Python server.
- Another thing about ``doSay``: this is the submit handler. As such,
it needs to return false so that the browser is prevented from doing
a normal form submission.
- ``addText()`` is the method that will be updating the browser DOM
once the server sends the data back.
There's not much to say about the next one. This is what sets up the
relationship between our module name and the actual file itself (so that
the JavaScript can be loaded):
.. literalinclude:: listings/nevow/plugins/echothing_package.py
:language: python
:linenos:
Writing the Server
~~~~~~~~~~~~~~~~~~
Despite what one might think, writing the server may be the easiest
part! If you've created Nevow applications before, then this will look
very familiar. The only method we need is one that will send data back
to the client. Besides importing the necessary modules and creating a
class with some boilerplate, that's about it.
Let's take a look at the code:
.. literalinclude:: listings/echothing/echobox.py
:language: python
:linenos:
As promised, simple as can be. We do make use of a Twisted utility that
simplifies typing the path to our template. Some very important points:
- The ``jsClass`` assignment is what connects this code to your
JavaScript code.
- As discussed in the `Concepts <../concepts.html>`__ section, the
``expose`` decorator is required if our JavaScript is going to be
able to call the ``say()`` method.
Putting it All Together
~~~~~~~~~~~~~~~~~~~~~~~
Now that we've got all the code in front of us, we can trace out exactly
what happens:
1. the user loads the resource in their browser, and the template is
rendered;
2. after typing a message in the input box, the user hits submit;
3. upon hitting submit, the client code ``doSay()`` method is called;
4. ``doSay()`` makes a remote call to the Python server method
``say()``;
5. the Python server receives the data when ``say()`` is called, and
then it passes that data to the client code's ``addText()`` method;
6. with control back in the client code and data fresh from the server,
JavaScript can now update the page's DOM with the new data, and this
is what the ``addText()`` method does;
7. when ``addText()`` finishes, the cycle has completed and the browser
now displays the latest data input by the user.
The Fruits of Our Labor
~~~~~~~~~~~~~~~~~~~~~~~
Now we get to run it! This is a little different than what you may be
used to, if you have written Twisted applications in the past. We are
using the plugin architecture of Twisted and Nevow such that ``twistd``
will publish our element in an HTTP service. To do this, we will use
``twistd``'s ``athena-widget`` command:
::
cd Nevow/doc/howto/chattutorial/part00/listings
twistd -n athena-widget --element=echothing.echobox.EchoElement
If you executed this against the tutorial code on your local machine,
you can now visit `localhost:8080 <http://localhost:8080>`__ and start
echoing to your heart's content.
Summary
-------
As you can see, our echo application is a toy app that doesn't do
anything very useful. However, it has provided us with a basis for
learning how to write working Athena code that lets a browser and server
communicate with each other, both sending and receiving data. As such,
we now have a solid foundation upon which we can build a functional,
useful *and* instructional chat application.
nevow/doc/howto/chattutorial/part00/listings/echothing/echobox.py 0 → 100644
View file @ 5664f5f3
from twisted.python.util import sibpath
from nevow.athena import LiveElement, expose
from nevow.loaders import xmlfile
class EchoElement(LiveElement):
docFactory = xmlfile(sibpath(__file__, 'template.html'))
jsClass = 'EchoThing.EchoWidget'
def say(self, message):
self.callRemote('addText', message)
say = expose(say)
nevow/doc/howto/chattutorial/part00/listings/echothing/js/EchoThing.js 0 → 100644
View file @ 5664f5f3
// import Nevow.Athena
Nevow.Athena.Widget.subclass(EchoThing, 'EchoWidget').methods(
function __init__(self, node) {
EchoThing.EchoWidget.upcall(self, "__init__", node);
self.echoWidget = self.nodeByAttribute('name', 'echoElement');
self.scrollArea = self.nodeByAttribute('name', 'scrollArea');
self.message = self.nodeByAttribute('name', 'message');
},
function doSay(self) {
self.callRemote("say", self.message.value);
self.message.value = "";
return false;
},
function addText(self, text) {
var newNode = document.createElement('div');
newNode.appendChild(document.createTextNode(text));
self.scrollArea.appendChild(newNode);
document.body.scrollTop = document.body.scrollHeight;
});
nevow/doc/howto/chattutorial/part00/listings/echothing/template.html 0 → 100644
View file @ 5664f5f3
<div xmlns:nevow="http://nevow.com/ns/nevow/0.1"
xmlns:athena="http://divmod.org/ns/athena/0.7"
nevow:render="liveElement">
<h2>Echo Element</h2>
<form name="echoElement">
<athena:handler event="onsubmit" handler="doSay" />
<div name="scrollArea">
</div>
<input name="message" /><input type="submit" value="Send" />
</form>
</div>
nevow/doc/howto/chattutorial/part00/listings/nevow/plugins/echothing_package.py 0 → 100644
View file @ 5664f5f3
from twisted.python import util
from nevow import athena
import echothing
chatthingPkg = athena.AutoJSPackage(util.sibpath(echothing.__file__, 'js'))
nevow/doc/howto/chattutorial/part01/index.rst 0 → 100644
View file @ 5664f5f3
Simple Chat and Two-Way Communications
======================================
Architecture
------------
We'll assume that you've read all the preceding sections of this
tutorial and have just finished the "Echo" application example. As such,
we don't need to do any more "mental preparation" and can skip straight
to a description of the architecture.
Fundamentally, this is no different than our echo application: there is
a little more chatter that takes place between the client and server;
there's another object involved (a ``ChatRoom``); and we'll have to run
the server a little differently.
Here are the new features we want to support:
- login form;
- in-memory user storage;
- the ability to send global alerts to all users; and
- the ability for all users to "hear" when another user speaks in the
chat room;
A general rule we can establish about our architecture is that if
something has to happen for everyone, that code needs to appear on the
server side, since it's the server that is keeping track of all users.
If something is going to happen irrespective of other users or if
browser DOM manipulation is required, then we know the client will be
the recipient of the code.
As such, in the features above, the login form will be client code. The
user storage, global alerts, and "hearing" will be implemented in server
code for the data; updating the DOM with that data will be implemented
in client code.
The user experience of this application will be the following:
1. they will be presented with a login box (no password, only username);
2. upon logging in, a message will be sent to all logged in users that
this person has joined, they will see a message at the bottom of the
chat that states their login name, and the login form will be
replaced with a chat area and a text input field;
3. they will type text in the input field; and
4. the typed text will appear in the browser of every person who is
logged in.
Building upon our previous example, our application will do the
following:
1. JavaScript client code will extract user input and send it to our
server;
2. Python code will receive messages from the client;
3. Python code will process these messages;
4. Python code will send messages to the all clients; and
5. a template file (or ``stan`` code) will be used for presentation.
More Coding
-----------
Presentation
~~~~~~~~~~~~
The template is very similar as it was in the previous example, with the
differences being a new login box, a "logged in as" area, and some name
changes:
.. literalinclude:: listings/chatthing/template.html
:language: html
:linenos:
We've now got two JavaScript methods that need to be defined:
``doSetUsername()`` and ``doSay()``. We can also infer from this
template that elements will be hidden and shown after login (note the
presence of ``style="display:none"`` in two places). With these
observations in hand, let's proceed to the JavaScript code.
Writing the Client
~~~~~~~~~~~~~~~~~~
Referring back to our thoughts in the "Architecture" section above, we
can establish that the JavaScript code needs the following:
- have the same basic boilerplate as in the "echo" example (imports,
inheritance, attribute-setting in the constructor);
- implement the ``doSetUsername()`` and ``doSay()`` methods;
- create a method that will send a message to all users; and
- create a method that will let everyone know when someone says
something. Let's see how this is done:
.. literalinclude:: listings/chatthing/js/ChatThing.js
:language: javascript
:linenos:
There is a little abstraction here:
- we need a general message-sending method (``displayMessage()``) for
any message that gets sent to all users;
- for user chat messages, we need something that will prepend the
username so that everyone knows who said what
(``displayUserMessage()``), and once this method does its thing, it
passes the adjusted message on to ``displayMessage()``.
Other than that, this is very straight-forward code; it's pretty much
the same as the "Echo" tutorial. The ``display*()`` methods are only
responsible for updating the UI, just as we would expect.
We also need the same glue that we demonstrated in the "Echo" example:
.. literalinclude:: listings/nevow/plugins/chatthing_package.py
:language: python
:linenos:
Writing the Server
~~~~~~~~~~~~~~~~~~
The server code is a bit more complicated. We anticipated this above in
the "Architecture" section where we noted that the Python code needs to
receive, process and send messages.
.. literalinclude:: listings/chatthing/chatterbox.py
:language: python
:linenos:
There is something in our "Chat" code that is not at all present in the
"Echo" application: the ``ChatRoom`` object. We need this object for the
following functionality:
- a means of instantiating new ``ChatterElement`` clients;
- a "singleton" instance for keeping track of all ``ChatterElement``
clients;
- a means sending messages to all clients;
Let's look at the second two reasons first. In our "Chat" application, a
new ``ChatterElement`` is created whenever a user connects, so we will
have potentially many of these instances. In order for our chat server
to function as designed, it will need a way to communicate with each of
these. If we create an object that can keep the ``ChatterElement``\ es
in a list, then it will be able to iterate that list and call methods
that, in turn, make remote calls to the JavaScript.
Because we need the chat room to be a singleton object, it can only be
instantiated once. But we need many instantiations of ``ChatterElement``
-- one for each connection, in fact. So what do we do? Well, in this
case, we make one of the methods of ``ChatRoom`` a factory for
instantiating a ``ChatterElement``. Before we return the instance,
though, we append it to the list of instances that the ``ChatRoom`` is
keeping track of.
Putting it All Together
~~~~~~~~~~~~~~~~~~~~~~~
Now that we've got all the code in front of us, we can trace out exactly
what happens:
1. the user loads the resource in their browser, and the template is
rendered;
2. after typing a message in the input box, the user hits submit;
3. JavaScript client code calls to the server with the text the user
submitted;
4. the server gets the message and shares it with all the connected
``ChatterElement``\ s;
5. each ``ChatterElement`` hears this message and passes it back to the
JavaScript client;
6. the client prepends the username to the message and then updates the
display with the complete message.
Keep in mind that ``ChatterElement`` entails several duties: it
establishes a relationship with a room object, it "registers" a user
(there's a one-to-one mapping between users and ``ChatterElement``), it
sends messages to the browser, and it receives messages from the chat
room. Being a ``LiveElement`` subclass, ``ChatterElement`` is also
responsible for the view (via the document factory).
Running with ``twistd``
~~~~~~~~~~~~~~~~~~~~~~~
One last bit of code that may seem odd is the ``chat`` variable we
define right after the ``ChatRoom`` class. What is this? This is how we
make all this cleverness work as a twisted plugin.
If you recall, in our "Echo" application, we ran the code with the
following command:
::
twistd -n athena-widget --element=echothing.echobox.EchoElement
The value we pass as the ``--element`` argument is the dotted name of
the ``LiveElement`` object of which our "web page" is primarily
comprised: the ``EchoElement`` object. In our "Chat" application, we
have more moving parts: not only do we have the ``ChatterElement``
object, but we have the ``ChatRoom`` object which is responsible for
keeping track of many ``ChatterElement``\ es. By defining the ``chat``
variable, we are accomplishing the following all at once:
- providing a variable that can be accessed as a dotted name and thus
used when starting the server (``chatthing.chatterbox.chat``);
- creating a singleton of ``ChatRoom`` (via the "magic" of Python
module-level instantiations);
- making use of a factory, that when called, will both return a new
``ChatterElement`` instance *and* add itself to the ``ChatRoom``.
Running this version of our code is a little bit different than the
"Echo" version. This is because of the ``ChatRoom`` code we discussed
above. As such, we pass a factory as our element, like so:
::
cd Nevow/doc/howto/chattutorial/part01/listings
twistd -n athena-widget --element=chatthing.chatterbox.chat
If you executed this against the tutorial code on your local machine,
you can now visit http://localhost:8080/ and start chatting to your
heart's content.
Summary
-------
Unlike our echo application, the chat application has some real
functionality and does some useful stuff: supporting user chats via
browser/server two-way communications. It should be evident now how the
echo application provided a basic conceptual and (partially) functional
foundation upon which our chat work could be based.
nevow/doc/howto/chattutorial/part01/listings/chatthing/chatterbox.py 0 → 100644
View file @ 5664f5f3
from twisted.python.util import sibpath
from nevow.loaders import xmlfile
from nevow.athena import LiveElement, expose
class ChatRoom(object):
def __init__(self):
self.chatters = []
def wall(self, message):
for chatter in self.chatters:
chatter.wall(message)
def tellEverybody(self, who, what):
for chatter in self.chatters:
chatter.hear(who.username, what)
def makeChatter(self):
elem = ChatterElement(self)
self.chatters.append(elem)
return elem
# element to be run with twistd
chat = ChatRoom().makeChatter
class ChatterElement(LiveElement):
docFactory = xmlfile(sibpath(__file__, 'template.html'))
jsClass = 'ChatThing.ChatterWidget'
def __init__(self, room):
self.room = room
def setUsername(self, username):
self.username = username
message = ' * user '+username+' has joined the room'
self.room.wall(message)
setUsername = expose(setUsername)
def say(self, message):
self.room.tellEverybody(self, message)
say = expose(say)
def wall(self, message):
self.callRemote('displayMessage', message)
def hear(self, username, what):
self.callRemote('displayUserMessage', username, what)
nevow/doc/howto/chattutorial/part01/listings/chatthing/js/ChatThing.js 0 → 100644
View file @ 5664f5f3
// import Nevow.Athena
Nevow.Athena.Widget.subclass(ChatThing, 'ChatterWidget').methods(
function __init__(self, node) {
ChatThing.ChatterWidget.upcall(self, "__init__", node);
self.chooseBox = self.nodeByAttribute('name', 'chooseBox');
self.scrollArea = self.nodeByAttribute('name', 'scrollArea');
self.sendLine = self.nodeByAttribute('name', 'sendLine');
self.usernameField = self.nodeByAttribute('name', 'username');
self.userMessage = self.nodeByAttribute('name', 'userMessage');
self.loggedInAs = self.nodeByAttribute('name', 'loggedInAs');
},
function doSetUsername(self) {
var username = self.usernameField.value;
self.callRemote("setUsername", username).addCallback(
function (result) {
self.chooseBox.style.display = "none";
self.sendLine.style.display = "block";
self.loggedInAs.appendChild(document.createTextNode(username));
self.loggedInAs.style.display = "block";
});
return false;
},
function doSay(self) {
self.callRemote("say", self.userMessage.value);
self.nodeByAttribute('name', 'userMessage').value = "";
return false;
},
function displayMessage(self, message) {
var newNode = document.createElement('div');
newNode.appendChild(document.createTextNode(message));
self.scrollArea.appendChild(newNode);
document.body.scrollTop = document.body.scrollHeight;
},
function displayUserMessage(self, avatarName, text) {
var msg = avatarName+': '+text;
self.displayMessage(msg);
});
nevow/doc/howto/chattutorial/part01/listings/chatthing/template.html 0 → 100644
View file @ 5664f5f3
<div xmlns:nevow="http://nevow.com/ns/nevow/0.1"
xmlns:athena="http://divmod.org/ns/athena/0.7"
nevow:render="liveElement">
<h2>Chatter Element</h2>
<form name="chatBox">
<athena:handler event="onsubmit" handler="doSay" />
<div name="scrollArea"
style="border: 1px solid gray; padding: 5; margin: 5">
</div>
<div name="sendLine" style="display: none">
<input name="userMessage" /><input type="submit" value="Send" />
</div>
</form>
<form name="chooseBox">
<athena:handler event="onsubmit" handler="doSetUsername" />
Choose your username: <input name="username" />
<input type="submit" name="GO" value="Enter"/>
</form>
<div name="loggedInAs" style="display:none"><span>Logged in as </span></div>
</div>
nevow/doc/howto/chattutorial/part01/listings/nevow/plugins/chatthing_package.py 0 → 100644
View file @ 5664f5f3
from twisted.python import util
from nevow import athena
import chatthing
chatthingPkg = athena.AutoJSPackage(util.sibpath(chatthing.__file__, 'js'))
nevow/doc/howto/deployment.rst 0 → 100644
View file @ 5664f5f3
Deployment
==========
Nevow includes two major phases for deciding what HTML to render.
:doc:`traversal` is the procedure by which a URL
is mapped to a Python object which will perform the HTML generation.
:ref:`glossary-page_rendering` is the process by which data objects
are combined with an HTML template to produce the final output.
Before any of this can take place, however, we must have an environment
in which our Python code can run in response to an HTTP request, and
HTML can be returned to the browser for rendering. This is called the
:ref:`glossary-deployment_environment`.
There are various deployment options for Nevow page code:
- CGI: Simple deployment in almost any HTTP server
- WSGI: A more complete and flexible way for deploying on many HTTP
servers
- Twisted.Web: A standalone application server process which includes a
built-in HTTP server
- Zomne: A small CGI which hands off HTTP requests to a long-running
application server process, similar to FastCGI or SCGI
CGI
---
You can deploy Nevow on any webserver which uses the Common Gateway
Interface. Using this method, your code is responsible for properly
formatting and outputting the HTTP response headers, and Nevow is used
only to generate the HTML body of your page. Here is the simplest
possible CGI:
.. code-block:: python
#!/usr/bin/env python
print "Content-type: text/plain\r\n\r\n",
from nevow import rend, loaders
class HelloWorld(rend.Page):
docFactory = loaders.stan("Hello, world!")
print HelloWorld().renderSynchronously()
With this simple CGI you can use the Nevow template loaders and standard
nevow template interpolation techniques in your CGIs. However, you do
not get any :doc:`traversal` features, and you
have to generate HTTP headers yourself. WSGI is a slightly higher-level
deployment option which does not suffer these problems.
Twisted.Web
-----------
A convenient and powerful way to deploy Nevow applications is inside a process
running the twisted.web HTTP server. With Python, Twisted, and Nevow installed,
you have all you need to run a Web Application, with no other dependencies or
external HTTP servers such as Apache required. Running your Nevow applications
under twisted.web also gives you access to some of the more advanced "Live"
features of Nevow, such as ``nevow.athena``. Currently, these modules require
more control over the HTTP socket than CGI can provide. (This may change in
the future.)
Deploying a Nevow application under twisted.web requires a little more
boilerplate, but can be considerably easier to set up than other
deployment options because there are no external dependencies. Note that
normally you should declare your Page classes in modules external to the
twisted configuration file, but everything is included in one file here
for brevity. Here is the minimal configuration file required to use
Nevow with twisted.web:
.. code-block:: python
from nevow import rend, loaders, appserver
class HelloWorld(rend.Page):
docFactory = loaders.stan("Hello, world!")
from twisted.application import service, internet
application = service.Application("hello-world")
internet.TCPServer(8080, appserver.NevowSite(HelloWorld())).setServiceParent(application)
Save this file as "helloworld.tac" and start the server using the
command:
::
twistd -noy helloworld.tac
Then visit your twisted.web server by viewing the url
"http://localhost:8080/" in your browser. See the twistd man page for
more information about what twistd is capable of, including daemonizing
the HTTP server.
Conclusion
----------
Nevow may be deployed in a number of environments, from the most
restrictive to the most permissive. Writing a CGI can be an easy way to
try out the Nevow templating mechanism, but can be slow. A long-running
application server process can be a good way to get good performance as
well as additional features such as in-memory server-side sessions,
advanced automatic form handling with formless, and live page updating
features such as nevow.athena.
Which deployment option you choose will depend on the amount of control
you have over your deployment environment, and what advanced features
your application will require.
nevow/doc/howto/gettingstarted.rst 0 → 100644
View file @ 5664f5f3
Getting Started
===============
Warning: This document has only just been started. It's not going to get
you very far right now.
Nevow is a reasonably large library and can be quite daunting at first.
This document's aim is to guide the first time user in building a Nevow
application.
Our First Application
---------------------
Let's dive straight in, here's the code for our first (very, very
simple) application. Create the following module, ``helloworld.py``:
.. literalinclude:: listings/gettingstarted/helloworld.py
:language: python
:linenos:
It looks quite simple but let's walk through it anyway.
First, we import two Nevow modules. ``nevow.loaders`` contains template
loaders of which the two most useful are ``xmlfile`` and ``stan``.
``xmlfile`` can load any well-formed XML (i.e. XHTML) file; ``stan``
loads a stan tree (more on these later). The other module,
``nevow.rend``, contains all Nevow's standard renders, many of which
we'll meet in this document.
We then define the ``HelloWorld`` class that subclasses ``rend.Page``,
Nevow's main resource class. ``HelloWorld`` has two class attributes.
``addSlash`` tells ``rend.Page`` to redirect to a version of the request
URL that ends in a ``/`` if necessary. You generally want to set this to
``True`` for the root resource. ``docFactory`` tells the page instance
where to get the template from. In this case we're providing a loader
that parses an HTML file (not shown) from disk.
Hmm, ok I hear you say but how do I see it. Well, Twisted provides a
good web server which we can use. Twisted also includes a clever little
application for starting Twisted applications. Here's the ``helloworld.tac``
file, a Twisted Application Configuration:
.. literalinclude:: listings/gettingstarted/helloworld.tac
:language: python
:linenos:
Give it a go, run the following and connect to http://localhost:8080/ to
see your application:
::
twistd -ny helloworld.tac
You'll probably notice that you get log output on the console. This is
just one of the good things that twistd does. It can also daemonize the
application, shed privileges if run as root, etc.
TAC files are covered in more detail in the Twisted documentation but
let's quickly explain what all this does anyway.
When ``twistd`` starts up it loads the ``.tac`` file (it's just Python)
and looks for the attribute called ``application``. When ``twistd`` is
all ready to go it starts the ``application``.
The application is not much use unless it actually does something so the
next thing we do is create a ``NevowSite`` instance, ``site``, and pass
it a root resource, a ``HelloWorld`` instance. Finally, we create a TCP
server that makes the site available on port 8080 and bind the server to
the application to ensure the server is started when the application is
started.
nevow/doc/howto/glossary.rst 0 → 100644
View file @ 5664f5f3
Glossary
========
Object Traversal
----------------
The process by which a Python object is located to render HTML for a
given HTTP URL. For example, given the URL http://example.com/foo/bar,
Object Traversal will begin at the "Root Resource" object by asking it
for an object which is capable of rendering the page at ('foo', 'bar').
The "Root Resource" returns an object and a list of unhandled path
segments, and the traversal continues across this new Resource object
until all path segments have been consumed.
.. _glossary-page_rendering:
Page Rendering
--------------
The process by which a Python object, usually a rend.Page subclass,
turns itself into HTML. Page Rendering involves locating some page data,
loading a template document, and applying the template to the data, in
the process generating HTML.
.. _glossary-deployment_environment:
Deployment Environment
----------------------
The environment in which a Nevow application is deployed. Generally
involves an HTTP server which is configured to route certain (or all)
HTTP requests through the Nevow Object Traversal and Page Rendering
process. Deployment environments include CGI, WSGI, and twisted.web.
DOM
---
Document Object Model. A tree of objects which represent the structure
of an XHTML document in memory. Nevow uses a nonstandard DOM named
"stan", which is made up of simple Python lists, dicts, strings, and
nevow.stan.Tag instances.
Flattener
---------
A Python function which knows how to translate from a rich type to a
string containing HTML. For example, the integer flattener calls str()
on the integer. The string flattener escapes characters which are unsafe
in HTML, such as <, >, and &.
Tag
---
A class, defined at nevow.stan.Tag, which holds information about a
single HTML tag in a DOM. Tag instances have three attributes: tagName,
attributes, and children. tagName is a string indicating the tag name.
attributes is a dict indicating the HTML attributes of that node.
children is a list indicating the child nodes of that node.
Tag Specials
------------
A Tag attribute which is "special" to nevow. Tag specials include data,
render, pattern, slot, and macro. Tag Specials will never be output as
HTML attributes of tags, but will be used by the internal Nevow
rendering process to influence how the Tag is rendered.
nevow/doc/howto/intro.rst 0 → 100644
View file @ 5664f5f3
============
Introduction
============
Summary
-------
Nevow is a next-generation web application templating system, based on
the ideas developed in the Twisted Woven package. Its main focus is on
separating the HTML template from both the business logic and the
display logic, while allowing the programmer to write pure Python code
as much as possible. It separates your code into 'data' and 'render'
functions, a simplified implementation of traditional MVC. It has
various parts which can be used individually or as a whole, integrated
web solution:
- XHTML templates: contain no programming logic, only nodes tagged with
nevow attributes
- data/render methods: simplified MVC
- stan: An s-expression-like syntax for expressing xml in pure python
- formless: For describing the types of objects which may be passed to
methods of your classes, validating and coercing string input from
either web or command-line sources, and calling your methods
automatically once validation passes
- formless.webform: For rendering web forms based on formless type
descriptions, accepting form posts and passing them to formless
validators, and rendering error forms in the event validation fails
Disk based templates
--------------------
Nevow includes the ability to load templates off disk. These templates
may have processing directives which cause the execution of python
methods at render time. The attribute technique was inspired by the
attributes used by ZPT. However, no actual code may be embedded in the
HTML template:
.. code-block:: html
<html xmlns:nevow="http://nevow.com/ns/nevow/0.1">
<head>
<title>Greetings!</title>
</head>
<body>
<h1 style="font-size: large">Now I will greet you:</h1>
<span nevow:render="greet" />
</body>
</html>
This template can then be loaded and rendered like so:
.. code-block:: python
class Greeter(rend.Page):
docFactory = loaders.xmlfile("Greeting.html")
def render_greet(self, context, data):
return random.choice(["Hello", "Greetings", "Hi"]), " ", data
Greeter("My name is").renderString()
data/render methods
-------------------
To allow clean isolation between code which fetches data from a data
source and code which renders the data into HTML, nevow allows you to
write both 'data' methods and 'render' methods. These concepts are
inspired by MVC, but simpler, since the framework can handle most of the
controller aspect. An example:
.. code-block:: html
<html xmlns:nevow="http://nevow.com/ns/nevow/0.1">
<body>
<span nevow:data="name" nevow:render="colorful" />
<span nevow:data="fun" nevow:render="colorful" />
</body>
</html>
This template can be loaded and rendered using a class such as this:
.. code-block:: python
class Colorful(rend.Page):
docFactory = loaders.xmlfile("Colorful.html")
def render_colorful(self, context, data):
color = random.choice(['red', 'green', 'blue'])
return context.tag(style="color: %s" % color)
def data_name(self, context, data):
return "Your name here"
def data_fun(self, context, data):
return "Are we having fun yet?"
Stan
----
One of the most powerful things about nevow is stan, an
s-expression-like syntax for producing XML fragments in pure Python
syntax. Stan is not required for using nevow, but it is both a simple
and powerful way to both lay out one's XHTML templates and express one's
display logic. A brief example will illustrate its utility:
.. code-block:: python
import random
from nevow import rend, tags
class Greeter(rend.Page):
def greet(self, context, data):
return random.choice(["Hello", "Greetings", "Hi"]), " ", data
docFactory = loaders.stan(
tags.html[
tags.head[ tags.title[ "Greetings!" ]],
tags.body[
tags.h1(style="font-size: large")[ "Now I will greet you:" ],
greet
]
])
When the Greeter class is constructed, it is passed a Python object
which will be used as that page's data:
.. code-block:: python
Greeter("Your name here").renderString()
Formless
--------
Python is dynamically typed, which means it has no built-in controls for
enforcing the types of objects which are passed to one's methods. This
is great for programmers, but not necessarily great if you are going to
be passing user-entered input to those methods. Formless is a simple way
to describe the types of objects that can be passed to one's methods, as
well as coerce from string input to those types. Other code can then
accept user input from a command line or from a web form, validate the
input against the types described using formless, and call the method
once validation has passed. A simple example:
.. code-block:: python
from zope.interface import implements
from formless.annotate import TypedInterface, Integer, String
class ISimpleMethod(TypedInterface):
def simple(self,
name=String(description="Your name."),
age=Integer(description="Your age.")):
"""
Simple
Please enter your name and age.
"""
class Implementation(object):
implements(ISimpleMethod)
def simple(self, name, age):
print "Hello, %s, who is %s" % (name, age)
Webform
-------
Webform is a nevow module which will automatically render web forms and
accept form posts based on types described using the classes in
formless. Used in conjunction with the twisted.web HTTP server, the
process is almost automatic:
.. code-block:: python
from nevow import rend, tags
from formless import webform
class WebForm(rend.Page):
document = rend.stan(
tags.html[
tags.body[
h1["Here is the form:"],
webform.renderForms('original')
]
])
resource = WebForm(Implementation())
Exposing this resource instance to the web using twisted.web and
visiting it will cause a form with two input boxes to be rendered.
Posting the form will cause form validation to occur. Upon error, the
user will be returned to the original page, with the form annotated with
error messages. Upon success, the "simple" method of the Implementation
instance will be called and passed a string and an integer.
LivePage
--------
LivePage was a Woven technology which allowed programmers to receive
server- side notification of client-side JavaScript events, and to send
JavaScript to the client in response to a server-side event. New for
Nevow 0.3, LivePage has been updated to support Mozilla, Firefox, IE6
Win, and Safari. Using LivePage is very easy:
.. code-block:: python
from nevow.liveevil import handler
def greeter(client, nodeName):
client.alert("Greetings. You clicked the %s node." % nodeName)
# Any string arguments after the event handler function will be evaluated
# as JavaScript in the context of the web browser and results passed to the
# Python event handler
handler = handler(greeter, 'node.name')
class Live(rend.Page):
docFactory = loaders.stan(
tags.html[
tags.body[
ol[
li(onclick=handler, name="one")["One"]
li(onclick=handler, name="two")["Two"]
li(onclick=handler, name="three")["Three"]
]
]
])
More Information
----------------
The `Nevow website <https://divmod.org/trac/wiki/DivmodNevow>`__ has more
information. Starting with 0.3, it contains a simple WSGI implementation
and can also be used to render CGIs. However, the recommended mode of
operation is using the `Twisted
web <http://twistedmatrix.com/trac/wiki/TwistedWeb>`__ server. Nevow is
an active project, and many new bugfixes and features are committed to
the Nevow Git repository. Information about Nevow commits is available
by subscribing to the `Divmod
commits <http://divmod.net/users/mailman.twistd/listinfo/divmod-commits>`__
mailing list. The Nevow Git repository can be checked out using:
::
git clone git://github.com/twisted/nevow
Discussion of Nevow occurs on the `twisted.web mailing
list <http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web>`__.
The Nevow developers are also often available for real-time help on the
`#twisted.web channel <irc://irc.freenode.net/#twisted.web>`__ on
irc.freenode.net.
nevow/doc/howto/listings/gettingstarted/helloworld.py 0 → 100644
View file @ 5664f5f3
from nevow import loaders, rend
class HelloWorld(rend.Page):
addSlash = True
docFactory = loaders.xmlfile('helloworld.html')
nevow/doc/howto/listings/gettingstarted/helloworld.tac 0 → 100644
View file @ 5664f5f3
from twisted.application import internet
from twisted.application import service
from nevow import appserver
import helloworld
application = service.Application('helloworld')
site = appserver.NevowSite(helloworld.HelloWorld())
webServer = internet.TCPServer(8080, site)
webServer.setServiceParent(application)
nevow/doc/howto/publishing.rst 0 → 100644
View file @ 5664f5f3
Object Publishing
=================
In :doc:`traversal`, we learned about the
``nevow.inevow.IResource.renderHTTP`` method, which is the most basic
way to send HTML to a browser when using Nevow. However, it is not very
convenient (or clean) to generate HTML tags by concatenating strings in
Python code. In the :doc:`deployment` documentation, we
saw that it was possible to render a *Hello World* page using a
``nevow.rend.Page`` subclass and providing a ``docFactory``: