Luc's Lino Blog

Adieu wysiwyg blogging

2010-02-02T09:11:00.000+02:00

I started to blog on Lino's WikiBlog, and it seems that I like it better than Blogger's wysiwyg editor. Such a self-made WikiBlog is probably less easily readable, but more easily writable.

Why doesn't Blogger support any wiki format?

2010-01-12T15:54:00.002+02:00

Blogger isn't really my thing because I hate to blog when the blog server doesn't support wiki format.
So today I misused the Lino wiki for blogging.
Result: I write more.
But then I read Wiki markup is dead...
Hmm...

New ideas for Lino.do_action()

2010-01-07T10:51:00.003+02:00

Working on issue 61. Some of my thoughts...

Lino.do_action() does an AJAX call on the specified URL. This URL defines the action that runs on the server. Lino.do_action() then reacts according to the response.
The action may return a "job" (response.job, previously response.call) to be executed by the client.
Maybe "reaction" would be a better name than "job". But let's call it a job because that name is not yet used in Lino's source, and after all this thing becomes a "job" for the client in the meaning that it will continue to run until some other action asks to stop it.

For example a report action, on the server, will check whether the user is allowed to see this data, will load window_config, and then return a Job that will create the Ext.Window with all its components and also call the show() method. The close() method of that job just closes this window.

If response.job is defined, it must be a string of JS code that defines a constructor function.The client will instantiate a new object using this constructor.
The constructor must initialize the new object so that it implements the Job interface:
- stop()
- refresh()
- selected_rows()

Note that there is no start() method. This is because the Job is supposed to start it's work during instantiation.

Lino.do_action() will need a new parameter "caller" (the Job who requests this action), and the parameters reload, close_dialog and job_params can go away since the caller contains them.
The parameter caller may be undefined if the action is called from a main menu item.

Lino.grid_action(), Lino.form_action() and Lino.show_detail() can then go away

Implement report windows as actions

2009-12-16T16:59:00.002+02:00

Hier ist nochmal ein Bild der aktuellen Situation.

Oberflächliche Probleme:

Submit in PersonDetail funktioniert nicht. Traceback "field 'name' may not be null. Das kommt, seit ich django.db.field.to_python für die Konvertierung benutze.
The comboBoxes of ForeignKeys don't display the values.
Focussing problems: after closing a window, the previous window should get keyboard focus. When a Window with a Grid gets focus, it should forward the focus to it's grid.
links.Link should provide a virtual column that offers clickable display of the url, as well as drag&drop to update it.
Number of rows displayed in a grid should be as much as fits into the window. Or the window should adapt its size to its grid.
PageLayout.layout_for instead of Report.page_layouts

Aber einige dieser Punkte sind wahrscheinlich verknüpft mit einem fundamentalen Problem, das ich deshalb wahrscheinlich als nächstes in Angriff nehme: Implement report windows as actions.
Das bedeutet, dass die Reports nicht mehr wie momentan alle als statische Funktionen im JS vordefiniert sind, sondern dass beim Klick auf einen entsprechenden Menübefehl ein AJAX-Request rausgeht, den der Server mit der Definition des zu öffnenden Fensters beantwortet.

Also statt z.B. der folgenden Funktion, ...

var projects_ProjectTypes = new function() {
this.main_grid = new function() {
    var main_cols = new Ext.grid.ColumnModel({ columns: [ { header: 'ID', width: 45, editable: false, sortable: true, dataIndex: 'id' }, { header: 'name', sortable: true, editor: { xtype: 'textfield', fieldLabel: 'name', allowBlank: false, maxLength: 200, anchor: '100%', name: 'name' }, width: 180, editable: true, dataIndex: 'name' } ] });
    var buttons = [ { text: 'Delete', handler: Lino.grid_action(this,'lino_DeleteSelected','/grid_action/projects/ProjectTypes/lino_DeleteSelected') }, { text: 'Detail', handler: Lino.show_detail(this,'projects_ProjectTypes2') } ];
    var keys = [ { shift: false, alt: false, handler: Lino.grid_action(this,'lino_DeleteSelected','/grid_action/projects/ProjectTypes/lino_DeleteSelected'), key: 46, ctrl: false }, { shift: false, alt: false, handler: Lino.show_detail(this,'projects_ProjectTypes2'), key: 13, ctrl: true } ];
    this.comp = new Ext.grid.EditorGridPanel({ clicksToEdit: 2, colModel: main_cols, tbar: new Ext.PagingToolbar({ prependButtons: false, items: buttons, pageSize: 10, store: projects_ProjectTypes_store, displayInfo: true }), viewConfig: { showPreview: true, scrollOffset: 200, emptyText: 'Nix gefunden!' }, selModel: new Ext.grid.RowSelectionModel({singleSelect:false}), enableColLock: false, store: projects_ProjectTypes_store, emptyText: 'Nix gefunden...' });
    this.comp.on('afteredit', Lino.grid_afteredit(this,'/grid_afteredit/projects/ProjectTypes','id'));
}();
this.show = function(btn,event,unused_master,master_grid) {
    if(this.comp) { this.comp.show() ; return; }
    this.comp = new Ext.Window( { width: 400, layout: 'fit', maximizable: true, title: 'ProjectTypes - List', closeAction: 'hide', items: this.main_grid.comp, tools: [ { handler: Lino.save_window_config('/save_win/projects_ProjectTypes'), id: 'save' } ], id: 'projects_ProjectTypes', height: 300 } );
    projects_ProjectTypes_store.load();
    this.comp.show();
};
}();

