Wanted: a product list created with the Admin Generator that allows for (1) sorting by name for both languages and (2) filtering by name. The final outcome should look and work like this:

(1) For the sorting:

generator.yml:

The Admin Generator should treat the i18n fields as if they were normal columns of the table. Specifically, they should be listed. For the columns to appear, a dedicated doSelectJoinTranslation table_method is needed as shown in the subsequent ProductTable.class.php.

config:
fields:
sortnamede: { is_real: true }
sortnamezh: { is_real: true }
list: display: [=sortnamede, =sortnamezh, eancode]
table_method: doSelectJoinTranslation

ProductTable.class.php:

The translation joins should happen without changing the result. When adding left joins in conjunction with "WHERE" on these joins, they become inner joins, not showing all rows of Product that do not yet have an i18n name given. To overcome this, the language selection goes into the join predicate. Furthermore, the selected names are given aliases (sortnamede, sortnamezh) as previously used in generator.yml.

public static function doSelectJoinTranslation($query) {
$rootAlias = $query->getRootAlias();
return $query->select($rootAlias.'.*, t.name as sortnamede, u.name as sortnamezh')
->leftJoin($rootAlias.'.Translation t ON ((t.lang = \'de\') AND t.id='.$rootAlias.'.id)')
->leftJoin($rootAlias.'.Translation u ON ((u.lang = \'zh\') AND u.id='.$rootAlias.'.id)');
}

actions.class.php:

The action allows for adding functionality to the default one. First, the valid sort columns are extended by the two "virtual" ones. Second, a sort query is added. Depending on the column to be sorted, it chooses for either the german translation "t" (as stated in the previous doSelectJoinTranslation) or "u" for the chinese one:

class productActions extends autoProductActions
{
protected function isValidSortColumn($column) {
return parent::isValidSortColumn($column) || $column == 'sortnamede' || $column == 'sortnamezh';
}
protected function addSortQuery($query) {
if (array(null, null) == ($sort = $this->getSort())) {
return;
}

if (!in_array(strtolower($sort[1]), array('asc', 'desc'))) {
$sort[1] = 'asc';
}

switch ($sort[0]) {
case 'sortnamede':
$sort[0] = 't.name';
break;
case 'sortnamezh':
$sort[0] = 'u.name';
break;
}
$query->addOrderBy($sort[0] . ' ' . $sort[1]);
}
[...]

(2) For the filtering:

ProductFormFilter.class.php:

First, there has to be added a "name" field, which is not included by default for i18n columns. Second, there has to be added a dedicated query for the search of the name. In order not to conflict with the other table aliases used above, there has to be chosen a new one ("s" in this example) for this purpose.

class ProductFormFilter extends BaseProductFormFilter
{
public function configure()
{
$this->widgetSchema['name']     = new sfWidgetFormFilterInput(array('with_empty' => false));
$this->validatorSchema['name']  = new sfValidatorPass(array('required' => false));
}
public function addNameColumnQuery(Doctrine_Query $query, $field, $values)
{
if (is_array($values) && isset($values['text']) && '' != $values['text'])
{
$query->leftJoin('r.Translation s')
->andWhere('s.name like ?', '%' . $values['text'] . '%');
}
}
}

That's it.

[?php /** * Project filter form base class. * * @package aaa  * @subpackage filter * @author Your name here * @version SVN: $Id: sfDoctrineFormFilterBaseTemplate.php 23810 2009-11-12 11:07:44Z Kris.Wallsmith $ */ abstract class BaseFormFilterDoctrine extends sfFormFilterDoctrine { public function setup() { } }
Fatal error: Class 'BaseFormFilterDoctrine' not found in /srv/vhosts/aaa/www/lib/filter/doctrine/base/BaseStockFormFilter.class.php on line 11

I googled it, but did not find a working solution. The start of the error "[?php" is a hint: it is not a regular php file the autoloader tried to include here. And it is not the BaseFormFilterDoctrine.class.php either, because it contains my name instead of "Your name here". It's a template file either from plugins/sfDoctrineGuardPlugin or from the kernel.

Hence, the autoloader has a hickup that only occurs in the presence of the php configuration on the production server. It can be solved by hacking the symfony kernel. I added "template, test" to the exclude entry of /lib/vendor/symfony/lib/config/config/autoload.yml - and voila, symfony loads the correct BaseFormFilterDoctrine.

Eigentlich sollten wir am Flughafen Shanghai-Pudong landen, der mit dem Transrapid mit Shanghai verbunden ist. Beim Landeanflug kam die Durchsage, dass wir heute ausnahmsweise an einem anderen Flughafen landen. Wenn man was erleben will, nehme man diese Airline. ;-)

Elektronische Rechnungen finde ich am einfachsten. Ich habe sie immer gerne mit auf dem Notebook dabei, falls es Rückfragen gibt. Das zeit- und atemraubende Ordnerwuchten entfällt. Papier ist unpraktisch.

Dieser Lieferant bevorzugte es bislang als einziger, die Rechnung per Post der Lieferung hinterherzuschicken. Mutmaßlich ausgedruckt von einem EDV-System. Immerhin. Es hätte ja auch eine handgeschriebene Papyrusrolle separat angeliefert per Pferdekutsche sein können.

Der Lieferant bittet nun um die Erlaubnis für den elektronischen Rechnungsweg per ... Fax.  Ich meine, ich verstehe den Hintergrund - irgendwelche Gerichte haben mal beschlossen, dass Faxe eine gewisse Verbindlichkeit haben (auch wenn das technisch völliger Humbug ist) - aber trotzdem find ichs skurril. Der Aufwand, jetzt aus Japan oder China ein Fax zu schicken (erstmal eins finden!), übersteigt meine Vorstellungskraft. Mal gespannt, ob sie eine Bestätigung per E-Mail akzeptieren. Sie können sie ja ausdrucken.