Ну, девелоперы, колитесь!

[Flying]

Автор оригинала: Dexter
To Flying:

ну что-же... выглядит убедительно.
Не скажу, что сдаюсь, но и не чуствую теперь полного превосходства IE

Уже прогресс

Мой комментарий такой. IE мне кажется легко закроет пробелы в том что касается отставания в поодержке стандартов.

Вполне возможно. Но проблемы с теми же CSS1 как появились в IE4.0, так и остались в последних билдах IE6.0... Так что не похоже, что они торопятся это исправлять.

NN c неохотой и со скрипом принял некоторые синтаксические конструкции IE (тот же iframe ).

Вообще-то <IFRAME> - это стандарт HTML 4.0:
http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME

Только ребята из IE свои дыры лотают гораздо быстрее и качественне чем NN. Так было много раз.. из поддержкой JS и многое другое...

Если честно - практика показывает обратное. Есть масса примеров, когда серьезные и даже критические дыры в защите IE (особенно в IE6) латались по нескольку месяцев. В то же время самая громкая "дыра" в Mozilla была закрыта за 2 дня. Open source всегда быстрее реагирует на сообщения о багах. Если интересно - можешь посмотреть этот процесс "вживую" - http://bugzilla.mozilla.org
M$ никогда тебе не откроет своих bug tracker'ов, поэтому ты и не знаешь, насколько дыряв и глючен IE и что, кем, когда и как делается для исправления всего этого. А здесь все открыто: нашел баг - сообщил о нем - принял посильное участие в решении проблемы - все, ошибка исправлена.

Сделают все и своего новенького добавят.
Пока NN сделал PNG - IE VML юзает... там фишки покруче можно нарисовать... и прямо в тексте ...

PNG - это открытый и общепризнанный стандарт в графике. В растровой, заметь, графике, а не в векторной, к которой относится VML. Так что сравнивать их нельзя.
Кроме того, ты очевидно не совсем в курсе дел...
1. VML так никогда и не дошел до статуса W3C Recommendation, остановившись на W3C Note. И случилось это в далеком 1998-м году. Вывод: VML - мертворожденное дитя от M$ (посмотри на список авторов этого "стандарта"): http://www.w3.org/TR/NOTE-VML
2. Очень советую посмотреть вот это письмо:
http://lists.w3.org/Archives/Public/www-svg/2000May/0034.html
особенно второй параграф - все четко и ясно.
3. Ты, наверное, не слышал о такой вещи как SVG (Scalable Vector Graphics)? Если нет - много потерял, советую ознакомиться: http://www.w3.org/Graphics/SVG/
Думаю ты сможешь понять, что это намного больше, чем VML. А после того, как ты это поймешь - зайди вот сюда: http://www.mozilla.org/projects/svg/ и почитай про native implementation of SVG in Mozilla. Надеюсь не нужно объяснять принципиальной разницы между реализацией поддержки SVG в виде plug-in и встроенной поддержки? На той же странице есть и screenshot'ы из Mozilla, собранной с поддержкой SVG (по умолчанию эта поддержка еще не включается, т.к. не доделана).
Кроме SVG в Mozilla есть (причем готовая) поддержка MathML. Посмотри, если интересно:
http://www.mozilla.org/projects/mathml/
http://www.mozilla.org/projects/mathml/demo/basics.xhtml

В общем мысль моя проста:
Мощьность разработчиков M$ позволит легко достойно ответить.

Мощность-то позволяет, вот только не видно что-то ее в действии...

Почаще теперь буду NN7 запускать... посмотрю как он в деле.

Лучше возьми Mozilla - NN7 пока слишком нестабилен, а ядро у него такое же, как у стабильной Mozilla 1.0. Да и новые версии Mozilla появляются намного чаще и всякие новые фичи намного раньше появляются.

свои демо pages для сравнения NN7 и IE6 - будут завтра.
Покажу разницу обычного HTML парсера..

Хорошо, посмотрим

 

[Rynor]

