s0rr0w

Таких - не жалко. Зато можно приобрести новых, которые никогда не откажутся от удобства, которое им можно дать с современными технологиями.

Необходимость? С этого места поподробнее. Действительно разное отображение есть только в одном случае - верстку делал полный дилетант. Данные случаи я не рассматриваю вообще.

JS

«свободный триммер» в Google.

Можно без него обойтись. Самое смешное, что тайтлы для опшинов нормально работают в IE, FF, и нифига не работают в Opera10, Boogagl Chron, Safari <select title="select"> <option onmouseover="this.parentNode.title='aaa'" title="aaa">aaa</option> <option onmouseover="this.parentNode.title='bbb';">bbb</option> <option title="ccc">ccc</option> </select>

Сделать набор дивов, которые содержат картинки и имена. И менять их свойство display.

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

Страницы. Страницы бывают трех типов: статические (структурные), динамические и специальные (так и не понял, нафига они нужны) Статические страницы - обычные страницы, контент которых не зависит от каких-либо факторов Динамические - контент которых зависит от запрашиваемых параметров. Специальные - не знаю. Каждая страница - это набор глобальных контейнеров (по умолчанию - один), который встраивается в страницу. Глобальный контейнер наполняется контентом при помощи компонентов. Компонент может описывать разные структуры данных. Типичный пример компонентов: заголовок, текст + заголовок, список + заголовок, таблица, галлерея и так далее. Основная цель компонентов - не давать пользователю ломать дизайн страниц, который предусмотрен разработчиком. В текст нельзя вставить заголовок или картинку. Это можно сделать при помощи компонента. Фактически, пользователь лишен чудесного права что-то испоганить своим ужасным вкусом. Кроме компонентов есть так называемые инклуды. Инклуды нужны в основном для вставки их кода в каждую страницу. Например, хлебные крошки. Кроме инклудов есть еще контент-скрипты. Их цель - дать пользователю наполнять динамический контент, например новости, галлерею картинок, список файлов, отдельно от редактирования самой страницы. Страницы имеют версии. Это позволяет переключать различное отображение страниц вручную или по времени. Страницы имеют свои собственные настройки, которые позволяют работать с мультиязыковыми страницами или мета-данными. Экспорт-импорт данных Как я уже говорил, система позволяет быстро переносить все, что сделал разработчик, на хост. Это реализовано путем экспорта скриптов и данных в XML, и последующим импортом в новую систему. Статистика просмотра страниц Интегрирована прямо в систему. Удобно. Layout'ы страниц Страница может иметь свой собственный лейаут, позволяет использовать разное поведение для разных страниц. Может можно для скинов использовать, но не уверен что будет все просто. Работа с картинками Очень удобно сделано, хоть и с первого раза непонятно. Картинкам можно создавать разные версии. Допустим, два вида самбнейлов, которые могут использоваться в разных компонентах. Ресайз, кроп, мультиаплоадинг - все через интерфейс.

Будем считать за спам, сообщения удалять, пользователя банить.

Код там местами древний, его не переписывали. Иногда попадаются sql-вставки. http://www.phenotype-cms.com/wiki/api-start Лично я в код сильно не вчитывался. Изучив структуру базы чуть более детально, я нашел там много позитивных моментов. Да, реализация еще хромает, но там есть позитив. Посмотри на их API, ссылку выше привел. Там есть ряд моментов, которые ты реализовал фильтром. Компоненты, которые вставляются в страницу для наполнения контентом - специфические, т.е. выполняют строгую задачу. Это я и хотел тебе показать. Изучай. Это полезно. Я не ковырял битрикс, там вроде тоже неплохо продумано все, но фенотайп - единственный CMF, который мне понравился за последние три года. Идеи, которые там используются не студентов-разработчиков. Реализация хромает, не спорю, но идеи - классные. Думаю, без проблем. Понятно ровно настолько, насколько ты сам сделаешь это. Переносимость сделана в фетотайпе на 4+. Пока что, лучше решения я не видел на рынке. Если интересно, могу составить краткий экскурс в фичи фенотайпа.

В том же фенотайпе это реализовано лучше и продуманнее. Не очень то понятно, что это раздел для SEO. Да и кто мешает рядом еще один таб сделать? Ты про это знаешь, так как ты разработчик. Пользователю это вообще не очевидно. Это не очевидно без прочтения документации. Если ты используешь одно поведение для всего интерфейса, старайся использовать всего одно поведение. Тогда людям будет проще разобраться, что можно делать в этом модуле, а что - нет. И за это я ненавижу эти две системы. Натянуть новый скин без танцев с бубном - нереально. Это еще та глупость. Ну, раз так, то тогда ок. Фенотайп мне нравится. Там есть абстракции и на уровне базы, и на уровне кода. Можешь посмотреть знаменитые ПХП фреймворки, просто почерпнуть оттуда идеи. С первого взгляда я не выявил.