..., die momentan im Menübefehl mit projects_ProjectTypes.show() aufgerufen wird, ruft der Menübefehl die existierende Lino.do_action(), und diese action gibt dann eine JS-Expression "new ext.Window(...).show()" zurück, die die gleiche Wirkung hat. Wobei die "..." natürlich ziemlich lang werden können.

Fenstergrößen und -positionen jetzt speicherbar

2009-11-25T04:42:00.000+02:00

Gestern Abend vor dem Schlafengehen grübelte ich noch über das Problem nach, wie abartig es doch ist, dass ich die Größe eines Ext.Window anhand seiner Komponenten selber zu ermitteln versuche. Heute morgen suchte ich zuerst nochmal nach, ob Ext.Window tatsächlich keine fertige Methode "sizeToFit()" oder so hat. Hat er scheinbar nicht.

Aber dann fiel mir ein, dass man ja sowieso die Fenstergrößen und -positionen manuell speichern können muss. Wenn das gemacht wäre, wäre es egal, dass Fenster par défaut immer in der Mitte stehen und alle die gleiche Höhe haben. Also machte ich mich an die Implementierung dieses Features. Keine zwei Stunden Arbeit, und alles funktioniert wie gehabt:
neuer tool-Button "save" in allen Fensterrahmen. Wenn man darauf klickt, wird per AJAX die Position und Größe des Fensters gespeichert. Auf dem Server wohlgemerkt. Einfach mit pickle in eine Datei "window_configs.pck". Momentan also immer global für alle Benutzer. Und ich glaube, dass das bis auf weiteres reicht, denn das sind Parameter, die anwendungsspezifisch verwaltet werden. und alle Benutzer sollen das gleiche Erscheinungsbild haben.

ActionContext kann jetzt mit *args und **kw instanziert werden. Was für die neue SaveWindowConfigAction gebraucht wird.

Und noch eine geniale (interne) Neuerung nebenbei: wenn py2js() einen callable kriegt, dann muss das ein Iterator sein, der einzelne JS-Zeilen liefert. Dadurch konnte ich folgenden Code schreiben:

        def save():
            yield "function(event,toolEl,panel,tc) {"
            yield "  console.log(panel.id,panel.getSize(),panel.getPosition());"
            yield "var pos = panel.getPosition();"
            yield "var size = panel.getSize();"
            url = '/save_win/' + self.name
            yield "  Lino.do_action(%r,%r,{x:pos[0],y:pos[1],\

                h:size['height'],w:size['width']});" % (url,url)
            yield "}"
          
        self.options.update(tools=[dict(id='save',handler=save)])

So, und jetzt schlaf ich vielleicht noch mal was...

Dialogs and Actions

2009-11-23T09:54:00.000+02:00

Wow! Issues 12 and 38 are solved! It is again possible to log in and out, and this is done using Actions and Layouts which are rendered using ExtJS. Here is a code summary:

