Es gibt einen dummen und bekannten (ticket 10062) Fehler im django admin panel. Einige Links (wie logout und Passwort ändern) werden nicht richtige generiert.

Ich hab jetzt ein scheinbar funktionierenden work-a-round dafür: In der eigenen admin.py setzt man den root_path Pfad neu:

1
2

from django.contrib import admin
admin.site.root_path = "/admin/"

Damit sind die URLs ok. Ich weiß allerdings nicht ob das ganze Nebenwirkungsfrei ist.

Das ganze dürfte sich dann erübrigen, wenn http://code.djangoproject.com/ticket/10061 aus der Welt geschafft wird.

Siehe auch: http://www.python-forum.de/topic-18841.html

EDIT:
Sehe gerade im ticket gibt es die Lösung auch schon, siehe: http://code.djangoproject.com/ticket/10061#comment:23

Nett, bei sourceforge gibt es neuerdings die sog. Hosted Apps. Das sind u.a. Trac und phpBB.

Leider kann man aber die Daten eines bestehenden phpBB nicht importieren, siehe: http://apps.sourceforge.net/ideatorrent/sourceforge/ideatorrent/idea/7/
Somit bleibt das phpBB für PyLucid erstmal so wie es ist.

Informativer Blog Artikel, wie man upload Pfade bei django file uploads organisieren kann:

• http://www.mahner.org/posts/ordnung-im-medienordner-dynamische-upload-pfade/

Tja, anscheinend hab ich mit dem ASUS P5E-VM SE eine schlechte Wahl getroffen. So wie es aussieht ist es nicht möglich den AHCI Modus zu aktivieren, weil anscheinen im BIOS keine Option dafür gibt :(

Es gibt zwar die nicht näher beschriebene Einstellung "SATA Configuration" die man mit auf "Disable", "Compatible" und "Enhanced" stellen kann. Aber leider aktiviert der "Enhanced" Modus nicht AHCI.

Der Intel Chipsatz ICH9 soll aber AHCI können.

Siehe auch Forum Eintrag bei ASUS:
http://vip.asus.com/forum/view.aspx?id=20080824053216718&board_id=1&model=P5E-VM+SE&page=1&SLanguage=en-us

Nettes Programm gefunden um Python Regular Expression zu debuggen:

• http://kodos.sourceforge.net/

Sieht unter GNOME zwar nicht so ganz schick aus, aber es geht ja auch um die Funktion ;)

Wenn man mal wieder mit Python an Metadaten aus Binären Dateien kommen will, sollte man mal einen Blick auf Hachoir werfen:

• http://hachoir.org/

Eine recht simple Lösung, hat Martin in seinem Blog vorgestellt:

1

{{ entry.published|date:_("DATETIME_FORMAT") }}

Neben DATETIME_FORMAT gibt es noch: DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT

Mehr Info's zum Thema: http://www.mahner.org/weblog/automatisch-lokalisierte-zeitformatierungen/

Sollte ich mal in PyLucid überall nutzten: http://trac.pylucid.net/ticket/261 ;)

Mit PyLucid v0.9 wollen wir von Null anfangen, mal wieder ;)

PyLucid soll i18n auch bei den CMS Inhalten bekommen. Das bisherige Datenbankmodell passt dafür natürlich nicht.
Der Plan für v0.9 soll auch sein, noch näher an django herran zu rücken. u.a. Aufsplittung in mehrere kleinere Apps. Das Plugin System wird wohl auch anders ablaufen...

Es wäre jetzt also ein guter Zeitpunkt mit zu machen. Wir möchten gern unser Team vergrößern und brauch immer Hilfe...

Wer Lust hat, bitte melden:

• im Forum: http://www.pylucid.org/phpBB2/
• im IRC: #pylucid auf freenode.net
• Jabber: pylucid@conference.jabber.org (besser IRC ;) )
• http://groups.google.com/group/PyLucid-general (recht verstaubt)

Hab mir mal Gedanken darüber gemacht, wie man verschiedene Django Apps aufbauen kann, damit sie dich nicht gegenseitig ins Gehege kommen.

↑ app settings  #

Jede django App kann eigene settings haben. Ich persönlich hasse harcoded Zeugs. Ich packe alles in Konstanten rein. Doch wenn man mehrere Apps hat, die jeweils für sich ein paar "Einstellungsdaten" haben, wie soll man das organisieren?

Einfach schreiben, diese default_settings.py mußt du in die globale django settings einbauen, ist nicht so schön.

Meine Lösung sieht so aus, jede App hat eine eigene settings Datei, die in der globalen importiert wird. Damit sich keine Überscheidungen zwischen den Apps geben kann, packen wir das ganze in einen eigenen Namensraum. Hier ein komplettes Beispiel:

• .../FooApp/Foo_settings.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

"""   
    Foo app settings
    ~~~~~~~~~~~~~~~~
    All own settings for the 'Foo' app.
"""

# A example variable 1
VAR1 = True

# A other example variable:
VAR2 = 10

In die globale settings.py importiert man alle App settings und kann ggf. Werte ändern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

"""   
    global django settings
    ~~~~~~~~~~~~~~~~~~~~~~
"""

# import the 'Foo' app settings
from FooApp import Foo_settings as FOO

# example overwrite one variable:
FOO.VAR2 = 20

↑ Beispiel app view  #

Im App view kommt man an die settings so dran. Man kann auch schön sehen, welche App die Einstellungen gesetzt haben:

• .../FooApp/views.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

"""   
    Foo view
    ~~~~~~~~
"""

from django.conf import settings

def foobar_view(request):
    """ Beispiel view """
    msg = 'Variable 1: %s' % settings.FOO.VAR1
    return HttpResponse(msg, mimetype="text/plain")

↑ app urls  #

Jede Applikation hat seine eigene urls.py:

↑ Beispiel app urls  #

• .../FooApp/urls.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

"""
    Foo app urls
    ~~~~~~~~~~~~
"""

from django.conf.urls.defaults import *
from django.conf import settings

from Foo import views

urlpatterns = patterns('',
    url(r'/$',     views.view1, name='Foo-view1'),
    url(r'/url2/', views.view2, name='Foo-view2'),
)

Note: Don't use strings, import the real function. So you will get real import errors, if something is wrong.

↑ global urls  #

In der globalen kann man diese mit include reinholen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

"""
    main urls
    ~~~~~~~~~
"""

from django.conf import settings
from django.conf.urls.defaults import *
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    (r'^admin/(.*)', admin.site.root),
    ...
    # include the application urls:
    (r'^Foo', include('Foo.urls')),
    ...
)

↑ app templates  #

Jede Applikation hat natürlich auch eigene Templates. Am einfachsten ist es, ein Unterverzeichniss mit dem App Namen zu erstellen und dies in den views anzugeben:

• .../FooApp/templates/FooApp/Bar1.html
• .../FooApp/templates/FooApp/Bar2.html

Im view macht man dann:

1
2
3
4
5
6
7
8
9

...
def my_view1(requesr):
    ...
    return render_to_response('FooApp/Bar1.html', context)
...
def my_view2(requesr):
    ...
    return render_to_response('FooApp/Bar2.html', context)
...

Wie seht ihr das alles???

Muss ich mal ändern:

http://blog.macromates.com/2005/key-bindings-for-switchers/