IgorRastarov

фронт: выглядит красивее, можно делать анимацию. Если калькулятор "продающий" то однозначно на фронте.
бэк: проще в реализации и его проще масштабировать и закладывать в него сложную логику, но от него будет нести нафталином. Ещё один довод за бэк - если при работе калькулятора понадобится активное взаимодействие с erp компании.

<?
$IBLOCK_ID    = 5;
$arFilter    = Array(
      'IBLOCK_ID'=>$IBLOCK_ID, 
      'ACTIVE'=>'Y',
    'DEPTH_LEVEL' => 3,
    );
$rsResult = CIBlockSection::GetTreeList($arFilter);

while($arSection = $rsResult->GetNext()){
   $arResult["ID"][] = $arSection;
}
?>
            <?foreach ($arResult["ID"] as $hi) {?>
         <? print_r($hi); ?> //не работает
             <?}?>

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде ( сортировка, текущая страница в блоге, строка поиска и т.п. ).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта ( логины, пароли, номера кредиток, сообщения и т.п. ).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

Через pdomenu сделал так:

[[pdoMenu?
  &parents=`родитель`
  &tplOuter=`@INLINE <ul class="list">[[+wrapper]]</ul>`
  &tpl=`menuParse`
]]

где menuParse

[[+link:is=`[[*uri]]`:then=`<li><span>[[+menutitle]]</span></li>`:else=`<li><a href="[[+link]]">[[+menutitle]]</a></li>`]]

Скорее всего проблема в том, что у Вас в обработчике нет поля EMAIL_TO, а в почтовом шаблоне, скорее всего есть. Я тоже недавно столкнулся с похожей проблемой. Я не использовал никаких стандартных компонент битрикс. Обычная html форма. Вот мой код, может Вам поможет.

CModule::IncludeModule('iblock');
$arSelect = Array("NAME", "ID", "PROPERTY_IMAGE");
$arFilter = Array("IBLOCK_ID"=>15, "ACTIVE"=>"Y");
$res = CIBlockElement::GetList(Array(), $arFilter, false, Array(), $arSelect);
while($ob = $res->GetNextElement())
{
    $arFields = $ob->GetFields();
  if (!empty($arFields['PROPERTY_IMAGE_VALUE'])){	
    $arEventField = array(  
      "EMAIL_TO" => $_POST['email'],// - здесь email - это <input type="email" name="email" placeholder="E-mail" value="" required>
      "TEXT" => $_POST['textarea'],// - здесь textarea - это <input type="text" name="textarea" placeholder="Текст сообщения" value="">
    ); 
      $image=CFile::GetPath($arFields['PROPERTY_IMAGE_VALUE']);
    CEvent::Send("IMAGE_FEEDBACK", 's1', $arEventField,'Y',8,array(CFile::GetPath($arFields['PROPERTY_IMAGE_VALUE'])));
  }
}

Поля EMAIL_TO и TEXT - есть в моем почтовом шаблоне под номером 8 и с названием IMAGE_FEEDBACK