class Login(layouts.DialogLayout):
    text = layouts.StaticText("Please enter your username and
           password to authentificate.")
    username = layouts.Input(fieldLabel=_("Username"),maxLength=75)
    password = layouts.Input(fieldLabel=_("Password"),
                maxLength=75,inputType='password')
    main = """
    text
    username
    password
    cancel ok
    """
    ok = LoginAction()

class LoginAction(actions.OK):
    label = _("Login")
    def run(self,context):
        username = context.request.POST.get('username')
        password = context.request.POST.get('password')
        if username and password:
            user = authenticate(username=username, password=password)
            if user is None:
                raise actions.ValidationError(
                _("Please enter a correct username and password.
        Note that both fields are case-sensitive."))
            elif not user.is_active:
                raise actions.ValidationError(
            _("This account is inactive."))
            login(context.request, user)
            lino.log.info("User %s logged in.",user)
            context.refresh_menu()


class Logout(actions.OK):
    label = _("Log out")
    def run(self,context):
        context.confirm(_("Are you sure you want to log out?"))
        logout(context.request)
        context.refresh_menu()

These things are then integrated into the main menu as follows:

    m = lino.add_menu("auth",_("~Authentificate"))
    m.add_action(Login(),can_view=perms.is_anonymous)
    m.add_action(Logout(),can_view=perms.is_authenticated)

Isn't that beautiful? I won't show you a screenshot right now because of issue 47. But just remember the screenshot of my previous post.

First results with DialogLayout

2009-11-18T18:49:00.002+02:00

This week I started to implement dialog windows that are defined using Layout. A first visible result is the Login dialog box. Here is the code used to define it:

class Login(layouts.DialogLayout):
    username = models.CharField(
      verbose_name=_("Username"), max_length=75)
    password = models.CharField(
      verbose_name=_("Password"), max_length=75)
    main = """
    text
    username
    password
    cancel ok
    """
    ok = LoginAction
    text = layouts.StaticText("Please enter your username and password to authentificate.")

And here is how it looks:

For the moment nothing happens when you click on ok. That's for tomorrow.
Interesting to notice: Lino uses django.db.models.Field instances to define the form's fields, not django.forms.

A patch for Django ticket #11696

2009-11-09T16:48:00.001+02:00

Django ticket #11696 is still not solved in Revision 11724. I didn't manage to apply the patch posted by anonymous on 09/13/09 18:08:56. Now I wrote my own patch which works for me, and I document it here as far as possible for now.

To install the patch, download the file 20091107.diff into you django's working copyand then type "patch -p0 < 20091107.diff", which should result in something like this:

(Stripping trailing CRs from patch.)
patching file django/db/models/loading.py

Yes I should write some test cases, when I have more time... for now I just write down the situation. I have a site with about 10 applications, and the models.py of one of them tries to import a non-existing module. This situation is stored in Lino 841 and igen 2.

Here is what happens without my patch:

T:\hgwork\igen\src\igen\demo>python manage.py validate
Traceback (most recent call last):
  File "manage.py", line 16, in 
    execute_manager(settings)
  File "l:\snapshot\django\django\core\management\__init__.py", line 440, in execute_manager
    utility.execute()
  File "l:\snapshot\django\django\core\management\__init__.py", line 380, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "l:\snapshot\django\django\core\management\base.py", line 195, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "l:\snapshot\django\django\core\management\base.py", line 223, in execute
    output = self.handle(*args, **options)
  File "l:\snapshot\django\django\core\management\base.py", line 352, in handle
    return self.handle_noargs(**options)
  File "l:\snapshot\django\django\core\management\commands\validate.py", line 9, in handle_noargs
    self.validate(display_num_errors=True)
  File "l:\snapshot\django\django\core\management\base.py", line 250, in validate
    num_errors = get_validation_errors(s, app)
  File "l:\snapshot\django\django\core\management\validation.py", line 28, in get_validation_errors
    for (app_name, error) in get_app_errors().items():
  File "l:\snapshot\django\django\db\models\loading.py", line 131, in get_app_errors
    self._populate()
  File "l:\snapshot\django\django\db\models\loading.py", line 58, in _populate
    self.load_app(app_name, True)
  File "l:\snapshot\django\django\db\models\loading.py", line 74, in load_app
    models = import_module('.models', app_name)
  File "l:\snapshot\django\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "c:\drives\t\hgwork\lino\src\lino\modlib\contacts\models.py", line 29, in 
    countries = models.get_app('countries')
  File "l:\snapshot\django\django\db\models\loading.py", line 114, in get_app
    self._populate()
  File "l:\snapshot\django\django\db\models\loading.py", line 58, in _populate
    self.load_app(app_name, True)
  File "l:\snapshot\django\django\db\models\loading.py", line 74, in load_app
    models = import_module('.models', app_name)
  File "l:\snapshot\django\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "c:\drives\t\hgwork\lino\src\lino\modlib\ledger\models.py", line 26, in 
    journals = reports.get_app('journals')
  File "c:\drives\t\hgwork\lino\src\lino\reports.py", line 44, in get_app
    m = models.get_app(app_label)
  File "l:\snapshot\django\django\db\models\loading.py", line 125, in get_app
    raise ImproperlyConfigured, "App with label %s could not be found" % app_label
django.core.exceptions.ImproperlyConfigured: App with label journals could not be found 

Which is a completely useless error message.
And here is what happens after applying my patch:

  (...)

  File "l:\snapshot\django\django\db\models\loading.py", line 156, in get_app
    self._populate()
  File "l:\snapshot\django\django\db\models\loading.py", line 96, in _populate
    len(self.postponed),msg))
django.core.exceptions.ImproperlyConfigured: Failed to import 3 applications:
lino.modlib.sales:
Traceback (most recent call last):
  File "l:\snapshot\django\django\db\models\loading.py", line 112, in load_app
    models = import_module('.models', app_name)
  File "l:\snapshot\django\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "c:\drives\t\hgwork\lino\src\lino\modlib\sales\models.py", line 49, in 
    from lino.modlib.contacts import models as contacts
ImportError: cannot import name models
lino.modlib.finan:
Traceback (most recent call last):
  File "l:\snapshot\django\django\db\models\loading.py", line 112, in load_app
    models = import_module('.models', app_name)
  File "l:\snapshot\django\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "c:\drives\t\hgwork\lino\src\lino\modlib\finan\models.py", line 32, in 
    from lino.modlib.contacts import models as contacts
ImportError: cannot import name models
lino.modlib.journals:
Traceback (most recent call last):
  File "l:\snapshot\django\django\db\models\loading.py", line 112, in load_app
    models = import_module('.models', app_name)
  File "l:\snapshot\django\django\utils\importlib.py", line 35, in import_module
    __import__(name)
  File "c:\drives\t\hgwork\lino\src\lino\modlib\journals\models.py", line 30, in 
    from lino.apps.documents import models as documents
ImportError: No module named apps.documents

Umstrukturierungen nach Abtrennung von dsbe und igen

2009-11-07T22:11:00.000+02:00

Lino (bzw. igen und dsbe) ist momentan nicht lauffähig, weil die Umstrukturierungen nach der Abtrennung der beiden ersten Anwendungen noch interessante Lawineneffekte hatten. Ich hatte z.B. mal wieder den Effekt, dass Django einen Fehler beim Importieren eines models-Moduls in in manchen Fällen stillschweigend ignoriert und die betreffende Anwendung dann schlicht nicht da ist. Ich habe unter anderem einen Patch geschrieben, damit Django abbricht, wenn ein models-Modul zwar existiert aber auch beim zweiten Versuch nicht importiert werden kann.

Was da noch hapert, habe ich im Issue 40 festgehalten. Das muss jetzt aber ein paar Tage warten.

Detached "lino-dsbe" and "lino-igen" from lino

2009-11-06T18:05:00.000+02:00

I created two new Google projects "lino-dsbe" and "lino-igen", one for each of these two early Lino applications.

Anonymous classes in JavaScript

2009-11-04T17:23:00.002+02:00

I opened issue 39 and worked on it. I won't finish this today, but the new structure of the generated JavaScript code becomes tangible. It will use a JS feature which I'd call "anonymous classes". Here is a snippet I wrote to see whether it is possible. It creates three nested instances of an anonymous class:

<html><head>
<script type="text/javascript">
window.onload = function () {
  var foo = new function() {
    this.bar = 1;
    this.baz = new function() {
      this.bar = 2;
      this.baz = new function() {
        this.bar = 3;
      }();
    }();
  }();
  document.write(foo.bar+" "+foo.baz.bar+" "+foo.baz.baz.bar);
}
</script>
</head><body></body></html>

And yes, it works, it writes "1 2 3" into your document.

An anonymous class is used only once to instantiate a single object, and then we forget their definition because we don't need it any more.
I will use this technique because it will be more straightforward to generate such code.

Luc was in Belgium

2009-11-04T08:59:00.004+02:00

In case you wonder why I didn't post anything for more than 2 weeks: I was in Belgium where I mainly installed a new TIM that will run on a site with about 10 users. TIM, despite its age and oldfashionedness, is still being used and maintained, and is my primary source of income. So don't complain when Lino must sometimes wait because of TIM!

Here is a snapshot made with freshly installed TIM and some of the new users:

But note that Lino wasn't completely asleep. I also had a meeting with the people who are probably going to be the first Lino users of the world:

Enough for know. Today is the first day after my travel where I will probably work on Lino again!

Finally satisfied with logging

2009-10-17T19:45:00.000+03:00

I pushed changeset 825:fabc7a1c89b5 to Google. Now I'm finally satisfied about how Lino uses the standard Python logging module.

In short: Code that runs on a LinoSite can simply import lino_site and use lino_site.log as logger. LinoSite's default logging behaviour is to render the bare messages (without any meta info) to sys.stderr and write complete records (with timestamp, module and level) to a file lino.log. The detailed messages in lino.log don't contain the logger's name (because that would be always the same) but do include the module's name.
If you don't want this behaviour, then just configure yourself the logging module before instantiating LinoSite.
But before I write more about this, let's wait whether my satisfaction stays ;-)

When your Django doctests never fail...

2009-10-15T10:39:00.002+03:00

Grr... don't believe the Django test runner when it claims that your doctests pass! I was eagerly working on issue #1 and wrote a new test application called 20091014, (the lino.test_apps package is a convenient way to write such quick standalone Django tests: I just change INSTALLED_APPS = ( 'lino.test_apps.20091014', ) in my settings.py and then I can do "python manage.py test"). This usually works fine, but now I noticed that after the last changes it says:

Lino version 0.0.1
Creating test database...
Creating table 20091014_a
Creating table 20091014_b
----------------------------------------------------------------------
Ran 0 tests in 0.000s
OK
Destroying test database...

Which means that it actually ignored the whole doctest string, as if there were no test at all. I read here and there about other people who had had similar problems. It still took me some time to discover my mistake. Afterwards I made the following experiment in a file tmp.py:

"""
First test:

>>> 9+2
11

>>> foo() #doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
(...)
NameError: name 'foo' is not defined

"""

if __name__ == '__main__':
import doctest
doctest.testmod()

python tmp.py says nothing, which means that all tests passed. Then I removed one space in front of the word "Traceback". This is in fact the syntax error I had introduced by mistak into my lino.test_app docstring. Here is how Python reacts in such a case:

Traceback (most recent call last):
File "tmp.py", line 16, in
    doctest.testmod()
File "c:\Python25\lib\doctest.py", line 1814, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
File "c:\Python25\lib\doctest.py", line 839, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
File "c:\Python25\lib\doctest.py", line 881, in _find
    test = self._get_test(obj, name, module, globs, source_lines)
File "c:\Python25\lib\doctest.py", line 965, in _get_test
    filename, lineno)
File "c:\Python25\lib\doctest.py", line 594, in get_doctest
    return DocTest(self.get_examples(string, name), globs,
File "c:\Python25\lib\doctest.py", line 608, in get_examples
    return [x for x in self.parse(string, name)
File "c:\Python25\lib\doctest.py", line 570, in parse
    self._parse_example(m, name, lineno)
File "c:\Python25\lib\doctest.py", line 640, in _parse_example
    lineno + len(source_lines))
File "c:\Python25\lib\doctest.py", line 726, in _check_prefix
    (lineno+i+1, name, line))
ValueError: line 8 of the docstring for __main__ has inconsistent leading whitespace: ' Traceback (most recent call last
):'

The Django test runner ignores such docstring syntax errors without any warning.
I'm using today's Django development version (revision 11624).

Django in fact has already a ticket #11436 which reveals that they are waiting for Python issue 1521051 to be fixed... for me that's enough to forgive them.

Wochenende

2009-10-09T22:09:00.000+03:00

Es hat sich diese Woche so viel getan, dass ich mit dem Dokumentieren nicht nachkomme. Ich versuche wenigstens die Tickets à jour zu halten. aber jetzt haben wir erst mal Wochenende.

Noch mehr Fenster

2009-09-30T09:24:00.000+03:00

Hier meine Notizen von gestern vormittag. Erst heute kann ich endlich daran weiter arbeiten. Morgen kommt leider schon wieder eine Unterbrechung, weil ich nach Tallinn muss. Und am Freitag kommen Kristiina und Juta Äpfel pressen, wenn ich Pech habe muss ich ihnen helfen und kann auch dann nicht weiter programmieren. Oje. Aber ich hoffe doch noch, dass ich für Ende Oktober einen zeigbaren Prototypen hinkriege!

