|
|
Log message
Lots of stuff.
Started out as effort to add support for adding comments
to pages via the web interface. That's done and required
many changes:
* editor:type_add is now fleshed out
** it will handle
string or dict request content and associate it
with another page if there is a 'to' element [1]
** if it is able to add the content, it will throw
an HTTP303 exception, which causes a 303 out to
the named page. A 303 requires a GET, which is
what we want here.
* use wsgiorg.routing_args throughout instead
of selector.vars
* When adding new content, if there is no content
when attempting to store, throw InvalidContent
up the stack
* when we get page_by_name, send the id [2]
* when the page of name X doesn't exist, return
an incipient page giving hints of editing
thrills to come [3]
* when displaying a comment underneath a page
entry, display a list of links to comment
associates for that comment, effectively doing
a sort of threading
* add get_request_content to simper.py. This
will return a dict of parsed html form input,
or otherwise a string-ish thing
* in _render only split the template after we
run the method, this allows methods that
won't use templates and just throw redirect
exceptions to use the render code (which
has exception handing)
* add more exception handling to _render
Where this leaves this is that:
* we need to consider ORM
* we need to start thinking about how to support
managing migration of associates when making
a revision
* tags are a pretty easy next step (named
associates without content) except that
content is expected at the moment...
* because comments have names (for now) that
means that it is possible for comments to clobber
themselves and each other. maybe they shouldn't
have names? or maybe more complicated authoring
is required?
* it might be that blog content is not editable
from the browser, which makes things a bit more
"safe"
* purpling will want to come eventually, should
be able to config in magic into the creole parser
that says, yes do purple, no don't, etc
* and c
[1] This requirement for 'to' presents a problem
for when we are posting into /content/comments
and not using form fields. We probably want
/content/name/{name:slug}/comments as a
collection. In fact we certainly do (in ical now)
[2] pointing out that in the end, we probably want
to ORM this thing up
[3] In non-user forms we will want 404 instead of
incipient page. How to do content neg when the
content-type is the same?
|
