Тот самый случай когда если сказал никогда - то никогда не захочешь делать запросы на выборку по части такого поля, а прочитать его целиком и разобрать на части вообще не проблема, конечно. Однако как это нередко случается легкость решения соблазняет и многие не выдерживают и вскоре начинают хотеть. Примерно каждый десятый вопрос на sql.ru про то, как сделать выборку по значению "третьего элемента в строке с разделителем труба".
Рел.БД в принципе для таких закидонов не предназначены.
Процентов 99 программистов задающих вопрос в РФ используют коды и ждут магических ответов способных заставить работать эти же самые коды. Задать человеческий вопрос, ну типа - хочу чтобы когда тут нажимали стало красным, а когда отпускали стало зеленым - органически невозможно. Любой кто захочет отвечать должен декодировать процитированные коды, дешифровать их до смысла человеческого вопроса про красным и зеленым.
Я не смог дешифровать, могу только судить по шаблону кодов, который намекает на кложи или на переменные переменных.
Например есть базовая функция getcat() и возможно пригодятся ее расширения вроде getcat_one() getcat_two() getcat_three() и тд. Использование расширение диктует какое-то событие или условие, которое мы можем назвать вот так one, two, three. Становится очевидным что если приделать название базовой функции к названию опции, то мы получаем название нужной нам функции, например
$func=$base_name.'_'.$event_name;
/* и вызываем ее */
$$func();
Если не угадал - расскажите на человеческом языке что означают те самые коды про ютубу.
Так и продолжайте. Ничего лучше нет, а все что лучше - вообще не такое как дримвивер. Пока будете переучиваться всех заказчиков своих неискушенных растеряете.
То есть надо понимать что html и css - по определению бред укуренного стрептококка, и не может существовать никаких способов вывести эти изобретения из бреда. В сухом остается воображение и опыт. Ну еще там есть шнурки и компиляторы типа sass/less - в порядке развития бреда до ахинеи.
Кстати Люстра неплохо конвертит вектор в SVG со стилями. Может быть сейчас и в хтмл научились? Adobe Illustrator.
Smirnof, вы сами пишите? Тогда вот такой простой пример, сначала прототип, то есть базисный класс, потом его расширение.
Class Listing { /* в прототипе метод может вернуть null, или array() или пусто '' или скажем данные вернуть как есть, без форматирования */ protected function price(&$item=null){ return null; } /* вывод листинга в прототипе */ protected function render_items(){ $html=array(); foreach($this->data as $item) $html[]='<figure>'.$this->image($item).$this->desc($item).$this->price($item).'</figure>'; if($html) return '<div class="prod-items">'.join($html).'</div>'; else return $this->notfound(); } /* волшебный метод __toString() обязан вернуть строку поэтому все завернуто в try-catch блок */ public function __toString(){ try{ return $this->before_render().$this->render_items().$this->after_render(); } catch(Exception $e) { return $e; } }}/* а это в классе который расширяет прототип */class ListingMarket extends Listing { /* теперь метод price будет возвращать форматированную цену */ protected function price(&$item=null){ if(!$item) $item=$this->item; if($price=$item['price']) return '<val>'.format_number($price,FORMAT_DECIMALS,FORMAT_DEC_PT,FORMAT_TH_SEP).'</val>'; }}/* где-то в моделях куда-то монтируем */$this->list= new ListingMarket();$this->list->select(); /* это еще отдельная история как расширять базисные запросы *//* где-то в представлении штукатурим */<main><?php echo $this->navbar, $this->list; $this->pagination; ?></main>
Конечно расширять каждый раз класс ради скажем какой-то мелочевки вы не станете, но и проверять ее не придется каждый раз, если просто задавать в опциях данные, а не условия для проверки данных, например надо менять тег листинга и стили и ид и прочие атрибуты, тогда
public function __toString(){ try{ $o=&$this->opts; return $this->before_render() .'<'.$o['tag'].' id="'.$o['id'].'" class="'.$o['css'].'">' .$this->render() .'</'.$o['tag'].'>' .$this->after_render(); } catch(Exception $e) { return $e; }}
Затем эти $this->opts можно отгрузить в JS через json_encode() и получить все нужные сведения для работы с листингом в браузере.---------- Добавлено 28.07.2015 в 08:45 ----------Вполне понятно что все это - азы ООП и ОРМ, мне даже неудобно слегка все это объяснять. Причину я тоже знаю. Мы не читаем по-английски даже сайты о программировании, где особо его и знать не надо. Черпаем инфу с застарелых туторов в рунете и древних, популярных рамок (framework) переведенных на русский всякими полугурками. Учите английский.---------- Добавлено 28.07.2015 в 08:56 ----------Ну вот, а еще есть доступ к методам родителя (но НЕ переменным родителя если он требует инстанси).
protected function price($item=null){ return $this->old_price($item).parent::price($item);}
метод приделает к выводу ценника из родителя - типа "старый", зачеркнутый ценник в классе который расширяет родителя.
Отсутствие шаблона и некоторая размазанность верстки по классам конечно будет вызывать трудности, но другие, не такие какие вызывают шаблонизаторы, в рассыпухе данных и лапше тегов которых нормальному человеку сроду не разобраться без полкило водки.
Это просто другой подход, который можно осилить и освоить и перестроив мышление применять с большей эффективностью.
В одном поле возможно хранить несколько значений, значение которых по отдельности не имеет значения. Например так можно хранить имена файлов картинок товара с разделителем из запрещенного в именах файлов символе. Теоретически можно и описание туда засунуть - через еще один разделитель, но практически при таком хранении описаний не будет.
В таких местах где собирается куча заранее неизвестных по имени переменных, применяют геттер и неизбежно сеттер. Тогда все проверки типа isset перетекают в геттер и все становится чище и светлее. Единственная чашка йаду - из геттеров нельзя нормально получать reference.
То есть тому объекту который у вас там $this надо сделать расширение мозга объектом с такими геттером и сеттером.
Это было автору темы.
Затем из такой модели делается коллекция в объекте типа ArrayObject, то есть с интерфейсом массива и в эту коллекцию собираются такие же коллекции, в них еще и так далее согласно структуре хтмля или там чего-то еще. У каждой модели есть __toString() который рекурсивно будет вызван при попытке вывести корневую коллекцию в строку. Вот и весь "шаблон". Модели собирают дерево и затем скажем echo $this->models и действующее вещество в буфере.
Это было на бис. ---------- Добавлено 27.07.2015 в 23:58 ---------- Еще раз. Например в шалобонизаторе листинга будет туева хуча проверок всяких опций на рендер листинга, поиска, избранного, акций каких-нибудь - то есть разных представлений списка тех же самых продуктов. Чтобы не сломать извилины придумывают мета-языки для шаблонов.
В нормальной же расширябельной логике все опции выводятся как заложено в единственном "шаблоне". Если данных нет - ничего не выводится. Если данные появились из-за того, что прототип был расширен объектом поиска, акций, избранного или еще какой-то моделью - все что модель туда напихала и выведется.
Чтобы добавить фичу в шалобоне, надо сделать как выше процитировано
if(isset($foo)):
<div><?php echo $foo; ?></div>
Чтобы добавить фичу в логике, надо воткнуть этот $this->foo куда надо. Прототип выведет $foo которое в нем null, а если прототип был расширен и $foo наполнилось смыслом - так и выведется.
То есть это if перемещается из шаблона - где в норме никакой логики быть не должно - в логику приложения, в бизнес-логику. Зачем проверять опцию и генерить переменную, если можно сразу вывести опцию как таковую ничего не проверяя.
В общем и целом так устроена рамка yii. Я не пользуюсь, просто изучал рамки и обнаружил что китайская уюя пока что самая продвинутая.
Запросы к бд это не запросы к серверу. БД на сервере, там все локально. Конечно многое зависит от производительности компа где бд дислоцируется и от сложности запросов и от правильности организации хранения данных в бд и от размеров самой бд. Скажем сложный, то есть на несколько таблиц запрос с генерацией временной таблицы и выборкой из нее без индекса из базы в сотню тыщ записей может замедлить, да.
Я думал что-то похожее на файловый проводник в винде.---------- Добавлено 27.07.2015 в 20:55 ----------
Сам по себе drag берет id потомка, а drop возвращает id родителя. Без драгов в обычной форме вы могли бы вывести дерево в интерфейсе select-option (name-id) с отступами и дать выбрать другого родителя из такого списка для выбранной записи.
У меня такой баян повсеместно наблюдается, поскольку почти вся навигация сайтов создается и хранится в условно деревянной таблице. Ну то есть в id-pid-name паттерне.
Нормально данные для вывода должны быть инициализированы.
if(!isset($this->config['foo'])) $this->config['foo']=null;
Тогда в рендере делается обычный вывод в буфер и, если там было ничего - то ничего и не будет.
Если от данных зависит вывод целой ветки или как вы пишите блока, то можно его сформировать заранее или применить безымянную функцию. Например заранее
if(isset($this->config['foo'])) $foo='<div>'.$this->config['foo'].'</div>'; else $foo=null;
функция
$foo=function(&$data){ if(isset($data['foo'])) return '<div>'.$data['foo'].'</div>'; };
И на выводе делается просто echo $foo($this->config);
Если эта функция хочет больше данных, можно применить use($bar,$baz) ---------- Добавлено 27.07.2015 в 20:24 ---------- Так вот если ваш конфиг с геттером, то инициализация не нужна, вы можете вывести любую переменную в любом месте и если ее не было - ничего не выведется, ибо геттер вернет null. Кроме того поскольку isset в геттере, то в скрипте, если надо проверить на пусто, проверка соединяется с присвоением
if($foo=$this->config['foo']) $foo='<div>'.$foo.'</div>';
else не нужен, т.к. $foo==null уже. ---------- Добавлено 27.07.2015 в 20:36 ---------- Дело в том, что такой подход как вы процитировали и вызывает потребность в шаблонах, шаблонизаторах и мета-языках шаблонов. Все это по определению - геморрой.
Подготовив и построив же структуру данных для рендера вы получаете полную свободу в верстке путем соединения переменных или функций в той последовательности и вложенности, которая требуется для построения дерева в хтмле.
Такой подход порождает древовидные структуры в самих моделях и тогда рендер становится простым и понятным как карандаш и главное - никаких долбаных шаблонов с идиотскими мета-языками.
Программисты тут вроде тоже тусуются и давно могли бы объяснить не программистам что магазин это интерфейс базы данных плюс немного дизайна ибо он тоже продает.
Нормализованные сущности обеспечивают все эти фичи как то сортировка и выборка. Если в бд есть ссылка на бренд, если есть цвет, дизайн, форма, размер и тп - значит по всем этим параметрам можно выбирать и менять порядок внутри выборки. Выборка ведет к конечной станции - к продукту, это - базис.
Затем сущности учета сделок и движения товара - как оплатить, как отследить, как сохранить хронологию, это - надстройка.
Больше ничего не надо.
Так вот этот самый интерфейс создают программисты, которые как правило не бельмеса в коммерции. Даже с такой простой фичей как сортировка выборки по цене они умудряются наворотить вариантов от "сортировать по убыванию цены/сортировать по возрастанию цены" до "цене (стрелочка)". Парадигма понимаешь запрещает написать в списке опций как написал бы нормальный человек - дороже/дешевле. В теории заказчик должен удивляться и требовать написать нормально. Не требует, значит сам не бельмеса в коммерции.
В некоторых отраслях вроде производства мобил и планшетов, аудио-, видео- фото- и тп программистов с инженерами маркетологи взяли под контроль, но в этом колхозном домене строительства инет-магазов инженерье все еще чувствует себя вольготно и самовыражается на полную катушку.
Взять хотя бы эту бредятину - добавить в сравнение. То есть сами себе запортим всю работу по впариванию, типа подарим надежду юзеру найти то самое заветное соотношение цена-качество.
Так вот выбирая ИМ и заказывая шаблоны - требуйте человеческого интерфейса, максимально гуманного и впаривательного, то есть такого, который не гасит имеющуюся потребность, но развивает и углубляет ее, и который сам зарождает потребность, чтобы углубить и развить.
Да, а платформа - вордпресс или любой другой друпал - не имеет значения.
