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.