Ставите в одну скобку два условия через && - если первое по порядку не выполняется, то второе уже не проверяется (и не выдаст ошибку)
ProLiant, про кандидат забудьте - не развивается уже давно. Но попробуйте посмотреть в сторону сборок It (был там такой пользователь, делал свои сборки на основе кандидата) - он вроде планировал ввести индексирование статей.
На оригинальном кандидате делать перелинковку можно только после основательного допиливания. Можете обращаться, кстати - я когда-то занимался саппортом на их форуме. Но лично мой вам совет - берите MODx и будет вам счастье.
LEOnidUKG, потому, что язык не строго типизированный.
И конкретно строку можно представить в виде одномерного массива. Одномерного. Отсюда ошибка, когда глубже обратиться пытаются. Пример из 15го поста как раз это иллюстрирует хорошо. В новой версии, судя по всему, решили автоприведение типов поставить на новые рельсы.
Алексей Барыкин, TaediumVitae, извините, погорячился. На 9ку уже обновился, а мыслями застрял на 8ке.
богоносец, с аргументом, "чем короче, тем лучше" я не спорю - безаппеляционно признаю.
(я CMSку разрабатываю для малых информационных сайтов на файловой основе. И структура адреса повторяет структуру статейных каталогов с файлами-статьями... теперь, думаю, вам понятнее, откуда ноги растут :) у такого подхода есть свои преимущества и недостатки, но не об этом сейчас)
В принципе... вот уже сегодня, без пелены фанатизма и на свежую голову, мне кажется бессмысленным сопротивляться. Как бы... против лома не попрешь - "чем короче адрес, тем лучше". Хотя, в сохранении иерархии в адресе есть своя логическая завершенность, целостность системы.
Ну и так, в качестве флейма, так как спор на этом можно завершить :)
По поводу множественности родителей... уфф.. такая шляпа с этим. Я однажды фотогаллерею делал с множественными родителями - там такая морока с тем, чтобы построить дерево разделов! Или чтобы удалить какую-то группу фотографий, приходится делать 101у проверку, а не является ли вложенная в группу картинка зеркалом? и так далее... мороки много.. и когда я наконец реализовал всю задумку в полной мере, то оказалось, что все пожелания заказчика ну оооочень просто можно реализовать самой обычной галереей без множественности родителей, с линейной иерархией. В общем, забил я на это дело. Так и лежит тот модуль единожды опробованным.
Плохо. Согласен.
Не-не, про ?лишний=параметр я не говорил. Это мы помним, блюдем и стараемся избегать.
На счет иерархии в самом адресе - с точки зрения программиста это вполне логично. С точки зрения SEOшника - это беспредел, особенно когда речь за ходит о третьем и больше уровне вложенности. Тут, как бы.. у каждого своя правда. Но, выше я согласился, правильнее будет встать на сторону SEO ибо, в конечном итоге, именно для продвижения и рекламы (содержимого сайта) и создается сам сайт (коммерческий сайт).
Не уверен, что я понял ваш аргумент.. просто в своем движке я без раздумий на несуществующий адрес показываю специальную страницу с соотв.кодом ответа 404... для меня это вообще не было вопросом. Поэтому я не совсем понимаю причин возникновения дублей... ну, наверное, речь идет о криворукой.. или не криворукой, а просто с недостатком системе.. вот хз.. мне не до конца этот момент понятен.
Вот-вот. Вы меня понимаете)
Кстати, да.. умеют.. просто вложенность по адресу, скорее, не для поисковиков, а для пользователя..
Кстати, давайте еще немного пофлеймим (не совсем по теме).
Сейчас планируется архитектура другого специфичного движка. И, скорее всего, с учетом всех ваших аргументов, я откажусь от иерархии в адресе. Постараюсь все адреса делать первого уровня вложенности. Но тут неизбежно возникает загвоздка - повторение адресов. Движок будет что-то вроде форумного. ЧПУ является обязательным. Следовательно, адрес имеет смысл формировать по теме топика (транслитерировать). Но даже в этом случае адреса страниц могут повторяться, так как могут повторяться названия топиков. И есть такая мысль, которую я предлагаю обсудить - в случае неуникальности адреса страницы приписывать в конец адреса какую-то фразу из словаря... или, возможно, не просто из словаря, а из списка ключевых слов по сайту.. или не по сайту, а свойственных текущему разделу "типа форума".. как вам такая мысль? burunduk, что скажете?
Ииии? :)
8ка основные (читать как популярные) свойства CSS3 понимает. И, как бы, не лучше и не хуже остальных, которые тоже понимаю плюс-минус только популярные (и часто только с префиксами).
Как бы.. и согласен, и нет. Есть еще аргумент, что хаки адаптации под ИЕ7 занимают на 50% больше времени (ну так, с запасом)) и что верстка будет стоить на 50% дороже.. и аналогично для ИЕ6, только процент можно по-больше взять :) и вроде бы даже действует. И тут же, если вдруг сомневается, можно какую-нибудь статистику показать, в которой ИЕ6 уже нет, а процент присутствия ИЕ7 пренебрежимо мал.
fooger, аа... вот оно как..
Просто, я все равно не понимаю смысла такой AJAXовости, если страница все равно целиком перезагружается. Или не целиком? (пощупать то нечего)
Thommy, да никак не помешает.. ошибка то не выводится.. или ее просто нет :) не знаю даже.. больше пока ничего не могу сказать..
Может, может.
Не стоило упоминать, но упомянул и такой вариант, так как встречал его вживую. Актуально бывает в случаях с файловыми хранилищами, в качестве дополнительного инструмента "типа индексации". Не суть, просто пояснил, что такое тоже бывает. Вопрос оправданности - другой вопрос.
так показывают-же по разному. Для категории один метод со своими построениями, для страницы - другой.
Совершенно не обязательно. Доступность по нескольким адресам - это уже ошибка роутинга. А вот как вы реализуете произвольное количество категорий с произвольным уровнем вложенности? На каждую категорию создавать правило рерайта? И на подкатегорию в категории? ну не вручную же?
В общем, долго уже спорим.. правда не по теме уже. В общем, моя точка зрения такова, что категория и страница - это разные объекты, отличающиеся как минимум параметром типа и соответствующими этому типу обработчиками. Вы можете не соглашаться с этим - структуры данных разные бывают. Просто я считаю эту (описанную выше) более "привычной", "понятной", "традиционной" и вполне логичной. Что, замечу, никак не отрицает вашей схемы хранения и схемы иерархии объектов данных.
Thommy, кстати, arg.***.ru/img/preview.gif не найден..
