Howdy!
I'm currently working away figuring out some of the scarier stuff
related to my CMS and would like some input and/or comment bashing from
the rest of you. ;^)
So far my design is very application-specific, but I hope to split out
the bare-bones for re-use later. I have a directory structure, like
so: (where topfloor is the package name)
topfloor/
templates/
master.kid
static/...
objects/
Folder/
model.py
controller.py
templates/
listing.kid
edit.kid
Page/
model.py
controller.py
templates/
view.kid
edit.kid
controllers.py
model.py
In my master model, I define an Atom, the base SQLObject for all other
content objects. An Atom defines a name, title, author, etc. (Right
now-) I also define each of the content models in the master model file
- to be moved into the model files for each object later - which
inherit from the Atom base class.
A simple controller for the Page object is thus:
> class Page:
> id = None
> model = None
>
> def __init__(self, id, model):
> self.id = id
> self.model = model
>
> @turbogears.expose()
> def index(self):
> return self.view()
>
> @turbogears.expose(html="topfloor.objects.Page.templates.view")
> def view(self):
> return dict(root=self.model.Atom.get(1),
> page=self.model.Page.get(self.id))
I do not simply pass the Page SQLObject to the class as the data may
change, as well as there are threading concerns. (Good caching will
come in handy here.)
I have a recursive descent search attach the Atom nodes (Folders,
Pages, etc.) to the Root CherryPy node down, being careful not to
overwrite existing methods or properties, during application startup.
I didn't want to have to re-write path lookup functionality which
already exists in CherryPy. Also, I wanted custom applications to be
able to be written without fear of being overwritten by CMS content.
This attaching code works great, I have other problems, though:
1. Can I make the @turbogears.expose() template path relative to the
current directory, or otherwise detach it from my application root?
E.g. the above would turn into "templates.view" which is much nicer.
2. How does the Widget system collect a list of widgets? A similar
feature would be very useful here to collect the base object types
and/or automatically make them available directly from the objects
package.
3. Not directly CMS related, I can't seem to get Kid to parse XML()
results. For example, I have a Page with lots of HTML on it, and I
need that HTML to be parsed by Kid and added to the middle of the XML
stream. *sigh*
4. Kid is having issue with my extending the master template - is there
any way I can have my controllers implicitly do this (i.e. leave it out
of the templates for the objects)?
I'll probably come up with other issues during the day as I implement
this - I'll keep my progress posted. I'll also be uploading a snapshot
of the code to our server soon for y'all to gander at.
Have a great day,
Matthew Bevan
