Hello,

I finished the Italian translation for the sphene apps: the files are attached. The translation is updated to sphene r803.

Please grant Antonio Fittipaldi credit for the translation: his email contact is in the files header.

Cheers.

Mmm... this seems a very clean and straightforward way of creating private messages It's different from what I did, but at a first glance it seems better integrated with the current system architecture.

to have a message in an "outbox" of one user and an "inbox" of another i would create multiple 'ThreadInformation' objects (similar to what happens when you move a thread from one category into another - a new ThreadInformation is created which points to the root of the posts)

this would solve the permission problem and will give you hierarchical categories for free (although a UI is still missing to create categories ) - and the statistics (number of threads, number of posts, etc. would work)

It makes perfectly sense, I'll check this alternative way of implementing the thing.

Thank you very much,

-- Daniele

Hello Herbert,

I have been working on private messages this weekend and I come up with the attached patch. The job is not finished yet but I'd like to have some feedback.

What I did was to add a PostRecipient object which joins a Post to many User, also carrying the information about which type of recipient is - e.g. To, Cc, Bcc (this information is not used in any way yet). I also added a CategoryType to handle private messages, so they appear as a category in the category list. The category provides many of the informations you designed it for, such as a customized form an an hook for saving the PostRecipient records upon save.

A few things were not possible just using the categories: e.g. only display the messages an user is allowed to see when he displays the category. This is done at model level: Category.posts, Category.get_thread_list now constrain the returned queryset if the message is private: an user can see a message only if he is the author or is one of the recipients.