2 года назад наша студия начинала работу, ориентированная исключительно на микрософт (IIS/ASP)
теперь идет переход на Linux/Apache/CASP/PHP/etc
почему?
потому что не хочется стоять в позе вместе с микрософтами
ASP.NET - это нет слов, среагировали на Java через несколько лет
боюсь, что подобное разочарование может наступить и в отношении IE
сейчас я его считаю лучшим браузером, но усилия Opera и Mozilla уже весьма заметны

 

[nail]

Во-первых, где ты видел сервер Java приложений без JDK ? Во-вторых, чем не подходит совершенно стандартный javac, который входит в JDK ? В-третьих, Resin, например, имеет встроенный Java-компилятор. В-четвертых, application server (Resin, Tomcat) умеет автоматом компилировать изменившиеся JSP и сервлеты (хотя я наприме этим не пользуюсь, держу исходники в отдельном дереве и использую make).
Так что M$ ничего нового не придумала. А поддержка нескольких языков нафиг не нужна на самом деле.

Автор оригинала: webdeveloper
А на джаве так компилируются только JSP файлы. Для компиляции сервлетов нужен нормальный компилятор. IBM Visual Age or JBuilder or Visual Cafe или еще что нито. Но самое приятное это то, что вся компиляция происходит автоматически. Тебе и делать то ничего не нужно. А в JSP это целая история. Скомпилировал сервлет, положи его на сервер, перезапусти сервер....

 

[Rynor]

я поработал с JSP немного, чтобы пощупать технологию
Tomcat - круто
всё так как пишет nail
Open Community решает вообщем

 

[Crazy]

особенно, если учесть, что разработки в этой области оплачивает не только "Open Community", а ряд весьма серьезных фирм.

 

[crow]

уже полтора года юзаем и постоянно совершенствуем "доморощенную систему управления контентом"

сейчас ядро системы представляет собой
редактор структуры сайта + редактор страниц, основанный на contentEditable, единой темлейтной структуре и множество модулей, таких, как:

• Управление пользователями
• Каталог
• Корзина и оформление заказа(или заявки)
• Новости
• Голосования
• Поиск по базе
• Форум

