[Erp5-dev] error on wiki page, pls check

[Bartek Gorny]

Hi

Can somebody please check the wiki page that I wrote two days ago, on
HowToAddTableToCatalog? I figured out that what I wrote there is
wrong, because the z_catalog_email_list is called every time I reindex
any object, which throws an exception if it the object is not an email
address. So I guess there must be a way to specify which catalog
methods are called when reindexing certain portal_types, or something
like that, but I don't know how.

Bartek

[Jérôme Perrin]

Post by Bartek Gorny
Hi
Can somebody please check the wiki page that I wrote two days ago, on
HowToAddTableToCatalog? I figured out that what I wrote there is
wrong, because the z_catalog_email_list is called every time I reindex
any object, which throws an exception if it the object is not an email
address. So I guess there must be a way to specify which catalog
methods are called when reindexing certain portal_types, or something
like that, but I don't know how.

Hi bartek

Currently, in various catalog method (stock, movement, item ...) we check
wether we should index the object in the method.
For exemple, z_catalog_movement_list first check the list of objects that are
actually movement (using isMovement attribute) and only catalog them if the
attribute is true.
So in your case, you can just filter the list of objects, using for example
getPortalType.

But this may still fail for empty emails, you have use "optional" attribute to
dtml-sqlvar so that it doesn't complain with None values.

- <dtml-sqlvar expr="getUrlString[loop_item]" type="string">
+ <dtml-sqlvar expr="getUrlString[loop_item]" type="string" optional>

Another solution can be cataloging objects only if getUrlString is not None.

[Bartek Gorny]

Thx - it works. I corrected the wiki.

It works ok for empty emails too, even without the 'optional' attribute.

Bartek

Post by Jérôme Perrin

Post by Bartek Gorny
Hi
Can somebody please check the wiki page that I wrote two days ago, on
HowToAddTableToCatalog? I figured out that what I wrote there is
wrong, because the z_catalog_email_list is called every time I reindex
any object, which throws an exception if it the object is not an email
address. So I guess there must be a way to specify which catalog
methods are called when reindexing certain portal_types, or something
like that, but I don't know how.

Hi bartek
Currently, in various catalog method (stock, movement, item ...) we check
wether we should index the object in the method.
For exemple, z_catalog_movement_list first check the list of objects that are
actually movement (using isMovement attribute) and only catalog them if the
attribute is true.
So in your case, you can just filter the list of objects, using for example
getPortalType.
But this may still fail for empty emails, you have use "optional" attribute to
dtml-sqlvar so that it doesn't complain with None values.
- <dtml-sqlvar expr="getUrlString[loop_item]" type="string">
+ <dtml-sqlvar expr="getUrlString[loop_item]" type="string" optional>
Another solution can be cataloging objects only if getUrlString is not None.
--
J?rome

[Jérôme Perrin]

Post by Bartek Gorny
It works ok for empty emails too, even without the 'optional' attribute.

It depends on the meaning of 'empty' ;)
If you set an empty value through the standard user interface, the value is
set to an empty string "", which works without 'optional', but if the value
has never been set, then url_string property defaults to None (as no
"default" is set in the property sheet), which requires 'optional' attribute.

[Yoshinori Okuji]

Post by Jérôme Perrin

Post by Bartek Gorny
Can somebody please check the wiki page that I wrote two days ago, on
HowToAddTableToCatalog? I figured out that what I wrote there is
wrong, because the z_catalog_email_list is called every time I reindex
any object, which throws an exception if it the object is not an email
address. So I guess there must be a way to specify which catalog
methods are called when reindexing certain portal_types, or something
like that, but I don't know how.

Hi bartek
Currently, in various catalog method (stock, movement, item ...) we check
wether we should index the object in the method.
For exemple, z_catalog_movement_list first check the list of objects that
are actually movement (using isMovement attribute) and only catalog them if
the attribute is true.
So in your case, you can just filter the list of objects, using for example
getPortalType.

Not completely true. The filtering in each catalog method is mostly for
"safety guard" against wrong settings. The right way to filter objects is to
use the filtering feature in SQLCatalog itself. Just go to the tab Filter,
and set whatever you need. You can filter objects based on portal types
and/or TALES expressions.

The reason why this is better is the performance: if you filter objects in
methods, the arguments are always parsed for all objects, even when they are
filtered out. If you filter objects in the filtering feature, the arguments
are not parsed for objects not being catalogged. This performance penalty
might be negligible in the case of email, because the data is simple, but it
is still a good idea to avoid such an unneeded overhead.

YO