Notice that it is hard to define if an user is entitled to display a thread: he may have privileges on a few messages but not on all of them, so we can't take decision just looking at the first or the last post in a thread, and a query such "select all the thread in which at least a message is sent to or created by the current user" sounds quite inefficient and maybe not easy to write using the Django orm. For this reason, private messages don't create thread: when a message is answered, the threading is purposely broken (now, talking about that, I start seeing a solution: I may replicate the thread_id on the recipient record, so that it would be easy to spot all the threads where an user posted at least a message - and adding an extra recipient record with the author I would get rid of the "or he is the author part". mmm... I'll see if it can work tomorrow).

When editing a private message, an extra field is shown, where a list of recipients can be entered. It is a customised widget also performing validation; a tool popping up a window and allowing users search would be nice to have in the future.

I'd love to hear some feedback from you or any other user interested in the feature. Thank you.

Hello,

we already made a few customizations to the sphene code, and we planned a few others soon enough. We want to add private messages and IP tracking, but I don't know how much effort will be required, so I don't want to block your release plan waiting for them.

I didn't provide the already available patches yet because they depend on the current wysiwyg editor, and the situation seems quite dynamic on that front. But it's probably better to describe it.

I added a better support for smileys: namely we can customize the mapping string -> filename (for our board we adopted the free icons from the tango project, which look very nice). Customizing such mapping touches a few areas of the program:

- the mapping in the python bbcode -> html converter
- the wysiwyg toolbar
- the html -> bbcode javascript regexps

The problem is that customization is currently not performed using the database, but using a script: it works fine enough for me, having file system access to my machine, but is probably not acceptable: I think customization should be done from the admin and the mapping should be stored in a database. This would work perfectly on Python side, but the customized map should be passed (in different forms) to the javascript. Currently the javascript is contained in static files, and this is a good thing for deployment.

So what would you do? Serving a dynamic javascript or generating the javascript via a script? I would consider the static js a priority, but I can't figure out an idiot-proof way to replace the static files.

Another feature we already have in place is the board messages icon. But that too would require mappings, new icons etc. (no js luckily), so I want understand first how to solve the above issue.

At this point interesting things seems about to happen: will Sphene keep using the currently available small wysiwyg editor, nice and lightweight as it is, or adopt a more affirmed editor such as FCKeditor/TinyMCE? I feel the scenario quite tangled

Those are my current concerns about some interesting things we wrote and which I'd like to contribute back. Apart from these doubts, I'll be glad to contribute any feature/bugfix we will write.

Cheers!

P.S. Neither dropping the bbcode nor completely rely on a wysiwyg editor seem a good idea to me. I think the underlying language for the board/wiki should be a markup and people should be free to edit it either using wysiwyg editor or a regular textarea. My use for Sphene is to convert an existing SMF forum where people is already used to BBcode: for me, I prefer a perfectly working BBcode to a markup yet to be written (and hardly hand-writable as an xhtml-based one would be)

Hello,

I just submitted two patches into the issue tracker. #162 adds the post tags to the feeds. To accomplish that, LatestBlogPosts is fed with BlogPostExtension objects instead of Post (which actually simplifies something). Please double check if I changed everything accordingly.

Patch #163 fixes a double-escaping issue in the post titles.

Both the features have been tested using an esternal aggregator (feedjack).

Cheers.

I got this idea: this is not xhtml, which is a well defined xml language, but another xml language of your own. You are right that this would save you from the hassle of deciding whether [ i] is a link or the start of an italic section: the "well formedness" part is ok. You can't directly render your language because you have some tags more <sct:wikiurl> and some less <script> so you will have to undergo a translation phase: in this respect the language would be like the other ones (it may easily be accomplished by tools such xslt... if you are into them).

I see good parts in your idea (the language is soundly well formed) but xml is not meant to be edited by people: you should heavily rely on a wysiwyg editor or the user experience would be pretty bad. I am not a great fan of them, and I would like the idea of being able to use a regular textarea and edit something easily hand-readable/writable.

Daniele Varrazzo said @ 2009-07-04 03:23:50:

choose the wiki language: I added a "markup" to the WikiSnip and WikiSnipChange objects with the relevant code to manage them, created a "register" of renderers and added a few configuration settings: default markup, list of available markups,

i think choosing a markup on a per-wiki snip basis makes even less sense than for posts. i came to the conclusion after experimenting with the forum that it hardly ever makes sense. what if you have written your post in ReST - and now i want to quote you.. but i write BBCode.. how is that going to work out? -- this is solvable obviously, and i have thought about strategies.. but it still won't be perfect no matter how it is implemented.

for the wiki, it will be even worse.. so if you want people to contribute to a wiki, they won't have to know one markup language, but dozens, because everyone who created a new wiki snip will probably have chosen another markup.

so probably the only thing that would make sense.. is to make it configurable for the whole website (or at least on a per-Group basis).. not for every snip.

You are perfectly right: i like the idea to have the language selectable per site or per group basis, but having it per snippet could quickly become a mess. I would probably leave the option to have the markup selectable by record (e.g. to be able to import pages from other wikis at database level) but personally, in my website, I would choose a markup language of my taste and stick with that.

but what you have to always think about is that once you made a choice of markup language, and are starting to use it on your site - there is no way on going back. i see it on this site right here.. i have enabled the autolinking of CamelCase words into the wiki.. this sounds great and everything, but in most cases it is just plain annoying. but i can't just turn it off, because it might be used in one or two locations. (the same goes for wiki links in brackets .. or even bbcode.. on http://thedjangoforum.com we were talking about some python code and in that code an array was accessed with the variable 'i' .. so you've got blah[ i ] .. without the spaces it would turn into 'italic'.. this is why i'm saying.. this whole markup stuff is extremely painful. it always gets into my way. so even for me i slowly start to doubt that anything beside XHTML - where i KNOW the rules, and they make sense to me is the right choice. and every user who is not familiar with XHTML will probably be annoyed if he has to learn another markup language - so give him a WYSIWYG editor and he will be more than happy.)

Yes, this is the sort of problems for which I think designing a markup language is not an easy task. Our conclusion are instead different instead I'm for using an already established markup language, you seem more willing to rely on a wysiwyg editor.

So maybe the right choice would be to use TinyMCE, FCKeditor or any other wysiwyg editor and add custom extensions to create wiki links, attachments, insertions of macros, etc.


what is your incentive on using another markup language?

My main point is that using xml by hand is a pain, while markup languages are designed to be used by hand. But I know there are camps in which that would be a lovely choice, and I don't want my ideas to stop the adoption of your tool elsewhere. I've also had in the past bad experiences in using wysiwyg editor: let's say that for me as an user I prefer to be able to use a plain textarea because it gives me more precision (if the markup supports me), "useful diffs" as you mention and such. But for me as a site admin I would like to be able to choose the markupof the wiki and eventually let people use an editor if they wish to.

I think your xml-based language would not be more easy to handle for a JS editor: because you have to basically whitelist the tags you want to accept (and tranlate some others), I think the roundtrips SpheneML <-> xhtml would requre the same "amount of works" of the others. My experience with JS editors as developer is limited anyway (the only one I looked into is the experimental sphene one) and i see it's everything a matter of bunches of regexp.

hehe, sorry for that long reply i am somehow not satisfied with any markup solution in SCT yet (and probably not for any wiki out there) and i fear implementing my vision of a simple wysiwyg editor which generates beautiful code which result in useful diffs, is not really easy to do.

It's a pleasure to be able to discuss about these points I think sct is a good package of products, the board rocks, and the wiki is already well structured at models level.

I did some work on the experimental wysiwyg in sphene, and it was relatively easy: because I am converting an existing board, I used my set of smileys and hacked the editor to inject smileys such ": )" instead of [ img]: It was, as I mentioned, a matter of regexp. You can check the result to this board (sorry, you should register to be able to see the editor: I've not been able to use the captchas yet).

After this experiece, I may say that I can refactor the "Renderer" into an object exposing these interfaces:

- render a board message
- render a wiki page
- provide JS for a wysiwyg editor to convert html -> markup
- provide JS for a wysiwyg editor to convert markup -> html

and make the markup language "pluggable" onto the current models.

Notice that the JS conversion are only relevant to the current editor: it may be that using FCK or others they end up not being request: I will investigate into that.

btw, in our forum, you may see other features in the board: message icons, Italian translation and a method to choose the smileys set: the patches are not polished yet for submission to sct: I will ask you something else in other post and then provide you good patches (but if you want "bad patches", they are already available )

Hello,

Herbert Poul said @ 2009-07-02 09:32:59:

probably the best way would be to use a subset of XHTML - it is well defined and most people on the web are familiar with it. on top of it it should be easy to hook up a WYSIWYG editor with custom features for the wiki. i guess this would be the perfect solution. what do you think?

well, i think the path of designing a markup language on our own is tricky: it has already been taken by a lot of people and groups and there are already dozen of them (I should have mentioned WikiMedia, probably the most used, and Creole, which is a tentative standard).

I think the choice of a wiki syntax is really a matter of personal preference, so i started implementing the possibility to choose the wiki language: I added a "markup" to the WikiSnip and WikiSnipChange objects with the relevant code to manage them, created a "register" of renderers and added a few configuration settings: default markup, list of available markups, whether the markup choice is available to the web interface... But then I noticed that a lot of the same things are already available in the sphboard. So now i'd take a different path:

- move the renderers from sphboard to community
- instead of having a render() method, add render_post(), render_wikisnip() methods to the Renderer class.

If that's ok for you, I can provide a patch for that (but I won't be able to work on it the next week). I already implemented a reST wiki renderer, but it doesn't implement the proposed interface: i'd be glad to refactor it and have a single register of renderers, for both wiki and board.

Cheers.

Hello,

I'd like to know what is the rationale behind the adoption of Markdown as wiki language.

The main issue with MD is that it is designed to express just a tiny fraction of what can be expressed in html (as is cleanly stated), and to let users to use html as fallback. The problem is that in the wiki you are not supposed to use html tags: the wiki is in safe mode, as rightly so, and html/js injection is not supposed to be allowed.

What remains of MD is the core language (which is frankly poor designed, with feature such as <br> relying on invisible suffix whitespaces, no tables etc.) and whose implementation is hard to extend (e.g. you had to patch the source to extend the language with your tags, but now that new MD versions have been released, porting those patches has to be done yet).

There were other choices as wiki markup language: a couple that come to mind are:

- reStructuredText: it is a more complete markup language and one particularly famous in the Python world (since Python 2.6 it replaced LaTeX as documentation)

- BBCode: I don't know about any wiki using such language, but being already used in the Board it may be a consistent choice.

reST is more easily extendible: your extension macros could have easily been plugged in as "extension directives" without hacking the source. It has the disadvantage to not allow WikiWords to be automatically converted into links (but actually with a preprocessor it can be done). The more natural way to create a link could be the "default interpreted text role", e.g. `page` (which would work both with CamelCase words and not), but for us (the Italian Python community) there is the extra disadvantage that the backtick character is not available on the Italian keyboard (at least on Windows, where an ALT+0096 is required... and laptop users are out of luck).

I don't know neither BBCode design (if any exists) nor the implementation used by Sphene, so I don't know if it could be successfully used in the wiki and if it is easily extendible, but at least it would be something not to be learned: everybody already using the Board would be already able to create and edit wiki page.

So I ask: is Markdown really a choice you've done after pondering about other possibilities, and about which you are still convinced? Or at this moment you would consider other choices (reST, BB or other I am not aware of)?

Some of my users already expressed a preference in reST, but none of them has actually started a sphene-docutils integration. I have currently planned to implement other features before doing it (which could actually be a bad decision: if then I'll find a lot of wiki pages to convert, that could discourage me). What is your opinion about:

- having MD replaced by reST

- having a choice of different wiki languages (e.g. with a global setting, with a dropdown under the page etc.)

I'd like to know other Sphene users opinion as well.

Thank you very much.

Hello,

Markdown allows horizontal rules (using a syntax such as "---") and paragraph breaks (adding two spaces before a break). But in Sphene wiki these items get censored with an HTML REMOVED.

The patch available from http://trac.python.it/sito/changeset/107%3Ad1f02e9c2ed1 allows these items to be used in safe mode too.

I will ask something else about Markdown in another post.

Uhm, yes: it is actually the case. I missed the DEFAULT_FROM_EMAIL documentation and assumed SERVER_EMAIL was the properly configurable one. Looking the documentation for both settings it seems the DEFAULT_FROM_EMAIL is more appropriate.

I was also mislead by the fact that you pass a None in the "datatuple" where the documentation for "send_email" says it expects a string, so I thought "webmaster@localhost" was a form of "last resort fallback", not a configurable setting. In my case an explicit "DEFAULT_FROM_EMAIL" in the datatuple building would have been a more explicit "go read the Django docs" instead of a "toh, I found a bug" message

Herbert Poul said @ 2009-06-12 09:34:34:

good idea with the prefix - but maybe it would make sense to let the whole string be configurable, what do you think?

If it were internationalised, it could be a good default. Because it contains placeholders, it is a little bit tricky to be configured anyway. If it were a configuration setting, its default should be localised, and in this case I would -personally- probably keep the default. At this point you may also want to configure the body... I would personally leave both title and body in the code and leave people who really want to change them to hack the code

By the way, as soon as I started testing the board, I received three "bug reports". All of them, upon investigation, revealed being just parameters to be tweaked and not bugs in the code. So I should say congratulations: even the sphene trunk, set up by a newcomer, seems production ready The only problem was probably a strange choice for some parameter defaults (6 hours to update the post count?) and a not very visible (but actually available) documentation.