Где есть описание массива $arResult в битрикс для системных компонентов?

Question

[Леонид Корсаков]

Системных компонентов много. Документация мрак. Есть где-нибудь описание ячеек выходного массива $arResult для основных (хотя бы) системных компонентов? Например элемент каталога детально. Особенно то, что касается работы с компонентами для интернет магазинов.

UPD: Похоже ответ напрашивается сам - нигде

Comments

[Егор Болгов]

В форумах битрикса и в курсах они сами пишут - "Всё в исходных кодах. Читайте код компонентов" :) Тупо надрачиваться надо, потом запомнишь. Часть не поймёшь вообще никогда.

Answer 1

[asdz]

Нет, и это на мой взгляд очень плохо, битрикс же вроде как MVC (как они сами говорят), а какая модель (arResult) передается в представление (шаблон) не декларируется. Нужно выяснять опытным путем для каждого компонента и иногда для каждого конкретного шаблона и желательно в отладчике, а с не print_r. Могу вас утешить, простые компоненты и шаблоны не настолько сложны чтобы сложно было понять что в них происходит, со временем привыкнете к битриксу - да, он такой.

Comments

[Леонид Корсаков]

Я давно к нему привык, каждый раз сталкиваюсь с плохой документацией. Думал может я что-то не знаю где она находится

[Евгений]

Нахрена вы ребята к нему привыкаете? Не я понимаю... руководство там хочет его продавать и т д, но неужели не устроиться в другую фирму? Ну вот смотрю я и вижу кучу вакансий и по php фреймворками и по js фреймворкам. И зарплаты там побольше чем у "разработчиков на битрикс". В чем проблема то работу сменить и заниматься нормальным программированием, а не мучениями с arResult?

Answer 2

[flutter_shy]

через print_r() посмотрите, это будет лучшее описание.

Comments

[Леонид Корсаков]

увы нет, далеко не лучшее

[flutter_shy]

А с чем возникли проблемы? Обычно в $arResult в шаблон приходит просто информация об элементах. Если это элемент каталога детально, то это все поля, которые есть у этого элемента, все созданные свойства попадут в $arResult['PROPERTIES'] и некоторая служебная информация вроде даты создания, сортировки и т.д. Если говорить о списке элементов, то те же данные об элементах, только сразу о нескольких.

[asdz]

ахахаха, в шаблоне комплексного компонента каталог попробуйте разобраться таким способом

Answer 3

[Максим Морозов]

Содержимое этого массива зависит от многих факторов. Для разных настроек компонента и разных настроек модуля будут разные массивы (со схожей структурой) Описывать все вариации не имеет смысла.

Самый лучший вариант - просмотреть что пришло в файл шаблона (template.php) через print_r:

?><pre><? print_r() ?></pre><?

Comments

[Леонид Корсаков]

Описывать есть смысл! Потому что документация наше всё. Есть специфические ячейки массива. Я не знаю что в них лежит, а данные эти туда сюда гоняются в итоге изобретаешь свой велосипед. Нужно пользоваться тем, что есть, но к нему нет описания. Я не нашел. Я знаю что можно вывести на экран содержимое. Я знаю, что за данные в часто используемых ячеках. Но не во всех.

[Rad1calDreamer]

Леонид Корсаков: откройте код компонента и посмотрите если уж совсем сильно надо

[Максим Морозов]

Леонид Корсаков: как уже выше написали - кода компонента вполне достаточно чтобы понять что находится в любом элементе массива.

[Леонид Корсаков]

Спасибо за капитанские решения=) хорошо, что свой двиг писать не советуете

Answer 4

[Алексей Емельянов]

Задокументировать все $arResult'ы всех компонентов нереально, для этого нужно нанять несчётную орду орков.

Проще посмотреть что приходит в резалте.
Для удобства анализа $arResult есть функция pre_0.2.1.php

<?
    pre($arResult);
?>

Comments

[Леонид Корсаков]

то, что я увижу структуру этого массива не решает проблемы не знания точного предназначения ячеек массива. На счет нереально задокументировать, я считаю что можно было описать основные компоненты. Но вообще говоря зачем нужен такой монстроносный платный продукт, если разработчикам лень к нему доки писать.

[Алексей Емельянов]

Леонид Корсаков: скорость написания документации - ниже скорости написания кода, Всегда перед разработчиками стоит сложный выбор - начать писать новый функционал или писать документацию к уже существующему коду.

[Евгений]

Алексей Емельянов: Это все потому что в данном "продукте" говноархитектура. Если нормально писать код, то автодокументор 80% комментариев по методам и свойствам классов сам за тебя напишет.