The hard problem of detecting whether a user is logged in is simply
sidestepped by assuming that any user that sends the `sessionid` cookie
is logged in. This is true as long as you don't save session variables
on anonymous users (i.e. if you don't spy on them ;)
"registry". Client projects register their models and views during import
time with a decorator. The cms views use the registered classes to generate
pages and forms.
Furthermore, the example application now combines the app and the project in
one, inspired by this line in the Django documentation:
There’s no restriction that a project package can’t also be considered
an application and have models, etc.
you to define everything related to it in the file 'cms.py'. No more
inherited proxy models and no more migrations every time you add/remove a
section type! In fact, the dependency on django-polymorphic has completely
been removed!
The example project has been updated and should get you started.
Documentation will be coming soon!
arrive at a simple, senseful and elegant solution that costs only 3 lines to
implement.
I know I should be happy about that, but it really makes me feel like a
total dumbass.
formsets, automatically generated from a reusable app foreign key relations
to their section model. Georgeous!
However, the client side javascript is, even after a complete refactoring,
still an utter mess. After the template generates the HTML tree it's a chore
to use javascript to show, hide and duplicate nodes based on user
interaction.
Maybe I should look into client-side templating?
Despite the name, the idea is to allow reusable apps to add any kind of
formset to the edit page. The first test case is to allow madebyjane to
upload multiple images to a section.
Work in progress.
Whe needs CRUD? If a page exists, you edit it. If it doesn't, the same form
creates it. No more sections on a page? It gets automatically deleted. The
only thing the user has to remember is: nothing. Brilliant, right?
Jaap Joris Vens