20100128 Arbeitsbericht

Aha, das ist cool: “it is also possible to update an issue by putting an issue tracker command in your commit-log message.” [http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control (1)]. Das muss ich gleich mal probieren, das wäre vielleicht ein guter Nachkomme für meinen [Blog], der ja auch nicht ganz das Wahre ist.

Ich hatte gemerkt, was mich am Google Issue Tracker stört: dass man nicht die komplette Datenbank der Issues und Comments runterladen kann. Dabei stimmt das gar nicht: http://code.google.com/p/support/wiki/IssueTrackerAPIPython

New issue
Summary: Implement server actions as generator functions
Labels: Type-Enhancement
Labels: Priority-Medium

Momentan führt jedes context.confirm() in Actions.run() dazu, dass der Code ein zweites Mal aufgerufen wird. Um das zu vermeiden, könnte ich Actions als generators definieren. In Action.run() müsste man dann sagen yield context.confirm(). Bin noch nicht sicher, wie die laufenden Generatoren dann in der Session gespeichert werden. Kann man einen Generator pickeln?

New issue Summary: Show user messages Labels: Type-Enhancement Labels: Priority-Medium Meldungen wie “Welcome, user X” sollten nicht in einer MessageBox.alert() gezeigt werden, sondern irgendwo in einem scrolling text field erscheinen, wo man die letzten paar Meldungen nach sehen kann.

Update issue 64 Im Login-Fenster ist jetzt (seit dem vorigen Commit) nach dem Öffnen das erste Textfeld fokussiert. Das, was ExtJS den defaultButton nennt, nenne ich start_focus. Für Grids und Details ist das wohl noch nicht gelöst.

New issue Summary: Implement Layout.default_button Layout.default_button ist der Button, der ausgeführt werden soll, wenn man in einem Textfeld des Fensters ENTER drückt. Das ist momentan überhaupt noch nicht implementiert.

Und jetzt bin ich mal gespannt, wie mein changelog aussieht. Ich mach jetzt hg ci -l 20100128.txt. Nein, das geht noch nicht, weil Mercurial darauf “Nothing changed” sagt. Hat seine Logik. Soll ich vielleicht meine Changelogs auch ins repository setzen? Na probieren wir das mal.

T:\hgwork\lino>hg add changes\20100128.txt
T:\hgwork\lino>hg ci -l changes\20100128.txt
T:\hgwork\lino>hg push lino
pushing to https://luc.saffre:***@lino.googlecode.com/hg
searching for changes
Success.

Und? Wie sieht das nun auf der Projektseite aus? http://code.google.com/p/lino/source/detail?r=39093d20dad3824d4877a8765018dcb11c4482cc

Uh… also kennen commit logs offenbar nicht WikiFormatting. Nachdem issue comments das wohl kennen, hätte ich das eigentlich erwartet.

Und zweitens sehe ich, dass man nur ein issue auf einmal pro commit bearbeiten darf: “These commands begin on some line in your commit-log message and continue until the end of the message.”

Schade. Also diese Datei kommt in meinen WikiBlog. Und ich könnte mir angewöhnen, die URL des Arbeitsberichts mit hg ci -m anzugeben.

—

Weiter in lino-igen. Am Layout von LoginForm und InvoiceDetail gewerkelt. InvoiceDetail findet noch nicht die DocItems. Scheinbar wird der mk und mt nicht richtig gesetzt. ReportRequest.extra wird jetzt auf 0 gesetzt, wenn man keine Records einfügen darf. Wenn master_instance None ist und das ForeignKey-Feld zum Report.master nicht nullable, dann darf man ebenfalls keine Records einfügen.