=================================
20130826 (Monday, 26 August 2013)
=================================

Lino's current default template for writing sales invoices isn't really
beautiful. I started to work on a new one.

The new `Invoice.odt` is based on the existing `Letter.odt` for :mod:`lino_welfare`.

First I renamed
`get_letter_margin_html`
:meth:`get_letter_margin_bottom_html <lino.ui.Site.get_letter_margin_bottom_html>`
and added a new method
:meth:`get_letter_margin_top_html <lino.ui.Site.get_letter_margin_top_html>`

Already the first line arises questions:
where and how to specify the date of a letter.

Specifying the city in the date of a letter
-------------------------------------------

It seems that at least in Europe it is common to add the sending *place*
to the sending *date*:

- de: "Eupen, den 26. August 2013" or "Eupen, 26. August 2013"
- fr: Eupen, le 26 août 2013
- en_US: Eupen, August 26, 2013
- en_BR: Eupen, 26 August 2013

So in  `Invoice.odt` I specify::

  [sc.site_company.city.name], [tr("",de="den",fr="le")] [dtos(self.date)]

Which required a new optional positional argument for
:func:`north.dbutils.babelitem` to specify a default value which doesn't
depend on the database's default language.

But oops, in Spanish they say "En Madrid, a 21 de enero de 2010"
(found `here <http://forum.wordreference.com/showthread.php?t=1675033>`_).
It seems that `python-babel
<http://babel.pocoo.org/docs/dates/>`_
doesn't worry about the problem.

More research:

- Thread: `city + date in a formal letter <http://forum.wordreference.com/showthread.php?t=1675033>`_
- `How to Format a US Business Letter <http://www.dailywritingtips.com/how-to-format-a-us-business-letter/>`_
  by Ali Hale

- `Date in a Business Letter <http://www.ego4u.com/en/business-english/communication/business-letter/date>`_

- `Stadt, den Datum?!?!.. oder nur Stadt, Datum??
  <http://www.gutefrage.net/frage/stadt-den-datum-oder-nur-stadt-datum>`_


Shortcut functions for date formatting
--------------------------------------

Until now I used the
following short-named functions when inserting dates into document
templates::

  dtos   26.08.2013
  dtosl  Montag, 26.08.2013
  dtomy  August 2013

Where "l" stands for "long".

But `python-babel
<http://babel.pocoo.org/docs/dates/>`_
differentiates between "long" and "full", and my "long" corresponds to
their "full".

To solve these naming clashes and still remain backwards compatible,
I declare these functions obsolete and define a new series of
short-named date formatting functions::

  fds(d) --> 26.08.2013
  fdm(d) --> 26. Aug 2013
  fdl(d) --> 26. August 2013
  fdf(d) --> Montag, 26. August 2013



Missing commas in :xfile:`linoweb.js`
--------------------------------------

Bug fixed:
IE doesn't like JavaScript
expressions containing uselessly trailing commas
(as e.g. in `var obj = { a:1, }`).
This kind of typo in JS generated by Lino
often passes undiscovered because I don't use that browser.
But Joe's users now noted such a comma and he fixed it and sent me a patch::

    Following is small fix, that fixes compatibility with IE10
    (otherwise compatibility mode is required and there are some UI glitches
    in compat mode)

    --- a/lino/extjs/linoweb.js     Sat Aug 24 03:43:43 2013 +0300
    +++ b/lino/extjs/linoweb.js     Mon Aug 26 01:54:17 2013 +0200
    @@ -1160,7 +1160,7 @@
       });
     Lino.DateTimeField = Ext.extend(Ext.ux.form.DateTime,{
       dateFormat: '{{settings.SITE.date_format_extjs}}',
    -  timeFormat: '{{settings.SITE.time_format_extjs}}',
    +  timeFormat: '{{settings.SITE.time_format_extjs}}'
       //~ hiddenFormat: '{{settings.SITE.date_format_extjs}} {{settings.SITE.time_format_extjs}}'
       });
     Lino.URLField = Ext.extend(Ext.form.TriggerField,{

Thank you, Joe. I applied your fix to trunk.

Yes, when there will be more contributors, then Lino will definitively
need a code repository with pull requests for this kind
of contribution.





'ExtUI' object has no attribute 'build_site_cache'
--------------------------------------------------

Bug fixed:
The :class:`modlib.system.models.BuildSiteCache` action didn't work.
It caused a server exception 'ExtUI' object has no attribute
'build_site_cache'.



Github or Gitorious?
--------------------

Today I discovered the `Why is Github more popular than Gitorious?
<https://stackoverflow.com/questions/78991/why-is-github-more-popular-than-gitorious>`_
question on stackoverflow
which has been "closed as not constructive".
I didn't read half of the comments, especially also because
it is probably obsolete.

But yes... the decision "Github or Gitorious?" seems to depend on the
religious question about whether software should be free (of commercial
interest) or not.
If I had do decide right now,  than I'd probably toss a coin...


Formatting `None` values
------------------------

The :meth:`format_value <lino.ui.store.StoreField.format_value>`
method of
:class:`lino.ui.store.StoreField.RequestStoreField`
failed on `None` value.
That's another complex question: who should handle `None` values`,
the formatter
(i.e. :meth:`format_value <lino.ui.store.StoreField.format_value>`)
or the callers
(i.e. :meth:`row2list <lino.ui.store.Store.row2list>` & Co?).
Let's leave this job to the formatters because it is easier
to implement.


The ``dump2py`` django-admin command
------------------------------------

Until now there was at least one limit for :mod:`north`:
it had to fail on huge databases.
We didn't yet reach that limit, but Murphy's law states that
it will happen one day.

This limit exists "by nature", because
Django's serializer concept means that a dump creates exactly
*one* file, and because Python must load a module into memory before
compiling and executing it.

The good news is: it took only a few hours to remove that limit.
I wrote a :term:`django-admin command`
:mod:`north.management.commands.dump2py`
and I split the :class:`north.dpy.Deserializer`
into a "Loader".

The bad news is: I'll need to update quite some documentation.
But in summary:

To make a python dump (be it for daily backup or before a migration)
we no longer recommend to say::

  $ python manage.py dumpdata --format py > mydump.py

It is now better to say::

  $ python manage.py mydump

This will create a python dump of your database to the directory `mydump`.
The directory will contain one file :file:`main.py` and a lot of other `.py`
files (currently one for every model) which are being :meth:`execfile`\ d
from that :file:`main.py`.

To restore such a dump to your database, simply issue::

  $ python mydump/main.py