Aber zur Sache.

Momentan ist das Detail-Fenster eines Contact so groß, dass es nicht in den Viewport passt.
Ich habs zwar geschafft, dem Viewport Scrollbars zu verpassen (besser gesagt dem Panel in dessen Mitte), aber dadurch scrollen die Windows noch nicht mit. Das ist also keine Lösung.
Sowieso hat es keinen Zweck, eine Art scrollbaren Desktop zu produzieren, sondern die Fenster müssen schon eine sinnvolle Größe haben.

"List" und "Detail" mit einem TabPanel in ein einziges Window zu packen, ist wohl nicht so toll, denn wenn man umschaltet, muss sich ja die Fenstergröße ändern. Tut sie sogar automatisch, aber das ist irritierend. Ich muss wohl besser separate Windows für die beiden machen. Vielleicht sogar bei mehreren Details auch diese jeweils in ein eigenes Fenster.

Bei so vielen Fenstern muss ich ja wohl dafür sorgen, dass man per Tastatur hin und her schalten kann! Oho: die keys property eines panels enthält einen KeyMap. Ich kann also eine Aktion "detail" machen und ihr die Tastenkombination Ctrl+Enter zuweisen. Das funktioniert jetzt für DELETE. Super. ExtJS ist cool!

Jetzt muss ich mir im action framework einen trick ausdenken, um das Detail-Fenster zu öffnen. wahrscheinlich ActionContext.open_window() Und das Layout ist ja jetzt nicht mehr im TabPanel, sondern muss wohl im action handler instanziert werden. Oho, es geht rund...

