330
330
These repositories are served by Apache using ``mod_dav_svn`` allowing access
331
331
over Subversion's WebDAV HTTP or HTTPS backends. Users are authenticated using
332
332
a randomly generated key which is stored in the database and is made available
333
to each user inside their jail (``svn_pass`` property inside
333
to each user inside their Jail (``svn_pass`` property inside
334
334
:file:`/home/.ivle.conf`). This key is automatically provided when doing
335
Subversion actions, but can be manually entered when accessing a user's
335
Subversion actions, but can be manually entered when accessing a users
336
336
repository from an external Subversion client such as with :samp:`svn checkout
337
337
{svn_addr}/users/{USERNAME}/ workspace`.
339
Repository permissions for ``AuthzSVNAccessFile`` are automatically generated
340
and placed in the file specified by the ``paths/svn/conf`` config option
341
(usually ``/var/lib/ivle/svn/svn.conf``) for user repositories and the
342
``paths/svn/group_conf`` option for group repositories (usually
343
``/var/lib/ivle/svn/svn-group.conf``). User authentication keys for
344
``AuthUserFile`` are stored in the file specified by ``paths/svn/auth_ivle``,
345
usually ``/var/lib/ivle/svn/ivle.auth``. These will be regenerated each time
346
user or group repository settings change.
339
Repository permissions for ``AuthzSVNAccessFILE`` are automatically generated
340
and placed in the file located at ``[paths] [[svn]] conf`` for user
341
repositories and ``[paths] [[svn]] group_conf`` for group repositories. User
342
authentication keys for ``AuthUserFile`` are stored in the file located at
343
``[path] [[svn]] auth_ivle``. These will be regenerated each time user or
344
group repository settings change.
360
URLs are resolved with a small IVLE-specific object publishing framework --
361
that is, resolution is implemented as traversal through an object graph. The
362
framework lives in :mod:`ivle.webapp.publisher`, and has an extensive test
365
This object graph is constructed by the dispatcher. Any plugin class deriving
366
from ViewPlugin will be searched for ``forward_routes``, ``reverse_routes``
367
and ``views`` sequences. Everything is class-based -- an object's routes
368
and views are determined by its class.
370
Forward routes handle resolution of URLs to objects. Given a source object
371
and some path segments, the route must calculate the next object.
372
A forward route is a tuple of ``(source class, intermediate path segments,
373
function, number of subsequent path segments to consume)``, or simply a
374
reference to a decorated function (see :mod:`ivle.webapp.admin.publishing`
375
for decoration examples). The function must return the next object in the
378
A reverse route handles URL generation for an object. Given just an object,
379
it must return a tuple of ``(previous object, intermediate path segments)``.
380
This creates a chain of objects and path segments until the root is reached.
381
Due to IVLE's lack of a utility framework, reverse routes at the root of the
382
URL space need to refer to the root object with the magical
383
:mod:`ivle.webapp.publisher.ROOT`.
385
Views are registered with a tuple of ``(source class, intermediate path segments,
388
In all of the above, "intermediate path segments" can either be a single
389
segment string, or a sequence of multiple strings representing multiple
393
While many applications prefer a pattern matching mechanism, this did not
394
work out well for IVLE. Our deep URL structure and multitude of nested
395
objects with lots of views meant that match patterns had to be repeated
396
tediously, and views required many lines of code to turn a match into a
397
context object. It also made URL generation very difficult.
399
The simple object publishing framework allows views to be registered with
400
just one line of code, getting their context object for free. URL
401
generation now comes at a cost of approximately one line of code per class,
402
and breadcrumbs are easy too. The reduced code duplication also improves
353
.. TODO: Not yet merged
added
removed
doc/dev/architecture.rst
