API плеера который у вас в коде.
Документация короче нужна, где описано как работать с этим плеером. Можно ли ставить плейлисты, как отловить окончание проигрывание очередного трека, как загрузить новую музычку и т.п.
Если юзаете стандартный (HTML5) или более-менее распространенный (выше подсказали) плеер то у него все это есть и вам укажут где искать. Если юзаете непонятно что - где искать непонятно.
Вы хотите отправить Ajax на чужой сервер? Если так, то ничего не выйдет. Ограничения политики безопасности.
Я же писал волшебное слово - WebStorage ---------- Добавлено 05.08.2013 в 09:09 ---------- И вот еще по поводу ограничений и скорости исполнения:
Chrome, Safari и IE не накладывают жестких ограничений для поддоменов и специально оформленный сайт может занять всё дисковое пространство. Подготовленное тестовое web-приложение способно заполнять диск с интенсивностью примерно 1 Гб в 16 секунд (Вас устроит :) ). Реализация Localstorage в Firefox по словам Feross "оказалась умнее". В Opera вопрос расширения размера localstorage оставлен на откуп пользователю.
http://www.opennet.ru/opennews/art.shtml?num=36259
Вполне может что встроенная в броузер БД даст прибавку намного больше чем в 2-3. Ввод-вывод самая ресурсоемкая вещь.
Единственный затык встроенных БД - ограничения на размеры 5-10Мб. Но в IE размер БД можно кастомно настраивать. Про другие броузеры не знаю. И наверное можно поискать плагины.
И я ровно о том же. Если для извлечения и _апдейта_ структурированных данных вместо БД юзают CSV больших размеров, то у меня лично возникает подозрение, что проблема не в том что данных много, а в том что они организованы криво. И кажется не у меня одного.
Обратите внимание как топикстартер решает проблему:
Имхо slavegirl изобретает свою собственную БД на CSV
Сорри. Это из _моего_ далекого прошлого :)
Но тем не менее, если приблуда уже есть, то вопрос о записи на диск не стоит. И очень вероятно что задача м.б. выполнен более эффективно - без того чтобы читать-писать большие файлы и урезать ради экономии мд5-ключи.
По бинарные файлы - Речь ведь шла юзать текстовый файл вместо БД, нерационально. JS умеет работать с БД. Опосредованно через WEB-Storage в броузере или напрямую через дополнительный софт.
Только разработчик плеера.
Но если известно API и вы дадите на него ссылку, то вполне возможно кто-то и поможет.
Вообще-то топик-стартер пишет, что использует сторонний плагин - iMacros. А это действительно что-то из очень далекого прошлого и наверняка есть альтернативы.
Без мутатени WEB-Storage 5-10Мб. в зависимости от броузера (может сейчас и больше). Задача ведь не файл записать, а данные сохранить.
Flash - мутатень, но пока еще жива и устанавливается по дефолту. Чрез нее можно получить доступ ко всем ресурсам.
Единственное ограничение - можно работать со своим сайтом, а топикстартер не уточнил со своим сайтом он работает или с чужим. А если с чужим - то можно без всякой мутатени можно поставить nodeJS вместо броузера и на чистом JS писать что угодно и куда угодно.
В дополнение к Brand from Amber,
Может пора подумать об HTML5? Там все прозрачно. У современных броузеров встроенные плееры. При желании можно найти что-то "красивое" или самому написать.
1. И круд и грид и далее везде. Я посмотрел несколько CMS сделанных на YII. Все тупо следуют мануалу YII. Следствие - насколько они удобны для программиста настолько неудобны и для верстальщика и самое главное для юзера (необозримые формы на несколько страниц, отсутствие fullAjaх и редактирования страниц на клиенте)
2. Не в том проблема, что от ручного труда не уйти, а в том, что компонентный подход увеличивает нагрузку на верстальщика, который кроме своих заморочек (кривой дизайн-станадарт- броузеры) должен погружаться в заморочки програмистов и разработчиков фреймворка.
> прикрутить вёрстку и ручками прописать атрибуты name/id и тд.
В тенденции сближения php и MS, которую я наблюдаю в YII (могу и ошибаться) эти атрибуты будет проблематично прописывать без изучения API конкретной модификации конкретного фреймворка с конкретным шаблонизатором принятом в конкретном проекте.
Кроме вас уже два человека мне прописали - не нравится перепиши стандартный компонент. Стандарт масдай, даешь Хаос. php-фреймворки призваны устранить хаос в программном коде, но они породили хаос слоя VIEW. Если раньше каждый программист писал свой гениальный шаблонизатор, теперь до кучи каждый модифицирует VIEW любимого фреймворка.
> Ссылки, разве что, для удобства собственного... Чтоб не переименовывать по всему коду.
Мы сваливаемся в холивар. И холивар идет из разделения зоны ответственности - кто должен формировать код _любого_ тега. Я не вижу никакой разницы между тегом ссылки и любым другим тегом с точки зрения разделения сфер ответственности.
Имхо влезание верстальщика в программный код фреймворка, это все равно что вызов контроллера или модели из view. Убивать за это нельзя но и хвастаться не стоит.
Я готов принять любой маразм, если он приведет к унификации процесса разработки. И если всюду будет phar или (прости Господи) Smarty - пусть он будет. Но всюду.
Прошу у топикстартера прощения из-за ухода в офтопик. Я сопротивлялся как мог.