Working on issue 9. (with Screenshots)

2009-09-25T14:00:00.001+03:00

First results of issue 9 are visible:

Remember how it looked two days ago:

Todo:
- Scrollbars for the ViewPort and the List panel
- load data to Detail panel
- PagingToolbar on Detail panels.
- Generate html response for index() once and serve it statically.

Gedanken zu Ticket #9

2009-09-24T22:11:00.001+03:00

I'm working on issue 9. Here are some of my thoughts.

Die neue Klasse extjs.Window scheint der richtige Weg. Ein extjs.Window instanziert einen self.store (den "master data store") und eine Liste von Layouts (self.layouts). Und kennt natürlich seinen self.report.
extjs.Window wird wahrscheinlich im JS nicht nur ein "new Ext.Window" machen, sondern eine user-defined class machen. Dieser Artikel hier war gut für mich.

Ich bin noch nicht sicher was passieren soll, wenn Layout.create_element() eine slave_grid macht. Der dazu gehörige Store muss vielleicht im Window registriert werden.

Layouts werden nicht mehr in Report, sondern in Window instanziert werden. Und das Fenster, in dem sie stehen (ihren owner) dann alls self.window kennen. Layout braucht dann kein self.report mehr sondern kann stattdessen self.window.report benutzen.

Also jedes mögliche Fenster einer Anwendung kriegt beim Hochfahren des Servers seine Window-Instanz. Und momentan gibt es erstmal genau ein Window pro MenuItem des Hauptmenüs.

Wo werden die RowLayouts von slave reports instanziert?

Und wie soll ich das F11 von TIM implementieren? Also dass man in einem Report eine konfigurierbare Liste von "verwandten" Reports hat, zwischen denen man hin und her schalten kann. Soll dann vielleicht jedesmal ein neues Fenster geöffnet werden? Genau. Das hat hier jezt also nic hts zu sagen.

Gibt es pro Report ein einziges Window? oder mehrere? Wie soll das Umschalten zwischen Vollbild- und Listenansicht gehen?

Vielleicht könnte auch die Grid mit ins TabPanel kommen. Also immer nur ein Layout auf einmal sichtbar. Aber ich muss irgendwie dafür sorgen, dass Stores von SlaveGrids nur dann geloaded werden, wenn ihr Grid auch sichtbar ist. Wenn die master grid nicht immer sichtbar ist, müssen die PageLayouts wieder eine PagingToolbar kriegen. Das wird auch jetzt klappen, wo der Store für beide gemeinsam im Window gespeichert ist.

Viewport wird nur noch für index() benutzt. Das Hauptmenü braucht nicht in den Unterfenstern zu erscheinen, wird also weiterhin nur im Viewport gerendert.

