Translation from Wiki to HTML "on-the-fly" (to display) are fine.
Don't prebuild and store the HTML because you might want to change the
presentation of a wiki tag later.
You can use the Title field to get the revisions and its sequence,
if you order by the primary key, since it increments. (thus
eliminating the "history" field). Also, change the "auto_now"
parameter to "auto_now_add".
All revisions of the "Example Title" page:
page_list = pages.get_list(title__exact = "Example Page", order_by = [-id])
Current page:
current_page = page_list[0]
Or:
current_page = pages.get_list(title__exact = "Example Page", order_by
= [-id], limit = 1)
But this design should really only be used for small, low traffic
and low edited, wikis.
On 3/31/06, shredwheat <[EMAIL PROTECTED]> wrote:
>
> I want a pages of my site to be editable by signed in members. This
> seems simple enough, but I'm not sure of the best strategy. This does
> not need to be a full on wiki style system, since the number of pages
> will be fixed and only about 10 or so.
>
> The main goals I am after:
> - simple text markup like ReST
> - full revision history
>
> It looks easy enough to just use the rest middleware on the pages I
> need. This is not going to be a high-demand environment, so is html
> translation on the fly good enough? Perhaps I should tap into the
> internal django caching for these. The other option is to prebuild the
> html pages when new commits are made to the text.
>
> It's the revision history that has me most stumped. The changes will
> not likely be high. It wouldn't be hard for each change to just be a
> new row in my Pages table? Each one could then have a reference to the
> previous revision. I'm not too worried about concurrent edits and
> locking, but if I can get that for free I'd gladly roll it in.
>
> Also, I'm unsure of the caveats of using large Text fields in the
> database. These are not going to be large, in fact I could probably
> limit each page to a few kilobyes. But it this going to create potholes
> and cruft in the database?
>
> Am I headed for troubles with a model like this? Any smart changes for
> this?
>
> class Page(meta.Model):
> title = meta.CharField(maxlength=100)
> body = meta.TextField()
> pubdate = meta.DateField(auto_now=True)
> author = meta.ForeignKey(User)
> history = meta.OneToOneField('self', nil=True)
>
> Is it possible to do a OneToOne with 'self'? I don't plan to support
> "forking" which would make ForeignKey more appropriate for the history
> field I guess.
>
>
> >
>
--
Julio Nobrega - http://www.inerciasensorial.com.br
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