css свойство background

JRE ставится вместе с Опенофисом. Да и чаты всякие и какие-то микропрограммулины могут требовать JRE.

Если у него хватит мудрости понять то, что мы не хотим его обидеть, а хотим сделать продукт лучше, то он должен послушать нас и сделать так, как ему будет нужно, или с его точки зрения правильным. Лет 8 назад я тоже остро реагировал на критику. Но однажды меня так натолкали носом, что я на всю жизнь запомнил.

Систему стоит рассматривать с нескольких сторон. С точки зрения пользователя системы: 1. Редактирование страницы. Что за фильтр? Что это дает? Какую задачу решает? Есть метаданные у страницы. Это вроде как служебная информация. Тогда почему бы туда не занести еще и инфу про Layout, Page Type и т.д. Контент отдельно, настройка свойств страниц - отдельно. Дополнительные контейнеры для редактирования. Нет вообще понимания, как дополнительный контент попадет на страницу. Вот с этим у меня вообще ступор. Login: [_____|v] [ ] Protected Если траница защищена, то как она может не требовать логина? Стремное поведение какое-то. Да и layout раздела Pages отличается от того же Files 2. Темплейтирование. Использование вставок php считаю прошлым веком. Читабельность кода никакая, для редактирования потребуются серьезные знания пхп, что для простого пользователя может стать серьезной проблемой. 3. Раздел Files Вообще непонятно, что там делают пермишины. Дырка в систему? Пользователь должен сам догадаться, что есть 777, что есть 755? Бред какой-то. Что вообще отсутствует Визитки зачастую делаются мультиязыковыми. Как это реализовать? Как дела обстоят с локализацией самого интерфейса? Программерская часть SQL размазан тонким слоем по всему коду. Этот подход несколько устарел уже. Это приводит к дыркам в систему, sql-инъекциям, куче других проблем. Темплейтирование сниплетов, плагинов? Как для каждого плагина сделать свой дизайн? Остальное Иван уже подметил.

Как раз является. Онклик исполняется от имени ноды, в ее контексте.

Ну не про деревянные же

Посмотрел. CMS на слабую троечку.

А зачем он нужен? Вот какой в нем смысл? Ах да, некий сакральный смысл, чтобы одинаково смотрелось.... Так это нереально вообще, каждый браузер будет показывать по своему. Ты ведь лучше него знаешь, как собирать страницы, иначе он бы к тебе не обратился с заказом. Раз обратился - путь будет добр, не указывать тебе, что лучше и что хуже. Потому что сайты делаются не для заказчиков, а для потребителей. Был у меня случай. Меня попросили сделать все так, как нарисовано в фотошопе. Я сказал, ок. Потратил два очень важных дня на маргинальные переделки, после чего мне сказали, что лучше я буду делать это так, как мне хочется, потому что сроки поджимают. Заказчик очень быстро выбирает между деньгами, которые он теряет, если ему хочется довести все до маразма, и когда он просто доверяет человеку сделать свою работу. В последнее время я все паддинги и марджины на глаз ставил... Никогда их не меряю линейкой в фотошопе. И ни один заказчик не пожаловался на то, что оно выглядит не так. Если вы подстраиваетесь под заказчика, то вы кодер-смертник. Подстраивайте заказчика под себя.

JRE нужно

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

Заказчик это будет оценивать только тогда, когда его цель - не заплатить тебе деньги. В противном случае заказчику глубоко фиолетово.

А кто это оценит? Пользователи? Им все равно, они ведь используют только ОДИН продукт.

Зачем? Они по умолчанию очень неплохо смотрятся. Да, пусть и по-разному, но люди привыкли к такому уже. Ну и что что они разные, эти отступы? Зачем их убирать, обнулять, переопределять? Это не источник проблем. Главный источник проблем - пустота в голове кодера в том месте, где должны быть знания css. Мдаааа... советы один "круче" другого. Люди не зря придумали margin'ы и padding'и отдельно. Главное - использовать их с умом, а для этого нужно выучить матчасть для начала.

IE6 и IE5.5 очень незначительно отличаются.