"/" wird die einzige url sein, die noch mit html antwortet.
"/json" antwortet mit json (so wie JsonStore es verlangt).
"/action" antwortet auch in json, aber nicht für JsonStore, sondern ein Objekt mit den properties success, msg, confirm usw. (mein "action framework")

Sollen mehrere Fenster sich einen Store teilen können? Ich glaube nicht.

Der ganze Code aus menus.py kann übrigens bei Gelegnehit (in konvertierter Form) nach extjs.py rüber. MenuItem und Menu wären dann Unterklassen von extjs.Components. Das wäre eleganter. Ist aber nicht dringend.

Wenn ich alles Javascript statisch (d.h. unabhängig vom request) generieren will, müssen die Zugrifffsberechtigungen im Javascript geprüft werden. Das wird noch lustig.

jaama.dyndns.org has done her work

2009-09-23T18:00:00.001+03:00

Oops, the new igen demo server announced 2 days ago was never visible to the outside world. I noticed it yesterday when Gerd tried it. And today, with Dirk's help, I found the probable reason: Elion (my internet provider) blocks these requests. Understandable: they want to be able to sell me more service for more money. I tried with port 1234 and 8080 instead of the well-known 80, but this also doesn't work.

That's not a problem because I've seen what I needed to see: even on a quick server and inside a LAN, the igen application looks too slow. I opened issue 9 and will probably a few intensive days on this.

Updated the old demo site igen.saffre-rumma.ee where you can admire actions mostly working.

New igen demo server is online

2009-09-21T17:15:00.001+03:00

The new igen demo server is online: http://jaama.dyndns.org
Note that this machine won't be always up and running, so if you get no response on that address, then try again later or send me a mail, asking to switch it on.

I also started a Wiki entry about Installation

Preparing a new igen demo server

2009-09-21T14:06:00.000+03:00

I'd like to see igen's performance on a normal Web server. I have a Debian machine here, called Jaama, waiting for this job. The router of my local LAN has a built-in DynDNS client, so I just needed to create a free host account at dyndns.com to get a name for my dynamic IP address.

The only problem is: how to let the router know that it should forward HTTP requests to Jaama?

Jaama was also configured as a DHCP client.

File /etc/networking/interfaces, change the line

iface eth1 inet dhcp

into

iface eth1 inet static
  address 192.168.1.100
  netmask 255.255.255.0
  network 192.168.1.0
  broadcast 192.168.1.255
  gateway 192.168.1.254

  dns-nameservers 194.126.115.18, 194.126.101.34

Result: Jaama's apache2 is now responding on http://jaama.dyndns.org/
Todo: install Lino on Jaama.

Web pages that helped me:
http://wiki.debian.org/NetworkConfiguration
http://www.cyberciti.biz/tips/howto-ubuntu-linux-convert-dhcp-network-configuration-to-static-ip-configuration.html

Grid now editable

2009-09-16T22:11:00.000+03:00

It is now possible to edit data using the Grid. Double-click on a cell to edit it. ForeignKey columns have a combobox. These were quite some hours of work, with some avalanches of internal changes.

To do next:
- make it possible to add rows
- add action buttons e.g. (DocumentsToSend.sign and SalesDocument.print)
- enhance performance

- layout problems
- make use of Ext.Windows rather than a Viewport?

Tuning the grid's columns

2009-09-07T12:25:00.000+03:00

The ColumnModels and Stores generated by Lino had just plain fields so far, relying on the automatic formatting. Now I started to work on this.

BooleanColumn now uses new attribute Report.boolean_texts
DateColumn now uses new attribute Report.date_format
Numeric columns are now displayed right-aligned
MethodElement now displays correctly using the method's 'return_type' attribute

The 'return_type' attribute of a Model's method (which was called 'field' so far, but I thought that it deserves a more complicated name). Is used to specify at model level how a method's return value is to be displayed. Example is sales.SalesDocument.total_incl()

Layout tuning

2009-09-06T00:34:00.001+03:00

Today (or rather yesterday) I worked less than 2 hours on Lino :

1) Activated autoLoad for ForeignKey Store. This increases the server load, but at least it gives a more pleasant impression for people who have a look at igen

2) http://igen.saffre-rumma.ee is, by the way, currently so slow that you may get timeouts. In this case just reload.

