Sphene Community Tools

Community

Copyright © 2007-2018 by Herbert Poul

You are not logged in.
Login
Register

Change Language:



AddThis Social Bookmark Button

A Django site.

Powered by Sphene Community Tools
Board » General » some sphwiki extensions

I have been slowly bringing my Django site http://boodler.org up to speed. The Sphene wiki is the only app there so far. But I've done a fair amount of stuff to it.

Some of this may be features you want. Some probably isn't. And there are some purely stylistic changes. I don't have a feature-by-feature set of patches; I've just taken a snapshot of my Sphene Python code and templates. I apologize for the -- er -- big dump. Hopefully the Django setup is modular enough for you to navigate. Feel free to incorporate anything back into Sphene that you want (BSD license).

- A "change password" view. (Linked from the login page.)
- A "recover password" view. (Ditto. This emails you a magic URL, like account registration does; you can use the URL to set a new password.)
- Wiki search feature.
- Wiki "redirect" links (forward any page to any other page, with protection against loops).
- Changed the wikilinks extension to require `[square brackets]` (no auto-detection of CamelCase words)
- Changed the wikilinks extension to accept more characters in snip names (spaces, punctuation, etc). This required editing a lot of templates to add "|urlencode".
- Wikilinks extension tries to make new Wiki pages have title-cased names. (So if you put `[some stuff]` in a page, and then click it, you'll get a new page titled `Some Stuff`.)
- Hid the title field for Wiki page editing (I figured that 99% of the time, the title should be the same as the snip name).
- "Recent Wiki changes" now only shows the last 50 changes.
- Wiki pages have HTTP Last-Modified header
- Many pages (wiki and login) have HTTP headers to ensure that clients don't cache stale pages.
- Wiki header for a page says "Edit", "Log in to edit this page", or "You can't edit" (as appropriate).
- Added `__str__` display format to some wiki models.
- Changed some tab indentation to spaces in Python files.

Warnings:

- The search feature doesn't pay attention to wiki-view permissions. It'll show you pages you can't view.

Whew. There are probably features I've forgotten -- my notes are scattered all over the place, and I haven't done a diff against the original Sphene source. Let me know if you have any questions.
Jeez, it'd be smart if I included the URL for my code:

http://eblong.com/zarf/boodler/sitework/
nice, thanks for sharing your efforts :)

there are quite a few useful features which i might add in the near future in one way or another.. (i just did a small diff between your code and the current SCT trunk... so i have not much insight into the code of every modification)

btw. which version of SCT are you using ? the 0.1 release or a SVN checkout ? - since there are no .svn directories i assume the release ? it might be worth looking into a way to incorporate your changes and still make it updateable .. there are a few new useful features (e.g. hierarchical wiki snips like Sandbox/Mytest)

- A "change password" view. (Linked from the login page.)
- A "recover password" view. (Ditto. This emails you a magic URL, like account registration does; you can use the URL to set a new password.)

this is really useful :) was already requested for SCT once.. i'm not sure about 'change password' (because i'm planning on creating a full featured settings/profile view) but recover password will find it's way into SCT
- Wiki search feature.

i still think this can be solved more generic for all django models which would allow a simple search through all models of a website (like wiki and board). *hope django.contrib.search will be done one day*
- Wiki "redirect" links (forward any page to any other page, with protection against loops).

good idea.. seems easy to implement (beside loop protection) .. i'll try to integrate it
- Changed the wikilinks extension to require `[square brackets]` (no auto-detection of CamelCase words)
- Changed the wikilinks extension to accept more characters in snip names (spaces, punctuation, etc). This required editing a lot of templates to add "|urlencode".