Все модули конфигурируются либо на лету (во время подключения модулей, либо из файла конфигурации, написаного в XML.

 

[crow]

Автор оригинала: Poltergeist
Народ, объясните мне такую вещь. Зачем пользоваться темплейтами, если можно загонять нужный элемент(меню например) в переменную типа $menu, а далее в нужном месте
<? echo $menu; ?> .
Я просто не могу Вас понять, Вы то кричите что PHP тормозно работает, то используете технологии, написанные на том же "тормозном"(это с Вашей же точки зрения) языке, и соответственно еще более "тормозные". Объясните мне в чем суть таких разногласий?
По-моему - PHP это уже язык шаблонов (грубо), и мне он нравится потому, что я могу объяснить дизайнеру или верстальщику, что для вывода определенного элемента ему надо сделать так <? echo $element_name; ?>, а ему не надо думать, что происходит внутри.

намного удобнее дизайнеру или верстальщику использовать не <? echo $menu; ?>, а просто {menu}

 

[Crazy]

JFYI: подробную дискуссию на тему "кому как удобнее" злые люди перенести в Offtopic...

 

[Flying]

2 Dexter

Похоже не дождемся мы обещанных демонстраций....

 

[Poltergeist]

Автор оригинала: crow

намного удобнее дизайнеру или верстальщику использовать не <? echo $menu; ?>, а просто {menu}

В крайнем случае, если дизайнеру влом написать echo $..., то можно написать либо GetHeader(), либо GetTopMenu() и так далее.

Я не пойму, зачем изобретать велосипед. Если вы хотите показать, что круто пользуетесь ereg_replace, или можете написать свой язык программирования, то пишите его на c++, а зачем на интерпретируемом языке писать еще один интерпретируемый язык - мне непонятно.

 

[Dexter]

2 Flying

ОК ... прошу извинить, был реально загружен.

http://comanche.seanet.com/~lerik/demo.htm

Спавните в _ЛЮБОМ_ MSIE и сначала NN4.7
потом в последней мозилле.

Чтобы понять в чем разница - попробуйте растянуть окно - а потом сжать до первоначального размера.

И как прикажете с этим боротся....

 

[Dexter]

To Poltergeist

В крайнем случае, если дизайнеру влом написать echo $..., то можно написать либо GetHeader(), либо GetTopMenu() и так далее.

Попробую выдвинуть 1 причину.

В моем движке например HTML шаблон "режется" на зоны с помощью стандартных комментариев. типа &lt;-- H --&gt;

Чего я этим добиваюсь:
3 вещи.
1. Вводится понятие "точек разрыва". Т.е. не {menu} или GetTopMenu(), а просто точка разрыва в которую я могу запихивить в зависимости от ситуации или menu или banner или пустоту. И решается это не HTML шаблоне а во внешнем ядре движка. - свобода полная.
2. При работе с шаблонами для наполнения часто возникает необходимость исп. стили и т.п. Так вот по вашей идее внутренний шаблон (напримеп просто новостная таблица) должен быть Include целиком... А нахрена там мусор типа повторных обьявлений стилеи и всяких Head и body по второму разу???. В моей системе верзняя и нижняя части просто отсекаются и при сборке получаем чистый HTML.
3. Удобство при создании самих шаблонов. Дизайнер в моем проекте работает в сврей дирректории. (inc) он может использовать графику из поддеррикторий этой папки. и ссылки на любые стилевыйе и JS внешние файлы. Он может исп. FP или DW для создания проэкта. Когда ему нужно сделать ссылку на раздел проэкта он прям и папки inc делает ссылку типа ../../about/ При работе движка - шаблон анализируется на предмет отностительных ссылок и они автоматичеки корректируются в зависимости от того в каком разделе движок использует этот шаблон. Корректируется ВСЕ ... начиная от src для графики и путей к JS файлпам.

Что мы в итоге достигаем..
1. Дизигнеру не нужно парится с нашими проблемами вааще! Он просто делает свою лаботу. в отведенном ему месте.
2. Мы получаем после сборки чистый НТМЛ котя при сборке участруют шаблоный разных уровней
( у меня 3 уровня).
3. мы используем шаблоны как нам заблагарассудится и не будем детать 2 HTML документа в которых вся разница в том что в оном написано {GetTopMenuType1()} а в другом {GetTopMenuType2)}. Захочет дезайнер внести изменения в дизайн... и похали по цепочке....
4. Программер может использовать шаблон где ему вздумается
захочет - в руте... а захочет в папке с 10-й степенью вложенности. Все ссылки буду корректны.

так что если хотите реального удобства от CMS без парсинга никуда. imho.

Допускаю, что вам нравится Ваша схема. Но я хочу добится в своей CMS максимально возможной унивирсальности для применения к любому дизайну и варировать любым функционалом...

 

[Flying]

Автор оригинала: Dexter
2 Flying

ОК ... прошу извинить, был реально загружен.

http://comanche.seanet.com/~lerik/demo.htm

Спавните в _ЛЮБОМ_ MSIE и сначала NN4.7
потом в последней мозилле.

Чтобы понять в чем разница - попробуйте растянуть окно - а потом сжать до первоначального размера.

И как прикажете с этим боротся....

