Support archive

Grid fields not parsing early when early parsing enabled

dpdexter 16 Sep 2014 18:49 problem, rejected

Hey Low,

I'm passing output of a LV Grid field to the brilliant_retail:js method, but the grid field does not actually appear to be parsed early. It is passed to exp:brilliant_retail:js and removed from the template data. If the data stays in the template it eventually does get parsed. Resulting in the template tags being output in the javascript source.

I'm guessing this => Low Variables: Calling Low_grid::display_output() handles the actual grid parsing.

Template Debugger:

0.000010/5.2MB) - - Begin Template Processing -
(0.000036/5.2MB) - URI: create/anto/dress
(0.000047/5.2MB) - Path.php Template: /
(0.000060/5.2MB) - Retrieving Template
(0.000070/5.2MB) - Parsing Template URI
(0.003305/5.29MB) - Template Group Found: create
(0.003852/5.3MB) - Retrieving Template from Database: create/anto
(0.004565/5.3MB) - Template Found
(0.004654/5.31MB) - Retrieving Template from File
(0.008716/5.58MB) - Calling Extension Class/Method: Low_variables_ext/template_fetch_template
(0.011922/5.64MB) - Calling Extension Class/Method: Ce_cache_ext/template_pre_parse
(0.012231/5.61MB) - Template Type: webpage
(0.012258/5.61MB) - Parsing Site Variables
(0.012700/5.62MB) - Snippets (Keys): lv_price_classic|lv_price_dress|lv_price_sport|lv_adjust_collar|lv_adjust_cuff|lv_adjust_bib|lv_adjust_fly_front|lv_adjust_front_fabric|lv_adjust_pocket_two|lv_adjust_pocket_flap_one|lv_adjust_pocket_flap_two|lv_adjust_pocket_contrast|lv_adjust_sleeve_placket|lv_adjust_epaulette|lv_adjust_epaulette_contrast|lv_adjust_button_3mm|lv_adjust_button_4mm|lv_adjust_monogram_letter|logged_in_member_id|logged_in_group_id|logged_in_group_description|logged_in_username|logged_in_screen_name|logged_in_email|logged_in_ip_address|logged_in_location|logged_in_total_entries|logged_in_total_comments|logged_in_private_messages|logged_in_total_forum_posts|logged_in_total_forum_topics|global:env|global:env_full|cdn_url|gv_allow_checkout|freelancer_version|csm:action|csm:error|br_payment_layout|br_price_html|br_sale_price_html|br_shipping_layout|br_system_alert|br_system_message|sn_out_of_stock_message|site_id|site_label|site_short_name|last_segment|current_url|current_path|current_query_string|is_core
(0.012729/5.62MB) - Snippets (Values): |||20|20|100|15|15|5|7.50|15|5|5|5|5|5|10|4|1|1||david@codesly.com|David Dexter|david@codesly.com|127.0.0.1||1246|0|0|0|0|local|Local||y|FALSE||| {gateway_label} {if "{has_form}"} {gateway_form} {/if} |{price}| {price} {sale_price}

|

{shipping_label} {if '{shipping_label}' != '' && '{shipping_label}' != 'Free Shipping'} {/if} {rates}
• - {if '{rate}' != ''} {rate} - {/if} {rate_label}
{/rates}

Replies

1. Low 16 Sep 2014 18:56

   Having early parsing enabled/disabled only applies to vars in variable syntax. If you're using tag syntax, which you need to do when outputting Grid/Matrix vars, early parsing is irrelevant; they're tags, so parsed as tags. Before late parsed vars, after early parsed vars.
   
   If the brilliant_retail:js tag removes exp-tags from itself, and then puts it back, but with the curly braces encoded, then there's not a lot LV can do.
   
   Is that what's the case here?

2. dpdexter 16 Sep 2014 19:10

   I figured. So the long and short answer is that LV doen't actually early parse grid fields.

3. Low 16 Sep 2014 19:15

   That's one way of looking at it. Inevitable with EE's template engine, really.

4. dpdexter 16 Sep 2014 19:16

   Thanks Low.

5. dpdexter 16 Sep 2014 21:10

   In the very rare case that anyone stumbles upon this again I wanted to mention we added a config variable to the exp:brilliant_retail:js tag that allows for late template parsing. The js method will get the raw tag data (as expected) but run the final stored data through an instance of the parser and whala... works.
   
   $config["br_parse_js"] = 'y';
   
   Does the trick in BR 2.7.1+
   
   Thanks...