3) Solved: The "Emitted Invoices" tab of an Order (http://127.0.0.1:8000/r/OrdersByJournal?master=ORD) did not show the list of emitted invoices. It even had a traceback at the beginning, which I changed into a warning "invoice_set : 'RelatedManager' object is not callable", then modified the PageLayout to solve the problem.

4) The Detail panel in Configuration / Accounts (http://127.0.0.1:8000/r/Accounts) was too small. This was because it uses the default PageLayout, so there was no Element with a width specified. There was also a warning "Could not compute width for PageLayout ledger.PageLayout" printed at the server console. A quick solution would have been to write a PageLayout for the Accounts report, but I want default PageLayouts also get rendered reasonably. But Element.width contains the manually specified width. It is important that this value remains None to indicate this fact, even when it might be computed (e.g. deducing it from the container's width). Remember also that widths specified in Layouts and Reports use always "characters" as unit.So I introduced a new attribute Element.preferred_width which is used at certain places when Element.width is None.

5) todo: after change (4), Detail panel of a Contact is no longer rendered correctly: the display width of text fields with max_length over 15 should get expanded so that they fill up their container's width.

6) todo: BooleanFieldElement has now a get_column_options() wich sets xtype='booleancolumn', but this doesn't have any effect.

Ext.form.ComboBox show value instead of displayField

2009-09-05T00:12:00.003+03:00

ComboBoxes in a Ext.FormPanel sometimes show their value (and not their display_field) after load().

Here is an example (which may change in the future, and if it works it requires you to log in using username "root" and password "1234"):
http://igen.saffre-rumma.ee/r/InvoicesByJournal?master=INV

The ExtJS documentation says "A ComboBox works in a similar manner to a traditional HTML select field. The difference is that to submit the valueField, you must specify a hiddenName to create a hidden input field to hold the value of the valueField. The displayField is shown in the text field which is named according to the name."

In an Invoice entry form I have a ComboBox field to select the customer for this invoice. Configuration options of this field:

name: customer
hiddenName: customerHidden
valueField: id
store: a JsonStore on Customer table with fields:['id','__unicode__']

BasicForm.load() gets the following JSON response:

{"count": 6, "rows": [ {

  "total_incl": "59.85",

"customerHidden": 100,

"customer": "Mets ja Puu O\u00dc",

  (...)

}]}

And the ComboBox then shows "100", not "Mets ja Puu OÜ".
When I then trigger the selection list, it contains correctly all customers, and is positioned on "Mets ja Puu".
Note that triggering the selection list has loaded the choices store.
Once the store is loaded, customer names are displayed correctly, also when I page to other invoices.

This shows that BasicForm.load() ignores the "customer" data, it only reads customerHidden and then asks its store each time.

It would be nice if it did, because then we would gain performance in the situation where a user just skips through invoices, wanting to see the customer names but never triggering the combobox.

Splitting TIM-Tools away from Lino

2009-09-04T21:41:00.000+03:00

The statement "Lino is the common code repository for two relatively non-related projects" can soon go away. I created a new project "timtools" on Google code, then made a clone of Lino ("hg clone lino timtools"), removed a bunch of files from my timtools working copy, did "hg ci", and now am trying to push it back to Google. But since it is a big push, I'm getting:

T:\hgwork\timtools>hg push timtools
pushing to https://luc.saffre:***@timtools.googlecode.com/hg
searching for changes
abort: error: Software caused connection abort

This reminds me issue 2716 which I had when I converted Lino to google.code. Only that now it is not "broken pipe". But let's try a manual version of the solution proposed by by qian.qiao, Jun 14, 2009:

T:\hgwork\timtools>hg push -r 10 timtools
pushing to https://luc.saffre:***@timtools.googlecode.com/hg
searching for changes

... and after about 10 minutes it says "Success.", so Issue 2716 can also appear with "abort: error: Software caused connection abort" instead of "Broken pipe".

Now since I am on Windows, I created a file "push.bat" with one line:

for /L %%i in (50,10,780) do hg push -r %%i timtools

The file is now running:

T:\hgwork\timtools>hg push -r 50 timtools
pushing to https://luc.saffre:***@timtools.googlecode.com/hg
searching for changes
no changes found

T:\hgwork\timtools>hg push -r 60 timtools
pushing to https://luc.saffre:***@timtools.googlecode.com/hg
searching for changes
Success.

T:\hgwork\timtools>hg push -r 70 timtools
pushing to https://luc.saffre:***@timtools.googlecode.com/hg
searching for changes
Success.

Very well. I can now continue on Lino while this is running.