Стандартными средствами - головой и руками Ну и еще спецификации перед этим прочитать.
При этом самое главное условие - прекратить пользоваться всяким дерьмом типа M$ FrontPage (в котором сделана эта страница, хорошо хоть не в Word'e). Меня особо прикололо вот это:

<span lang="ru">Как</span><span lang="en">&nbsp;</span><span lang="ru">бы</span><span lang="en">&nbsp;</span><span lang="ru">м</span>e<span lang="ru">ню.</span>

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

Теперь конкретно о том, как с этим бороться. Посмотри следующие файлы:
http://dom.natm.ru/test/original.html

Это твой оригинальный пример. На соответствие его стандартам HTML можешь проверить здесь: http://validator.w3.org/

http://dom.natm.ru/test/my1.html

Это мой вариант того же кода с исправленной ошибкой. Посмотри его в тех браузерах, о которых ты говорил и убедись, что проблема не в них, а в твоем коде. Однако он тоже не проходит валидацию.

http://dom.natm.ru/test/my2.html

Это тот же код, но написанный в соответствии со стандартами W3C. Если интересно - проверь его через валидатор, это корректный HTML 4.01.

http://dom.natm.ru/test/my3.html

Это опять тот же код, но с DOCTYPE, который заставляет Mozilla переключиться в Standards compliance mode. Как ты можешь заметить - высота таблицы уменьшилась. Почему это происходит - можешь посмотреть здесь:
http://www.w3.org/TR/REC-CSS2/tables.html#height-layout

Ну как, еще примеры "глюков" Mozilla будут?

 

[Dexter]

To Flying

Прежде всего спасибо за предельно четкий и хорошо аргументированный ответ.

Далее немного "лирики"

Да.... говорила мне мама... учи английский.

очень оказывается умные книжки есть в инете.

Главное что я понял, своим коротким умом - это то, что параметр height для таблиц как бы теперь вне закона по новым стандартам и если хочешь его использовать, то давай дуй писать CSS для кажной таблицы, иначе валидатор скажет сорри... Не оченть то удобно если таблиц моно и они разные... И вообще ... без CSS терь шагу не ступить?

Да ... при таких стандартах FP не выживет.

А если серьезно... то я конечно понял насколько несерьезно относился к HTML вообще. Навено это потому .. что ребята из мозиллы не сделали достаточно мощьного визивиг HTML редактора. (NN Gold - rulez!!!). Отсюда все мои беды.
Когда верстаешь в сжатые сроки большие таблицы.. то в FP это лелать не то чтобы эффективно.. а оч. эффективно.

Выводы: Впечатлен... но интересное дело.... в теории все понятно... Но я хочу посмотреть на это с другой стороны.
До войны Henkel - был самый передовой истребитель... чудеса показывал в воздухе... но когда война началась... выяснилось, что сложная система трубопроводов в крыле не любит, когда в нее пули попадают... Непигоден оказался для реальных боевых действий. Мне кажется, что есть много других причин (помимо следования стандартам), которые делают програмный продукт или подход популярными. Я не хочу сейчас осанавливаться на деталях которые способствовали мнению, что с M$ удобно и мощно, я хочу сказать что эти факторы несомненно есть. При этом всегда есть тесты и подходы доказывающие обратное. Давайте вспомним историю с OS/2... и тд.. и тп... Я лишь процитирую Гегеля "Что действительно - то верно".

А действительность такова - что большинство разаботчиков веб гораздо более недовольны NN чем IE ... это действительность.

Какой бы Вы купили автомобиль, который ездит толко на АИ-98 или тот который побарабану чем заправлять (в нем есть система, используя автомобильную терминологию, "коррекции актанового числа")?

Что касается

Ну как, еще примеры "глюков" Mozilla будут?

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

То что мне это ужастся - даю теперь процентов 50. Помите "День сурка", чем больше "влезаю" тем меньше уверенность.

 

[Flying]

Автор оригинала: Dexter
To Flying

Прежде всего спасибо за предельно четкий и хорошо аргументированный ответ.

Главное что я понял, своим коротким умом - это то, что параметр height для таблиц как бы теперь вне закона по новым стандартам и если хочешь его использовать, то давай дуй писать CSS для кажной таблицы, иначе валидатор скажет сорри... Не оченть то удобно если таблиц моно и они разные... И вообще ... без CSS терь шагу не ступить?

Ну здесь ситувция такова: если ты посмотришь на спецификацию HTML 4.0, то увидишь, что у таблицы вообще нет такого аттрибута - height. Т.е. раньше он был, а теперь убрали. Но браузеры для совместимости его еще пока поддерживают (хотя Mozilla в режиме standards compliance - нет). А насчет CSS, то да, без него никуда. Да и с ним намного удобнее, проще и гибче. Ради интереса советую взять Mozilla и зайти вот сюда:
http://www.mozilla.org/start/1.0/demos.html
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
И попробовать выбрать различные стили View -> Use style. Тогда поймешь, о чем я.

Да ... при таких стандартах FP не выживет.

А если серьезно... то я конечно понял насколько несерьезно относился к HTML вообще. Навено это потому .. что ребята из мозиллы не сделали достаточно мощьного визивиг HTML редактора. (NN Gold - rulez!!!). Отсюда все мои беды.
Когда верстаешь в сжатые сроки большие таблицы.. то в FP это лелать не то чтобы эффективно.. а оч. эффективно.

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

Выводы: Впечатлен... но интересное дело.... в теории все понятно... Но я хочу посмотреть на это с другой стороны.
[про истребитель скипнуто]

А действительность такова - что большинство разаботчиков веб гораздо более недовольны NN чем IE ... это действительность.

Пожалуйста, не забывай указывать версию номер 4 после букв NN

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

Будем ждать

То что мне это ужастся - даю теперь процентов 50. Помите "День сурка", чем больше "влезаю" тем меньше уверенность.

 

[defresto]

СМС а оно нам надо?

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

Вобщем енту структуру я и хочу навязывать всем программистам с которыми буду в будущем работать, если видите ошибки или не согласны по каким-то моментам буду очень рад коментам (особенно негативным). Эта структура родилась после того как я окончательно задолбался объяснять каждому новому программеру как старая супер смс работает и где там собака порылась... При использовании данной структуры удалось потратить по 4 часа на каждую локализацию достаточно сложного проектика.

У меня сложилось впечатление, что все эти CMS фигня полная и лучше пхп-инклюд ничего нет. Мне как ламмеру и кодировщикам и дизайнерам отредактировать инк файл не проблема, а вот разбираться в супер мощном CMS движке...

Я как не программист нехочу крутой движок я хочу систему позволяющую легко вносить изменения и локализовать сайты. Что думаете? Достаточно ли то что я описал? Допустил ли я ошибку которая будет сильно тормазить работу? (например слишком много инклюдов)
.............................

З.Ы. Сорри что оффтопик
Очень нужен человек, который поможет переехать на новый сервер (настроить его, вычистить ошибки). Естественно не безвозмездно Вообще работы хватает так что если есть возможность работать удалённо и можете соблюдать сроки пишите е-мэйл в профиле. Лучше всего сразу ася

 

[Crazy]

Re: СМС а оно нам надо?

Автор оригинала: defresto

У меня сложилось впечатление, что все эти CMS фигня полная и лучше пхп-инклюд ничего нет.

Это означает, что тебе CMS и не требуется. В настоящее время.

 

[defresto]

Re: Re: СМС а оно нам надо?

Originally posted by Crazy

Это означает, что тебе CMS и не требуется. В настоящее время.

Ещё как надо... Просто с ними столько гемора, что не вижу лучшего способа, чем делать втопорную инклюд

 

[webdeveloper]

Re: СМС а оно нам надо?

Автор оригинала: defresto
Я читал массу форумов посвящённых проблеме использования
CMS... Несколько раз пытался использовать... Я не программист я менеджер так, что уж сорри если совсем уж ламмерское мнение:
Пришёл к выводу, что лучшего метода чем:
- сделать один пхп-файл
- через инк вставлять темплэйт.инк с нужной структурой
- вставлять необходимые инки меню, баннеры и т.д. в места определённые темплейтом
- код нужной страницы вставлять инклюдом в место определённое темплэйтом
- использовать библиотеку с основными функциями
- использовать библиотеку с системными сообщениями и надписями для облегчения перевода на другие языки

Вобщем енту структуру я и хочу навязывать всем программистам с которыми буду в будущем работать, если видите ошибки или не согласны по каким-то моментам буду очень рад коментам
...

Все что здесь написано это полная ерунда. Это все равно что сказать - мне не нравятся автомобили и всем моим сотрудникам я буду навязывать лошадей. Ну или в крайнем случае пересадить всех с БМВ на Таврии.

Для каждого сайта нужно применять правильные технологии. То что перечислено выше это просто набор персональной странички Васи Пупкина. Технология определяется назначением сайта.

А то что трудно объяснять программерам - так нужно заставлять этих программеров документацию писать вовремя и грамотно.

 

[Crazy]

Re: Re: Re: СМС а оно нам надо?

Автор оригинала: defresto

Ещё как надо... Просто с ними столько гемора, что не вижу лучшего способа, чем делать втопорную инклюд

Отнюдь. Если вы готовы рассматривать такое решение как возможное в вашем проекте -- значит CMS вам все же не нужен. Вы к этому еще не готовы.