Момент у меня в опере 11.61 происходит предупреждение что запрос небезопасный. При подтверждении реферер не скрывается. В целом это уже нюансы. Можно и отказаться от использования оперы. Я не ожидал и такого результата. Еще раз спасибо
Момент у меня в опере 11.61 происходит предупреждение что запрос небезопасный. При подтверждении реферер не скрывается. В целом это уже нюансы. Можно и отказаться от использования оперы. Я не ожидал и такого результата. Еще раз спасибо
Можете мне в личку или сюда написать пример кода вложенных iframe. Я тоже так делал, но тогда на целевой сайт приходил referer фрейма. В целом это уже лучше. Но все равно сайт светился. Или я не так понял Вас.
Тему про EAV начали вы. Я же говорю что для текущего примера это бред. Потому смысл кидать мне ссылку где обсуждается именно этот подход и указывать что я не умею использовать поиск…
Вы читали мое сообщение? Я написал что EAV применяется. Но в данном конкретном примере его использование мягко говоря сумасшествие. У меня все больше и больше складывается впечатление что вы знаете все это только по наслышке, и не работали в реальных условиях. То что предложили вы — хорошо может выглядеть только на бумаге. Высказывание про HAVING остается в силе. Вообще забавно. Вы так силитесь меня учить, а как вижу с EAV сами не работали. Без HAVING или вложенного запроса вы не сделаете поиск по нескольким атрибутам одного товара (зачем было говорить про расположение названия товара в goods. Понятное дело что имелось в виду про тот атрибут который находится в смежной значений) Если простые слова вас все не убеждают могу привести пример такого SQL запроса. narod.ru/disk/40930454001/%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81.xls.html. Повторюсь еще раз. Представление не диктует мне структуру хранения данных в базе. Но я смотрю весь процесс целиком, а не на малую его часть. При хранении этих полей через EAV вы сделаете такую грыжу для реализации остального функционала что и свет белый не милым будет. И лень тут ни при чем. Тут только здравый смысл. Да и база тут не выиграет. В лучшем случае для выбора 5 товаров с характеристиками у вас будут 5 дополнительных запросов. А для обычных случаев будет по 100 и больше. Но вы все эти моменты не учли. Зачем спрашивается. Нам же нужно взять все значения характеристик. Конечно это можно решить кешированием, но зачем ломать себе руку что бы ее потом лечить. Я сказал все что хотел.
У меня складывается впечатление, что вы по большей степени теоритик. И не реализовывали задачи на практике. Конечно я могу ошибаться. И если вас это оскорбило, приношу свои извинения. Первые 2 решения это единственный гибкий вариант который я смог придумать для решения поставленных задач (и я был бы искренне рад, если бы вы предоставили более хорошее решение. Ведь для имитации таблиц нужно всего 4 поля: id, цена, название, описание. Где id, название, цена уникальны для каждого товара, а описание общее для всех. Также нужно учесть что общих и уникальных полей может быть значительно больше). Из всех форумов и обсуждений на которые я его выносил улучшение предложили в разделении таблицы товаров на 2 по тому принципу что я описал ранее. Третий же способ разделения цен применяется в львиной доле CMS интернет магазинов. И никакой избыточности в себе не несет. Про разделение данных и бизнес логики я вообще не говорил. Тем более модель в любом случае затачивается под таблицу с которой она работает. Указывая на недостатки текущей модели без предоставления альтернатив несколько не по фэншую =)
На счет первых двух совершенно согласен. Мне тоже не нравятся эти решения. Хотя они дают чрезвычайную гибкость реализации поставленных задач. К тому же отчасти решение пустых полей можно решить таким образом. Разделить таблицу товаров на 2 части. В одной будут 100% уникальные поля. В другой те что будут дублироваться. Третий же вариант мне кажется наилучшим если не учитывать что он хорошо подходит для более узкого круга задач.
Вы говорили про то что записи в базе данных никак не должны ограничивать отображение. Совершенно согласен. Но такого результата в большинстве случаев можно достичь в лабораторных условиях а не в реальных проектах.
Я предпочитаю работать через ORM. Хотя при надобности чистый sql это не проблема.
Спасибо. Я работал с 1-й версией. У Smarty 3 есть игнорирование ошибок на несуществующую переменную и на не закрытый цыкл к примеру. Так же как можно загрузить шаблон не с файла, а с переменной.
Наверно я не ясно выразился. Если я не подключаю elFinder все работает как нужно. Когда я редактирую поле и оно теряет фокус выскакивает алерт. А когда подключаю elFinder алерт начинает выскакивать при клике на любой элемент страницы
