Hi folks,
I also had that problem a few days ago - and before ;-) My simple solution
looks like this:
class vd_oxCategoryList extends vd_oxCategoryList_parent
{
protected function _getSqlSelectFieldsForTree($sTable, $aColumns = null)
{
$sFieldList = parent::_getSqlSelectFieldsForTree($sTable, $aColumns);
$sFieldList .= ", ".$sTable.".oxlongdesc as oxlongdesc";
return $sFieldList;
}
}
This is easy to read and extend, if you need more fields.
Regards, Kai
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Tomas Liubinas
Gesendet: Mittwoch, 23. Januar 2013 16:28
An: [email protected]
Betreff: Re: [oxid-dev-general] Lazy Loading
Hi together!
There are a few aspects regarding this issue. Lazy loading is a technique
ensuring that you load only needed fields instead of loading all the record
information. The field list is cached per Controller. This way for example long
description is not loaded in article lists as long description information is
not used there. It works transparently. There is no need to take care about
this aspect in templates or in the module code. As soon as you use a new field
for example in your templates it is loaded in the following way:
- First of all missing field triggers __get() magic getter.
- The missing field is identified and the value to the object is
retrieved using a separate SQL select.
- The field is registered to field cache and next time it is included
in needed field list and will be retrieved together with other field
information for this Controller (template).
Lazy loading is a generic technique implemented in oxBase class, however it is
turned ON only in oxArticle object by default. Overall its implementation is a
bit complex and there were ideas to get rid of it at all, but for oxArticle and
oxArticleList it is still gives some performance advance.
Original problem was that category tree was not loading some field values.
Without deeper investigation I would say this happens not because of lazy
loading problems, but because oxCategoryList::_getSqlSelectFieldsForTree()
method has hardcoded list of select fields. So in order to have extended
information in the tree, this method should be extended to additionally include
icon field value.
You mentioned there is a way to fix this problem by lazy loading setting
manipulation. I guess that would work, but it must be not performance optimal.
When you turn lazy laoding ON then initially the list would be loaded with
missing field information and additional fields are loaded by lazy loading
technique, but only on __get() magic getter. If it works like this I am happy
lazy loading is robust enough to retrieve this information, but as I said this
is not recommended way to do that. As I said I would recommend playing with
oxCategoryList::_getSqlSelectFieldsForTree() field list :)
Regards
Tomas Liubinas
From: [email protected]
[mailto:[email protected]] On Behalf Of Michael Zender
Sent: Wednesday, January 23, 2013 3:12 PM
To: [email protected]
Subject: Re: [oxid-dev-general] Lazy Loading
Hi Tim,
Thanks a lot, disabling the field caching for the respective class solved my
problem. It seems to result in an additional cache file being created for the
respective object and every view that uses this object (e.g.
oxeec_fieldnames_oxcategories_start_i18n.txt). In the cache file all the fields
are mentioned that are used to render the respective view.
I still don’t understand, why lazy loading was implemented this way and why I
have to disable caching to produce additional cache files that result in
another feature working. In my opinion, lazy loading could be implemented
non-optional, with a set of default fields for each db object. Every additional
field gets loaded on demand. Additionally, this could be optimized the way it
seems to be using a cache file that stores all the fields in addition to the
default ones that should be loaded when a certain view is rendered.
Maybe one of the core devs could say a word or two on this topic and whether
this could be considered a bug in the implementation or just a small design
flaw.
Thanks a lot for your help!
Best regards
Dipl.-Ing. (FH) Michael Zender
Development eCommerce
Technical Project Lead
MOS-TANGRAM AG
Wohlerstrasse 2
CH-5623 Boswil
Phone: +41 (0)56 677 82 20
Fax: +41 (0)56 677 82 99
E-Mail: <mailto:[email protected]> [email protected]
Internet: <http://www.mos-tangarm.com/> http://www.mos-tangram.com
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Tim Aniol
Gesendet: Mittwoch, 23. Januar 2013 12:00
An: [email protected]
Betreff: Re: [oxid-dev-general] Lazy Loading
Hi Michael,
we ran into the same problem with oxcategory and category descriptions for
sub-categories. This code snippet works fine for us:
/**
* Module smx_oxcategory
* Activate lazyloading to get custom db fields
*/
public function __construct()
{
$this->_blUseLazyLoading = true;
self::$_blDisableFieldCaching[get_class($this)] = true;
parent::__construct();
}
Mit freundlichen Grüßen
Tim Aniol
Softwareentwickler
*************************************
shoptimax GmbH
Guntherstraße 45a
90461 Nürnberg
Tel (09 11) 2 55 66 - 10
Fax (09 11) 2 55 66 - 29
eMail <mailto:[email protected]> [email protected]
Web <http://www.shoptimax.de> www.shoptimax.de
*************************************
Geschäftsführung: Friedrich Schreieck
Ust.-IdNr.: DE 814340642
Amtsgericht Nürnberg HRB 21703
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Michael Zender
Gesendet: Mittwoch, 23. Januar 2013 11:55
An: <mailto:[email protected]> [email protected]
Betreff: Re: [oxid-dev-general] Lazy Loading
Hi Björn,
Thank you for your quick answer!!
I already tried, what you suggested. Sorry, I did not mention that in my
original E-Mail.
I created a module for oxCategory and set oxCategory::$_blUseLazyLoading to
true in the overridden init() method. Unfortunately, this does not seem to have
any effect on my problem.
Best regards
Dipl.-Ing. (FH) Michael Zender
Development eCommerce
Technical Project Lead
MOS-TANGRAM AG
Wohlerstrasse 2
CH-5623 Boswil
Phone: +41 (0)56 677 82 20
Fax: +41 (0)56 677 82 99
E-Mail: <mailto:[email protected]> [email protected]
Internet: <http://www.mos-tangarm.com/> http://www.mos-tangram.com
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Lange, Björn
Gesendet: Mittwoch, 23. Januar 2013 11:40
An: [email protected]
Betreff: Re: [oxid-dev-general] Lazy Loading
Hi Michael,
2013/1/23 Michael Zender <[email protected]>
I investigated this issue a little further and discovered, that the
$oxcmp_categories object is constructed using the method
oxCategoryList::buildTree() which does NOT load the oxpromoicon field for very
category. BUT, as far as my understanding of lazy loading goes, the respective
field should be loaded automatically, when it is accessed, but not already
loaded.
I would use a module till now for this use case.
I hope someone can elaborate a little bit on this topic, how the lazy loading
feature in OXID works and how one has to use it. Also, for a scenario like
mine, what would be the best practice to get the URL I’m interested in.
Lazy Loading works through the magical getter in the oxbase class. If the
property $this->_blUseLazyLoading is true and the requested field is a table
field of the objects core table, the value is loaded (either from the cache or
the database). Take a look into oxarticle. _blUseLazyLoading is true by
default. But in oxcategory, it is false by default. Try to change the value and
i think (without further tests), it should work.
Regards,
Björn
--
_________________________________
WBL Konzept GmbH
Björn Simon Lange
Geschäftsführender Gesellschafter
Bilker Straße 34
40213 Düsseldorf
Telefon: 0211 942 120 31 | Fax: 0211 942 120 32
<http://www.wbl-konzept.de/> www.wbl-konzept.de |
<http://www.facebook.com/wbl.konzept> www.facebook.com/wbl.konzept |
<mailto:[email protected]> [email protected]
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
