Чет мне кажется, что фон будет лежать за текстом, а это уже как бы не перечеркнуто, т.е. картинка должна быть поверх циферок, но тогда есть проблема с выделением,---------- Добавлено 22.10.2014 в 23:58 ----------off: у нас одна дата регистрации, братуха :))
Финт ушами :):
http://jsfiddle.net/aagkg03z/3/
Письмо от рапиды приходит когда произошло зачисление счет акка рапиды и когда они переведены по шаблону. Письма пришли не всем т.к. платежи в процессе, мне тоже не пришли.
ок, дома посмотрю, андроида под рукой нет. А логика у js с вашим приложением будет простая и подходящая по большому счёту только вашему сайту, чего там скрывать. Ок, делайте как знаете, просто посмотрите куки яндекса или гугла или почты гугла, почты яндекса (document.cookie, в консоли), это у тех, кто довольно сильно заморочен над оптимизацией работы своих приложений.---------- Добавлено 22.10.2014 в 17:41 ----------
на мой взгляд специфика работы приложения с пользователем в большей степени должна перекладываться на js, оставляя серверу работу с неперсонифицированными данными ( хотя это не всегда возможно ).
На мой взгляд лучше.
Вы попробуйте, у меня на androide с опера мини работают приложения которые состоят из одного js и все там ок с производительностью.
Не хочется спорить но cookie это максимум 4кб :)), js замедлит если делать анимации и пр. лабудень, для $(el).attr( 'id', 'any' ), вы ничего не заметите, но такими мыслями серьезно себя ограничиваете в функционале.
Вы там выше написали о том, что это может быть картинка, видео, аудио, поэтому почему нет, ведь все эти объекты могут использоваться в нескольких статьях, но вам виднее как именно будет в вашем случае
Добавить в закладки по h2 некоторой статьи можно чисто javascript + cookies, ( пронумеровав их при загрузке страницы тем же javascript ) или хочется на разных устройствах помнить?
В общем если правильно понял расчитываете на зарегистрированного пользователя .. ок ( если нет то тоже js мог справиться )
Здесь наверное да, если аннотация это вступление к некоторой статье, то возможно статья должна уметь себя показывать как аннотация.
Если так, то да изображение надо уметь обрабатывать без парсинга собственного сайта.
Обычно join показывает результат равный или худший нежели два отдельных под запроса этого join, только тест скажет как будет в конкретном случае и какие именно данные будете доставать, но чуда вероятно не случится.
Ничего плохого нет, только уверены, что не хотите использовать таблицу связей (там и указывать позицию), ведь некоторую figure и др. объекты данной статьи можно было бы использовать в другой. Почему 2 не имеет смысла без 1? чем меньше тем выше, хоть -100 -10 0 10, какое именно число на мой взгляд не важно, вам же нужно только ранжировать.
Наверное лучше использовать общую с параграфом таблицу, если только вы эти strong не начнете использовать в других статьях отдельных от первоначального параграфа.---------- Добавлено 22.10.2014 в 16:15 ----------В целом когда сделаете структуру базы покажите её здесь, думаю все станет гораздо яснее.
ortegas, ок становится немного прозрачнее, что не совсем CMS, а некоторый сайт со своей спецификой и внутренними объектами так? Объекты страницы чем отличаются друг от друга?---------- Добавлено 22.10.2014 в 15:21 ----------Что-то мне подсказывает, что можно обойтись структурой которую указал в первом посте, добавив в таблицу Section поле section_type ...---------- Добавлено 22.10.2014 в 15:23 ----------Но в целом в вашем варианте нет ничего плохого, если выборка из 3 таблиц тремя запросами это вполне себе ок, для такого варианта сайта в котором несколько типов объектов.---------- Добавлено 22.10.2014 в 15:25 ----------Если уже есть готовая структура базы именно этих таблиц, было бы понятнее
ortegas, понять бы еще, зачем вы хотите выделять из текста по regexp его внутреннюю структуру, зачем она вам? Хочется именно выяснить какую цель приследуете. Вы делаете свою CMS? у которой разработчиком сайта и наполнителем контента будет конечный пользователь?
я так понимаю структура таблиц будет такая: таблица статья, таблица секции, таблица связей вроде
Article
[id, title]
Section
[id, title, body]
ArticleSection
[article_id, section_id]
Если да, то проблем с производительностью быть не должно все в рамках привычного использования реляционных бд.---------- Добавлено 22.10.2014 в 02:54 ----------Вы уверены, что секции надо делить на три разные таблицы? Вероятно там сильно много общего наверняка можно обойтись одной. Тогда и проблем с выборкой из трех таблиц не будет, а архитектура предполагающая FULL OUTER JOIN имхо заслуживает того, чтобы ее пересмотрели.
