Дополнительное свойство товара

Цитата:

Если ваш контент-менеджер напишет в свойстве товара «Чтен» с ошибкой (с опечаткой, или пробел в конце вставит, или еще чего-нибудь в этом роде? в некоторых случаях даже регистр букв имеет значение) или вместо «чтен» напишет «Для чтения», то такой товар не будет подпадать под фильтр.
А если в шаблоне случайно закрадется опечатка в value при редактировании оного, то данный пункт вообще работать не будет.
А если кто-то добавит в доп.свойство товара значение, которого нет в списке — то оно в списке не отобразится и под фильтр не попадет.

1. Дело как раз в том (о чем я и пытался все это время сказать), что этот самый человеческий фактор исключен. И что такая "ручная" обработка в стиле хард-кор меня вполне устраивает. Если это было бы не так, то да, действительно 5 900 - это на самом деле деньги небольшие.

2. А насчет "чтен" и "для чтения" - там like стоит, вероятно, по включению и не чувствительный к регистру, так что то, что я "опубликовал" работает во всех практически вариантах доп. свойст, например: "Для чтения в туалете", "Чтение", "чтение мелкого текста" и т. п. - главное чтобы присутствовала последовательность символов "чтен". Так что не все так печально, как Вам кажется.

3. Очень жаль, что Вы продолжаете возвращаться к старым вопросам, не относящимся к теме и игнорируете вопросы по существу. Не проще ли тогда мои сообщения игнорировать полностью? А я буду надеяться, что ответит кто-то более бескорыстный и не склонный к троллингу

PSin писал(а):

1. Дело как раз в том (о чем я и пытался все это время сказать), что этот самый человеческий фактор исключен. И что такая «ручная» обработка в стиле хард-кор меня вполне устраивает

Ну я же не случайно сказал про российскую ментальность

PSin писал(а):

2. А насчет «чтен» и «для чтения» — там like стоит,

Почитайте про оптимизацию sql-запросов и о том, какую нагрузку like создает на базу данных.

Так что все по-прежнему печально.

PSin писал(а):

и игнорируете вопросы по существу

Я-то вам как раз по-существу и отвечаю. Что нужно пользоваться уже готовыми и технически верными решениями, а не изобретать велосипеды на костылях вместо колес. Тем более если вы согласны с тем, что 5900 это на самом деле небольшие деньги.

Блин.. точно тролль. Какая нагрузка? От 3 опций в 2х доп. свойствах? У меня не федеральная база налоговой инспекции (3ий раз напоминаю). Тем более что like там по умолчанию стоит, ведь это бывшее редактируемое текстовое поле ( <xsl:if test="property_show_kind = 1"> ) а там без like вообще ничего фильтр не найдет - никто точными запросами пользоваться не будет.
Спрашивается, в чем разница? Редактируемое поле или набор из 3-4х зафиксированных опций? Тем более, что в редактируемое поле еще и SQL-инъкцию можно запихнуть (впрочем, там конечно защита должна быть, но тем не менее). Спсибо за помощь, короче говоря.
Такое ощущение складывается, что я лично у Вас отнимаю 5 900 вместе с последним куском хлеба

Кстати, ув. Kotoff, в не очень далекой отсюда ветке обсуждения вы делитесь скриптом реализующим поиск в версии "халява". На мой взгляд, версию "мой сайт" следует приобретать только за год тех. поддержки, а поиск - это бонус. Но если рассуждать Вашими категориями то вышеуказанное - это ни что иное как
и, следовательно,
У Вас ко мне что-то личное? Или изменились взгляды?
В любом случае, я ни на что ведь не рассчитываю, а просто задал вопрос. А отвечать на него или нет - личное дело каждого. Вам все равно спасибо, остальные вообще не удосужились ничего написать. Жаль, я думал, будет многим интересно.

Ув. PSin! У меня к вам ничего личного. И не личного тоже. У меня к вам вообще ничего, если честно.

Относительно же поиска в "Халяве" есть два нюанса. Один толстый, а другой тонкий.

Толстый состоит в том, что по сути это не полноценный поиск - он ищет только по названию товаров и не поддерживает морфологию.

Тонкий же нюанс в следующем - если вы внимательно читали начало той самой темы, то должны были заметить, что способом-то исходно поделился не я, а denisov999. Я же просто исправил ошибки в его коде. Потому что очевидно, что этим решением будут пользоваться, раз оно уже опубликовано. Так пусть уж оно будет хотя бы технически верным, без потенциальных дыр в безопасности, не создающее излишней паразитной нагрузки и соответствующее принятым в HostCMS парадигмам.

И это не "проявление неуважения", а как раз наоборот.

Потому что если будет растиражировано решение содержащее дыры, то рано или поздно под него появится эксплойт, и система будет скомпрометирована как потенциально небезопасная. А это, в свою очередь, бросит тень на репутацию системы. Сейчас же мне не известно ни одного экcплойта под HostCMS.

Ну и что мне теперь, писать "дырявый" XSL, чтоб мне там маленький косяк поправили?

Возможно к вашему сожалению, но в XSL не может быть ошибок безопасности. Это же почти идеальный MVC-шаблонизатор, изолированный от контроллера и модели.
В XSL могут быть:

• грубые синтаксические ошибки, проводящие к тому что шаблон не работает;
  
• ошибки в именах узлов и атрибутов обрабатываемого XML-документа, приводящие к тому что шаблон работает, но нужные данные не выводятся;
  
• неочевидные ошибки логики кода - когда шаблон генерирует правильный html-код, но делает это нерационально и создает паразитную нагрузку на сервер.
  

Первые два случая вы так или иначе поборете сами, потому что в ином случае результат вас категорически не устроит, а третий вы, я предполагаю, просто не заметите, либо проигнорируете, судя по вашим отзывам о нагрузке создаваемой sql-оператором like.

Простите, прошлым сообщением просто попытался пошутить. Не исключено, что неудачно.

Касаемо же like .. понимаю, что Вам до этого никакого дела нет, но я уверен на 110%, что он там паразитной нагрузки не создаст, ибо фильтры эти пресловутые со списком на который мне жалко денег используются только в одном из 2х десятков раздела магазина.. И хорошо, если у этого магазина будет хотя бы 100 посетителей в день (и 10% из них потенциальных покупателей).
Будь этот проект несколько серьезнее, то я бы и на лицензию не жался и о рациональности SQL запросов задумывался бы.
А самое главное, этот like там придумали до меня и по задумке разработчика он там используется через поле ввода input. И ввести туда можно что угодно. Надеюсь, что ограничения там какие-то есть, хотя бы по длине строки + защита от SQL инъекций, но уж точно фиксированный select ничем на его месте не хуже.

PSin, я вашу шутку оценил Но ответил серьезно.

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


PSin писал(а):

Надеюсь, что ограничения там какие-то есть, хотя бы по длине строки + защита от SQL инъекций

Есть, не сомневайтесь!

Kotoff, замечательно, что мы хоть где-то пришли к общему мнению Осталось только теперь дождаться альтруиста, который доточит "возврат" уже выбранной опции обратно в select, чтобы он не очищался после нажатия кнопки активации фильтра "Применить". И, что-то мне подсказывает, что я сам и буду этим альтруистом У меня все равно другого выхода нет, как Вы правильно подметили.