Геннадий, тем, что нужно вывести сгенерированную в реальном времени информацию, а не забить базу данными этих полей. Пользовательские поля - для хранения данных, а не для вывода информации.
И при чем здесь события?
Видел события для кастомизации формы заказа; для кастомизации формы элемента инфоблока есть специальный файл - хотел узнать, может быть, что-то подобное предусмотрено и для формы редактирования пользователя. В интернете информации не нашёл.
Александр, проблема в том, что у меня текстовых ресурсов на 150mb - скорее всего, повесит устройство, если всё будет сразу грузиться в память (не говорю о том, как разрабатывать, имея такую массу текста встроенной в тело файла).
Александр, на странице нет сразу всех ссылок, поэтому таким образом весь сайт сохраняться не хочет. Есть ли какие-то программы, которые набор файлов могут сконвертировать в mhtml? И содержимое страницы строится на JavaScript. Тот mhtml, который получился через сохранение в браузере, хотя и имеет, например, меню в теле страницы, а открывать его не хочет.
rPman, первый пункт выполнен - я писал выше, что все статьи есть в текстовом формате и структурированы - все внутренние ссылки связаны с текстовыми файлами, на которые они ссылаются; всё разложено по папкам. Как сделать из этого сайт - вопросов нет, но нужно именно представить их в виде мобильного приложения. Какими средствами такое быстрее всего можно реализовать?
rPman, есть только все статьи в текстовом формате, доступа к самому сайту нет. В статьях разметка и ссылки заданы при помощи BB-кодов, их преобразовать не проблема. То есть, нужно сделать оффлайн-сайт, который будет открываться как приложение на Android.
Алексей Ярков, сайт долгое время не обновляется, есть все статьи в текстовом формате (файлы txt). Сайт, можно сказать, одностраничный - просто переключаются статьи. Разметку и стили написать не проблема. По факту, нужно только меню с разделами и статьи со внутренними ссылками.
Относительно идеи с разделами есть сомнения - где-то читал жалобы на скорость работы при большом количестве разделов. Спасибо за ссылку на статью. Думаю, в случае со статическими данными, как у меня, лучше подойдёт ответ выше - там есть дублирование данных, но все данные получаются без рекурсии, быстрыми запросами.
Adamos, вчера уже плохо воспринимал информацию и почему-то подумал, что вы предлагаете хранить список нижестоящих. В этом случае без рекурсии при добавлении не обойтись. А при хранении вышестоящих новый пользователь получит ID пригласившего + список вышестоящих пригласившего - рекурсий не будет. Имеет место дублирование данных, но при относительно небольшом количестве пользователей это не должно стать проблемой. Во всяком случае, таким образом мы избежим рекурсий при получении данных.
Но остаётся один вопрос - если мы получаем список нижестоящих по "LIKE '%#13000#%'", то как мы можем понять уровень каждого полученного элемента относительно текущего? Это тоже важная часть задачи.
P.S. Для каждого полученного пользователя на уровне PHP разбить список вышестоящих на массив по "#" - и индекс элемента, в котором находится ID текущего пользователя - и будет его уровнем. В зависимости от порядка хранения пользователей, возможно, придётся обратить массив.
Нет, так не годится, потому что при таком подходе потребуется при добавлении каждого нового пользователя обновлять это поле у всех элементов дерева. А их может быть много.
> что вы хотите от этих данных,
Чисто от них - иметь возможность получить список:
1. Всех пригласивших выше меня.
2. Всех приглашённых мною и далее (как в примере в тексте вопроса).
По сути, только эти две функции и требуются. Но и процесс добавления элемента в дерево тоже должен быть простым.
