Forums / General / TemplateCompile enabled and attributes disappear

TemplateCompile enabled and attributes disappear

Author Message

Heath

Sunday 01 July 2007 10:35:50 am

<b>Long Title</b>

TemplateCompile setting enabled and attribute_view_gui attributes disappear!

<b>Summary</b>

Merely in writing this one detailed document, which would accurately present the problem both in text, screenshot, settings, supporting url; I found I had found a pattern in describing the problem which matched the output surrounding my use of a feature which I was not certain was completely supported ('{attribute_view_gui attribute=$node.object.data_map.$a}').

When you have to pay for support, I always recommend one communicate clearly in the first email. This drastically improves the context and speed of email support.

<b>Problem Description</b>

In the interest of prompt development of new features the following was added to the settings of this build. These settings have been known to disable as completely as possible all available cache systems (while it does appear to work very well there may be further settings which can disable further cache sub systems as of yet unknown).

File: <i>settings/override/site.ini.append.php</i>

<b>Contents Added</b>

[ContentSettings]
ViewCaching=disabled

[TemplateSettings]
TemplateCache=disabled
TemplateCompile=disabled
DevelopmentMode=disabled
DevelopmentMode=enabled
CacheThreshold=0

<b>Error Description</b>

If I turn off all of these settings (remove them) now that development is completed I get a rather nasty artifact. The attributes of the form would disappear!

The Templates with the error were the feedback form's datatype attributes (not all but most..)
Attributes of a form dynamically called from an array here is an example. The following ...

{def $attribs=array('accept_cc','need_equip','monthly_charges','average_charge','likely_method')}
{foreach $attribs as $a}<div>{attribute_view_gui attribute=$node.object.data_map.$a}</div>{/foreach}

<b>Solution Description</b>

Replace the direct calling of the name in the previous example with another way of doing the same act.

{foreach $attribs as $a}<div>{def $a_name=$node.object.data_map.$a}{attribute_view_gui attribute=$a_name}</div>{/foreach}

I might note that only the ezstring datatype was not affected by this 'negative feature' all other datatypes were affected by this problem.

<b>Conclusion</b>

I started this process to solve this problem first by writing an email to a fictional support provider. I quickly found that after less than 5 minutes of writing a single complete (very verbose) supporting text document I had found my own solution.

Now my problem is solved, hope this helps someone else, time for a free beer!

Cheers!

Brookins Consulting | http://brookinsconsulting.com/
Certified | http://auth.ez.no/certification/verify/380350
Solutions | http://projects.ez.no/users/community/brookins_consulting
eZpedia community documentation project | http://ezpedia.org

Xavier Dutoit

Monday 02 July 2007 3:14:19 am

Hi,

I noticed that node.data_map works(ed) better than node.object.data_map on some cases, even if the data_map logically belongs to the object.

X+

http://www.sydesy.com