i actually like the current wiki link handling (except not beeing able to escape squarebrackets-links) - i guess the best way would be to allow customization of the regular expression in a SPH_SETTINGS variable (configurable in settings.py) - what do you think ?
- Wikilinks extension tries to make new Wiki pages have title-cased names. (So if you put `[some stuff]` in a page, and then click it, you'll get a new page titled `Some Stuff`.)
- Hid the title field for Wiki page editing (I figured that 99% of the time, the title should be the same as the snip name).

well .. depends on how you are using the wiki .. i use the title field quite often. maybe we can use this title-magic feature to simple prefill the title field with a useful default value ? - this way users can simply ignore it if they like to.
- Wiki pages have HTTP Last-Modified header
- Many pages (wiki and login) have HTTP headers to ensure that clients don't cache stale pages.

i haven't thought about browser caching for SCT .. your middleware seems to do the right thing .. :)
- Wiki header for a page says "Edit", "Log in to edit this page", or "You can't edit" (as appropriate).

I figured that users who have no permission to edit wiki snips are not interested in the information that if they would have enough permission they could edit the site :) .. but i guess it's just a template adaption, so you can easily customize it.. (outside the SCT codebase to remain the ability to update easily)
- Changed some tab indentation to spaces in Python files.

yes, i already changed all my editors to use spaces ;)
i should grep through all sources and remove any remaining tabs...
Whew. There are probably features I've forgotten -- my notes are scattered all over the place, and I haven't done a diff against the original Sphene source. Let me know if you have any questions.

thanks again for your contribution - i'll try to extract as much code/ideas as possible ;)

one question tough .. as i said above .. what do you think about updating SCT ? since your patches are so integrated i don't think it's easy.. but since i probably can't include all your changes into the SCT codebase maybe we should think about a way so you can customize SCT without having to modify all the code ?
Hey, we have Signatures !!! Great, isn't it ? ;)
so, i have now converted most of your listed features into enhancement requests in the issue tracker: http://code.google.com/p/sct-project/issues/list so i don't forget to look into it :)


--- Last Edited by Herbert Poul at 2007-06-08 00:09:01 ---
Hey, we have Signatures !!! Great, isn't it ? ;)
> btw. which version of SCT are you using ?

I started with an SVN snapshot:

Last Changed Rev: 235
Last Changed Date: 2007-05-20 11:44:50 -0700 (Sun, 20 May 2007)

> ...search...
> I still think this can be solved more generic for all django models

I'm sure it can, but I needed a solution now. :) (Same was true for the password changing stuff.) I will also have an account/profile page someday, but I wanted to start with a working system.

> i actually like the current wiki link handling (...) - i guess the best way would be to allow customization of the regular expression in a SPH_SETTINGS variable

I figured this was a stylistic change -- I wouldn't expect my preferences to be universal. But it wasn't just a regexp change; I twiddled the handle_wikilinks_match() function in a couple of different ways. I don't see a way to make this completely customizable without doing that.

Maybe you could just have a boolean setting for camelcase/no camelcase, and let the user hack code if he wants to get any more complicated.

> what do you think about updating SCT ?

Well, some of my changes are pure extensions, like the Last-Modified middleware. You might as well grab those. Template adaptations, like the "log in to edit" change, you don't need to worry about.

The code tweaks? It's probably too early for you to worry about allowing every possible site preference. I found the Sphene code very congenial to modify, because it's simple. The next guy who comes along will probably make a completely different set of modifications, and if you try to make it flexible enough for everybody, it'll just get complicated and buggy.

The one further feature I plan (maybe this weekend) is anti-collision in the wiki editing. If two people try to edit the same snip at the same time, the second one should get a warning when he saves.
Just for future reference -- here's a blog post I found, and now it's how I'm doing all my SCT hacking. Bazaar is very cool.

Being able to generate diffs on demand from the upstream subversion repository is quite quite handy, especially since google's issue tracker has an attachment feature just for said diffs. :)
What? You wanted a sig?
I see if I can use chinese/中文 to post.
I see if I can use chinese/中文 to post.
this is weird .. it works for me on linux.. but on windows i only see '?' .. anyway .. did it work for you ?

and.. you could have created a new thread for this, you know ;) *thinking about creating a sandbox forum category*
Hey, we have Signatures !!! Great, isn't it ? ;)
- Wiki pages have HTTP Last-Modified header
is there a reason, you have done this as a thread local, instead of just putting it into the response object ?

it seems that every view which would want to set the last modified header would have access to the response object ?
Hey, we have Signatures !!! Great, isn't it ? ;)
Post hidden by Herbert Poul :
SPAM !!!!!!

Please login to post a reply.



Powered by Sphene Community Tools