Обновить
-3
0
Максим@maxru

Пользователь

Отправить сообщение
Почитайте про jsonb в postgres и сравните возможности.
Просто с json постгре уже давным-давно научилась работать.
Знаем, пользуемся.
До JSON'а был hstore, он тоже умел в индексы.
Третий вариант — самый гибкий, но от него почти сразу отказались, так как нужны были сортировки и фильтрация по названиям, и для этого все равно пришлось бы делать что-то аналогичное варианту 1 или 2.


Ехал постгрес через постгрес. Тем более что в 9.4 нормальная работа jsonb появилась с индексами и печеньками.
Отлично, спасибо!
Про PDI очень понравилось.
Извиняюсь, Pages маковские.
Соглашусь с комментарием, UMI-CMS — сферическое ООП в вакууме, с реальной жизнью имеющее мало общего.
Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

Лок-файлы не умное решение.
Случай 2.
Лучше картинки разбивать по папкам не по датам, а, скажем, по первым нескольким символам хеша и по нескольким уровням, чтобы более равномерно распределить их по папкам.

Случай 3.
pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

Странные у вас программисты какие-то, не умные.
1. Но выбрать можно будет? Неудобненько выходит в таком случае. Выбрать можно, а купить нельзя.
2. ок
3. Не подойдет, если цена зависит от набора параметров. Я имел в виду линеаризовать для клиента.
1. А если белые айфоны есть только с 64 Гб и Wi-Fi? Клиент что увидит?
2. А цены на комплектацию как назначать? Через матрицу цен?
3. Имхо правильнее было бы линеаризовать составную комплектацию, особенно если вариантов меньше 6, было бы сразу видно, какие варианты можно купить, а какие нельзя.

Т.е. так:
* белый, 16Gb, Wi-Fi+3G
* черный, 32Gb, Wi-Fi
* черный, 64Gb, Wi-Fi+3G
Опять на свет полезли.
Zend_View есть, который native php.
Но можно прикрутить и любой другой.
gmail и яндекс прекешируют картинки, так что письмо будет в любом случае «получено».
Нет, в таком виде не пройдёт.

Но «адок» из базы будем выводить так:
$html = <div id="mydiv"><p>{$data['content']}</p></div>; // $data['content'] = 'Привет, <b>Хабр!'


Т.е. данные, подставленные в шаблонизатор, в любом случае будут восприниматься как простой текст и экранироваться.
В итоге будет выведено:
<div id="mydiv"><p>Привет, & lt;b& gt;Хабр!</p></div>
Нет, он в любом случае получит:
— экранированный вывод, если использовались стандартные классы
— не экранированный адок, если вы специально создатите сущность, которая не будет экранировать child'ов
Т.е. любой контент воспринимается как текст.

Чтобы получить не работающий сайт нужно создать stream_wrapper и инклюдить контент из базы как файл шаблона. И я не знаю, что хуже — не работающий front-end или исполнение кода из БД :)
Скорее между JSX и Hack.

Не понял только, как собранный из JSX JS может выполняться в браузере быстрее себя самого (это я из презентации почерпнул)?
HTML — тоже XML, я обобщил.

P.S. Я и не воспринимаю в штыки, я дискутирую.
P.P.S. Напишите, что именно нужно раскрыть полнее? Этот пост планировался скорее как краткий экскурс с целью выяснить, есть ли заинтересованность в предметной области в принципе.
В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.

Автоматическая генерация на 100% валидного XML и возможность манипулирования DOM-структурой тоже не тянут?
Или расширить базовые классы и использовать что-то навроде:
<ui:input ... />

или
<ui:upload ... />

вместо копирования html-кода или подключения шаблонов в цикле / repeater-ов?

Ну и, естественно, docs.hhvm.com/manual/en/hack.unsupported.php

Нет, все из-за кармы

Я интереса ради ваши комментарии в профиле уже почитал. Сдержаннее надо быть.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность