У вас с математикой проблемы?
Вы не можете, зная в какой временной зоне находится ваш сервер, посчитать какое время показывать юзеру, зная его часовой пояс?
Если храните дату вместе с временной зоной, то всё ещё проще через DateTime
Ранее как возникла ошибка в валидации и увидел что в шаблоне регулярки, просто взял и закодировал их.
Странно, попробуем все регулярные выражения в исходный вид вернуть и постараться вернуть ошибку.
upd. Интересно, ошибки нет. При этом json формируется не заранее а на лету по запросу. Так бы можно было предположить что была ошибка при записи ответа в бд... . И репозитория нету старого Подожду пока проявится.
Передать-то конечно можно, но какбэ распарсить потом стандартными функциями JS не получится ибо в регулярках могут быть и есть символы используемые в разметке самого JSON.
Потому либо экранировать каждый такой символ и на клиенте чистить, либо base64.
По крайней мере только о таких вариантах думал.
Если вы точно не знаете зачем вам писать данные именно в реляционную бд, то скорее всего вам не нужно их там хранить.
Решение в хранении кэша в файлах.
Использовать memcache нужно только в том случае если вы точно знаете что здесь он нужен. А к этому можно прийти только в результате тестирования и анализа результатов. Учитывая ваш перечень данных "последние комменты, новый посты, новые пользователи и пр." целесообразность использнования memcache под них крайне маловероятна.
Доброго времени суток. Думаю, что тему можно отнести в этот раздел.
В проекте есть формы, содержащие значительное количество (в среднем 30-40) полей разного типа.
Задача в оптимальной с позиции затрат ресурсов и удобства пользователя валидации значений. На клиенте используется сокращённый jquery.validate.
Типы фильтров:
Обязательное поле
Регулярное выражение
Макисмальное значение
Минимальное значение
Маска (тож регулярка)
К полю можно передать текстовый комментарий к ошибке заполнения.
Поля вместе с фильтрами тянутся по ajax в json-формате при запросе формы определённого типа.
Проблема валидации значений форм уже поднималась обсуждалась.
В данном случае я сторонник делать все проверки на стороне клиента и уже потом делать всего одну проверку всех значений на стороне сервера.
Вопрос возник именно с оптимальным решением для проверки по регуляркам на клиенте.
Регулярки просто так передать в json нельзя. Посмотрев массу корявых функций кодирования регулярок под json решил использовать старый добрый Base64 и декодировать их на клиенте.
Как вы считаете, насколько оптимально это решение?
Есть-ли что-то поэлегантнее для кодирования регулярок и насколько с вашей точки зрения вообще целесообразно это делать на стороне клиента?
Учитывая что вопрос всё-таки касается моего огорода - решил что буду делать именно так в целях уменьшения количества запросов и операций не дешовых проверок по регуляркам на стороне сервера.
Кросс-доменные запросы через IFRAME + postMessage
http://learn[dot]javascript[dot]ru/ajax-iframe-xdomain
И смысл ссылки?
Я показал готовое решение причем кроссбраузерное и с postMessage и без postMessage, которое будет работать и в IE6. Лишь бы пост оставить что ли
кроссдоменого ajax'a не существует по причинам безопасности. Для запросов на другой домен либо фреймы либо писать php скрипт который берёт данные и обращаться к нему ajax'ом
Для IE 6-7 придётся использовать обходное решение для эмуляции междоменной передачи (что задачу всёравно решит) построенное к примеру на jquery Postback (postmessage):
$sql=$db->super_query("SELECT `".PREFIX."_comanda`.`id` AS `id1`,
`".PREFIX."_comanda`.`name`,
`".PREFIX."_comanda`.`img`,
`".PREFIX."_comanda`.`info`,
`".PREFIX."_comanda`.`phone`,
(SELECT GROUP_CONCAT(`".PREFIX."_comanda_sertificat`.`img` SEPARATOR '::') as `pimg` from FROM `".PREFIX."_comanda` where `".PREFIX."_comanda_sertificat`.`cid` = `id1` )
Если у вас есть прямой доступ к серверу проекта тогда разумеется можно : решается анализом исходников или лобовым grepом каталога проекта на сервере.
Если доступа нет тогда какой код и трафик вы собрались анализировать?