Users/DetlevLengsfeld

High, i`am german without deep knowledge of python and of course english.

today i have a look of the code — brilliant —. very clever things to learn :)

i try to "downgrade" some macros and i`m looking for some tipps to debug the macros and some thoughts the reason
to change to a db.

anyone willing to help?

shame on me and my teacher. Please edit the mistakes!

Detlev DOT Lengsfeld AT t-online DOT de

http://mobbing-gegner.de

Comments:

Note: You must be logged in to add comments

Hello Detlev! As for the "relative_dir" and "add_on", that is thing we did in some places before we understood the right way to do it (request.getScriptname()) — I will try and remove all references from the code ;). I'm not sure what you mean by "debug the macros?" Do you mean tips on how to port them to MoinMoin? If this is what you mean, then I am not sure as there are some fundamental differences.

As far as "why are we using a database?" The reasons were not immediately clear to us from the get-go. There were a number of changes we needed to make to MoinMoin to make it operate in a manner we wanted, and many of these related to performance. For instance, we wanted to be able to keep page names case-insensitive but still case-knowledgable. We wanted to be able to see edits users made and figure out which edits were made to particular pages and sets of pages, and combine various pieces of information. We found that we were building a lot of ad-hoc solutions (serializing things to disk, moving lots of directories around), and that we would be much better served by taking advantage of a database as both a data store (especially for things like locking) and as a source for relational information (who edited this? what else have they edited?). This also becomes important when you start asking a lot of non-flat questions such as "What are all of the Wanted Pages? What are all of the Orphaned Pages?" You can maintain your own little databases for each of these, but in the end you're still using a database — simply one of your own construction that does not allow relational queries.

The advantage of not using a database is that it is not a dependency. I don't feel that this is too large of a drawback, and it is certainly possible to make Sycamore run on something like SQLite and package the flat database with the download — something like a "quick install option." This would actually be a lot of fun to work on, I think!

—PhilipNeustrom

-thx a lot. i need to read it twice :)

—

Step one:

• svn to grab the code
  

• edit pass in vi share/sycamore_config.py for the mysql-admin if any
  

• relative_dir =
  

• restart and feel free to test :)