ShamblerR: ну а как быть с городами и кинотеатрами, которые не подключены к киноходу и кассе? В Кургане например только 1 из 5 кинотеатров подключен, остальные 4 пользуются также большим спросом, но они пока не доперли до киноходов и касс. Мой город имеет 2 кинотеатра и ни один не подключен, то есть для горпортала важно иметь возможность хранить эти данные. Вы бы как хранили сеансы? Кинопоиск последний раз не раньше года назад менял структуру, весь парсинг происходит в одной функции, так раз в год можно и переписать селекторы. Можете на почту написать? faragly@mail.ru
ShamblerR: спасибо, было бы отлично! то есть в вашем решении сеансы как промежуточные данные не сохраняются в БД? У меня насчет контента вопрос не встал, я сделал автоматический парсинг кинопоиска, в админке выбирается постер и кадры и одним нажатием дбавляется как элемент инфоблока. А сеансы планировал привязывать к ИД фильма
ShamblerR: без интеграций на данном этапе, для городского портала. В моем городе не давали возможности для подключения к UCS, поэтому расписание высылали почтой, контент-менеджер забивал все это.
ShamblerR: Я тогда сделал киноафиши, было 3 инфоблока - с сеансами, с фильмами, с кинотеатрами. Каждый сеанс добавлялся на отдельной странице (как обычный элемент инфоблока добавляется, в этом первая убогость, нет множественного добавления). Ручное добавление фильма с множеством полей, копи-паст лишний геморрой. Цены на сеансы также хранились в отдельном инфоблоке, цены отличались в зависимости от кинотеатра, фильма, социльного статуса (детские, студенческие, взрослые). Это что касается убогости добавления и редактирования. Сам компонент был написан по уму как мне казалось, запросы в базу сводились к минимуму, но скорость вначале была секунда-полторы после сброса кэша, после оптимизации удалось добиться 100-150 миллисекунд. По сравнению с остальными страницами это в 5-10 раз дольше. Сейчас же сделан удобный интерфейс в админке, с ангуляром и прочими плюшками, встал вопрос как все же хранить сеансы.
ShamblerR: то что я пишу - в стандартном битриксе нет 100%, я начал работать с этой системой с версии 6.0, я знаю что я не хороший прогер, но я хотя бы это признаю. То что я делаю - стандартным функционалом не сделать (можно сделать связки в инфоблоках, но компоненты однозначно писать придется и это будет убого, так я уже делал). На данный момент я написал часть модуля, пусть код не идеальный, но он делает свое дело. В данный момент я признаю что я мне многому нужно научиться и поэтому я здесь. Я не начал городить свой код на highloadblock потому что я подозреваю что это нужно делать на ORM, но я не знаю как делать множественное поле дата и потом как я буду работать с этими данными, поэтому собственно и спросил.
ShamblerR: Уважаемый, вам не кажется что вы начали изливаться желчью? Вроде я вопрос вполне конкретный задаю, если вы против горе-программистов, после которых к вам обращаются как к разработчику - то это не мои проблемы. Это во-первых. Во вторых, я модуль пишу для своих потребностей, так что перестаньте истерить. И вообще, что вы делаете на этом ресурсе? Вопросы обходите стороной, ваши сообщения веют негативом. ЗаметьТЕ, я обращался к ВАМ, а не ТЫкал :)
ShamblerR: пишу модуль с юзабельным интерфейсом, хочется найти максимально оправданное средство для хранения данных о событиях, инфоблоки отметаю, там много лишнего. ORM еще не использовал, мне нужно хранить несколько дат к одному событию, множественное свойство дата и затем по определенной дате делать выборку событий. Гигантских объемов нет. На ORM как сделать множественное свойство с датами?
А в скорости будет разница? Вроде и первый и второй варианты используют прямые обращения в бд. Встречный вопрос - возможно на ORM сделать множественное поле типа дата и затем делать выборку по совпадению даты getList'ом?
код сократил по максимум, там у меня еще свойства задаются, но вот весь костыль только с детальной картинкой. Изображения предварительно уже закачаны и получили свои ИД (правда под другим модулем), видимо использовать их не удастся если не перекачать в инфоблоки
Дело в том, что подобная задача была реализована на jquery и там не возникало подобного, поэтому проблемы с сервером исключил. Но тогда я использовал денвер, а сейчас Winginx, сейчас реально тупик, даже не знаю в какую сторону копать
Но ведь сервер обязан обрабатывать множество запросов, не так ли? Я проверил, запускаю долгий процесс, затем обновляю скрипт вытягивающий прогресс, он долго работает, как только долгий запрос обрабатывается, выдает ответ скрипт прогресса... С чем это связано, как это победить? У меня локальный сервер Winginx
xmoonlight: в функции ajaxStart() я жду 1 секунду и отправляю запрос для проверки выполнения, в ajaxProgress() ждать наверно не стоит, убрал, но дело не в этом