На каком языке создавать WEB-интерфейс?

Python. Либо Pylons, либо Django. Про Django мало что скажу, давно смотрел, не понравилась его монолитность и слишком навязчивый API для MVC, для простых случаев это подойдет а для сложных придется преодолевать препятствия.

Pylons - модульный, во главу угла поставлен WSGI, для маршрутизации URL'ов используется routes (аналог из RoR), позволяет использовать любой интерфейс к БД, практически любой template engine. Средства для MVC не регламентированы, с одной стороны придется попотеть и строить свой собственный, хотя ясен пень не с нуля. С другой стороны - максимальная гибкость.

А в целом, два фреймворка очень похожи.

Насчет RoR, чтобы не начинать холивар скажу две вещи.

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

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

Тут новая "проблема" вылезла - с меня затребовали обоснование применения WEB-интерфейса ВООБЩЕ. Какая, мол, разница, накидать в Builder-е кнопочек на форму и для IPC использовать именованные каналы, или делать WEB-интерфейс и работать через TCP-IP сокеты. Киньте сЦылку, где преимущества WEB-интерфейса расписываются "для начальника".

В-третьих, интерпретатор Ruby медленнее. Python из скриптовых языков один из самых быстрых. A Django, вроде, один из самых быстрых MVC фреймворков. Мне Django очень понравился.

Обоснования для начальников - это в другую ветку.

А в целом, мультиплатформенность, малое время разработки (надо ещё доказать), отсутствие необходимости дополнительной настройки клиентских машин.

> Во-вторых, руби разрабатывается жутким националистом. Я совершенно не противь национализма, но когда он начинает вредить общему делу, то пора что-то менять. Я конечно понимаю, что япония - "многовековая культура с древними традициями", но их отношение к уникоду просто поражает. Осталось только нам упереться рогом и заставить комитет включить "церковно-славянскую" кодировку, а египтянам их древние иероглифы.

Ну тут ты, вроде, не совсем прав. Говорят, юникод для японской лингвистики неприменим. И поэтому (справедливо почти) они считают себя обиженными и живут на своих традиционных многобайтных кодировках.

А церковно-славянские символы в юникоде есть, кажется (другой вопрос, если ли они в твоих шрифтах...). Чего б их не включить, благо их четыре десятка, а не три тысячи?

Преимущества веб-интерфейса

Переносимость. Работает на чем угодно, включая КПК и сотовые телефоны.

Быстрая развертываемость. Завести пользователя и дать ему ссылку, а то и интегрировать в интранетовский портал. Обновлять только на сервере, притом ОБНОВЛЯТЬ ПО МОЖЕТ СОВЕРШЕННО НЕПОДГОТОВЛЕННЫЙ ЧЕЛОВЕК! Либо через систему управления пакетов (в т.ч. и на винде), либо через питоновские egg'и. В случае, если возникли неотловленные косяки при обновлении, то элементарно откатываемся на старую версию.

Работота через интернет. Слышу вопросы "Что за на? Оно и так будет работать!" Отвечаю, понятие "интернет" характеризуется потерями и задержками. И очень многие программы которые отлично работают в ЛВС или в корпоративном интранете не будут работать или работать ооочень плохо через интернет, например через GPRS.

Высокая степень безопасности. Помимо аутентификации пользователей по SSL (именно пользователей, а не сервера т.е. поднимаешь свой ЦС и вперед) есть возможность защищать веб приложение маршрутизатором типа циски в т.ч. аутентификация через AD.

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

>Говорят, юникод для японской лингвистики неприменим.

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

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

От разработки веб-интерфейсов осталось сильное ощущение, что веб для интерфейса малопригоден...

> Переносимость. Работает на чем угодно, включая КПК и сотовые телефоны.

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

> ОБНОВЛЯТЬ ПО МОЖЕТ СОВЕРШЕННО НЕПОДГОТОВЛЕННЫЙ ЧЕЛОВЕК!

Э-э-э... А при чём тут веб?

> И очень многие программы которые отлично работают в ЛВС или в корпоративном интранете не будут работать или работать ооочень плохо через интернет, например через GPRS.

И к веб-интерфейсам это относится в той же степени.

> все вышеперечисленное основано на стандартных технологиях

Которые у всех работают по-своему.

> От разработки веб-интерфейсов осталось сильное ощущение, что веб для интерфейса малопригоден...

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

Кстати, а как у таких приложений обстоят дела со скоростью передачи данных клиент <--> сервер?

>На каком языке создавать WEB-интерфейс?
Если говорить про интерфейс, то язык будет один - JavaScript.
Рекомендую для клиента: http://www.extjs.ru/ и http://extjs.com/
Серверная часть может быть на чем угодно: JSP, PHP, те-же замечательные pylons.
Для отладки firefox+firebug.

>И главный оффтопичный браузер тебя заимеет.

Да? Мы же не быдлоинтернетмагазин пишем! В _корпоративной_ среде намного более реальным видится развитие событий, когда главный оффтопичный браузер будет поимет через групповые политики до полной импотенции...

А для мобильных устройств будет своя версия шаблонов.

>Э-э-э... А при чём тут веб?

Да не причем, блин.

>И к веб-интерфейсам это относится в той же степени.

Ты видимо не осознаешь, что я имею ввиду. Счастливый ты человек. У меня же имеется опыт использования такой программы через VPN до Москвы. Любой самый безобидный глюк канала и прогу начинает колбасить.

>Которые у всех работают по-своему.

А нафиг админы тогда нужны? Не винды же переустанавливать? Вот и пусть занимаются стандартизацией.

А без зоопарка языков на клиенте и сервере никак? Это нужно будет сделать быстро, опыта в подобных разработках у меня немногим больше нуля (именно в WEB-разработках).

1. WEB будет работать ВЕЗДЕ. на всех платформах, и из любой точки земного шарика. 2. Если делать Web интрефейс - не надо заморачиваться с сокетами. 3. Возможность легкого встраивания скинов. 4. Если AJAX - по скорости разницу не заметите.

Рекомендую asp.net (modmono работает прекрасно) + Anthem.NET AJAX. Работать будет под офтопом и unix без перекомпиляции, скорость близкая к нативной.

ЗЫ. шо щас будет... :)

> WEB будет работать ВЕЗДЕ

Только на одном и том же браузере, одной и той же версии. Что существенно снижает ценность этого "ВЕЗДЕ". Web-интерфейсы действительно быстро пишутся, тем более, что рисовать их должны дизайнеры, но разработчик имеет много секса с браузерной совместимостью. Причем грабли лежат в самых неожиданных местах, типа разных алгоритмов рисования элементов и рассчета их размеров в разных браузерах.

Плюс некоторые вещи, которые элементарно реализуются в графических интерфейсах, в случае Web'а приходится делать через задницу. Пример - подсветка некоторых слов в элементе ввода. HTML-ый элемент INPUT не поддерживает установку стилей для отдельных участков своего содержимого. Если не рассматривать вариант с собственными Active-X'ами (а для межбраузерной межплатформной работы мы не можем этот вариант рассматривать), то подобных граблей в сложном интерфейсе не мало.

Другая проблема - скорость. Не передачи данных, а работы самого интерфейса. Когда заходит речь об интерфейсе к данным большого объема (например, список из сотен тысяч/миллионов элементов), то начинаются мучения с динамической подгрузкой и прочей ерундой.

При чем тут зоопарк? Мало-мальски сложный интерфейс на Web-технологии требует JavaScript'а на браузерной стороне. А что уже будет на стороне сервера - выбирает разработчик. Хоть тот же JavaScript. У нас, к примеру, именно так и сделано - собственный Web-сервер и собственная реализация JavaScript'а для более-менее высокоуровневой логики, в т.ч. для генерации ответов браузеру.

>Пример - подсветка некоторых слов в элементе ввода. HTML-ый элемент INPUT не поддерживает установку стилей для отдельных участков своего содержимого. Если не рассматривать вариант с собственными Active-X'ами (а для межбраузерной межплатформной работы мы не можем этот вариант рассматривать), то подобных граблей в сложном интерфейсе не мало.

a: display: block; с обработкой события oclick() вполне спасёт отца русской демократии :D

s/a: display: block;/a {display: block;}/

> Только на одном и том же браузере, одной и той же версии

Это ж надо так уметь...

>Я даже помнится ставил и изучал, ничего экстраординарного не нашел

Тоже самое могу сказать о Django. Слово в слово)

Кому что ближе к телу.

З.Ы. А Pylons, как клон RoR - ненужен и вторичен

Я же не говорю, что приведенный пример совсем никак не реализуется. Реализуется, но с бОльшими затратами. Чем больше таких случаев, тем меньше ценность Web-технологии. Между тем, в сложном интерфейсе таких моментов много.

А тут уметь особо нечего. Поддержка JavaScript меняется от версии к версии (в случае IE, к примеру, довольно геморройно обеспечивать совместимость с версиями <5.5). Поддержка стандартов W3C различается между браузерами. Периодически вылезают неожиданные косяки в, казалось бы совершенно безобидных, местах вроде сложного форматирования с помощью таблиц. И многое другое.

Может всё-таки проблемы возникают от __незнания__ веб-технологий? Против веб-технологий не было выдвинуто ни одного__объективного__ возражения.

>Ну тут ты, вроде, не совсем прав. Говорят, юникод для японской лингвистики неприменим. И поэтому (справедливо почти) они считают себя обиженными и живут на своих традиционных многобайтных кодировках.

Какие проблемы с японским у utf-8? Вообще-то, 2^31 степени символов теоретических и 2^21 практических должно на все случаи жизни хватить. И на японский-то хватает...

>Реализуется, но с бОльшими затратами.

И где в данном случае бОльшие затраты? И на что эти затраты, на изучение спецификаций html и css? Так без изучения как раз и получаются вот такие перлы:

>Поддержка стандартов W3C различается между браузерами. Периодически вылезают неожиданные косяки в, казалось бы совершенно безобидных, местах вроде сложного форматирования с помощью таблиц.

Спецификация html нынче практически всеми браузерами поддерживается одинаково, косяки есть в реализации поддержки css со стороны зоопарка ИЕ, но и это решаемо. А сложное форматирование надо делать как раз с помощью css, в html делается только логическая структура документа.

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

"С академической целью добавлены многие исторические письменности, в том числе: руны, древнегреческая, египетские иероглифы, клинопись, письменность майя, этрусский алфавит."

Так что египетские иероглифы можно использовать легко.

Дело в том, что иероглифы на самом деле не являются символами в том же смысле, что в алфавитных языках, так как каждый иероглиф составляется из множества разных элементов, и перечислить все иероглифы невозможно, также как нельзя перечислить все слова русского языка. Есть даже живые носители китайских и японских фамилий, которых нельзя записать в юникоде.

Поэтому идеальная кодировка для китайских иероглифов и кандзи должна выглядеть примерно как скриптовый язык с командами начала и окончания символа и перечислением между ними всех его графических элементов. А идеальное представление в памяти — как массив указателей на описания символов.

В случае с юникодом проблемма не только в том, что там перечислено вполне определённое подмножество иероглифов (можно ли говорить по-русски с использованием только слов даже не из толковых словарей, а из какого-нибудь конкретного орфографического?), а в том, что для схожих японских, китайских и корейских иероглифов используются одни и те же позиции, и соответствующее начертание они принимают только в соответствующих шрифтах. Это примерно так же дискриминирует японцев, как дискриминировало бы нас, если бы в юникоде не было отдельных символов для русских букв А, В, Е, К, М, Н, О, Р, С, Х, а использовались бы соответствующие латинские (примерно как в KOI8).

>И на японский-то хватает...

Но японцы почему-то недовольны.

http://ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4

>Юникод предусматривает возможность разных начертаний одного и того же символа в зависимости от языка. Так, китайские иероглифы могут иметь разные начертания в китайском, японском (кандзи) и корейском (ханчча), но при этом в Юникоде обозначаться одним и тем же символом (так называемая CJK-унификация), хотя упрощённые и полные иероглифы всё же имеют разные коды. Часто возникают накладки, когда, например, японский текст выглядит «по-китайски».

>И где в данном случае бОльшие затраты?

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

>Спецификация html нынче практически всеми браузерами поддерживается одинаково

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

А динамическое форматирование (пользовательский интерфейс ведь, а не статические документы) таки удобнее с помощью HTML+JavaScript делать.

Меня интересует такая задача: Вот у меня есть 3 кривые по 1000000 точек. Как с помощью Web организовать отображение кривых? При этом все эти кривые должны масштабироватся. Также должны показыватся текущие значения на пересечени с вертикальной прямой проходящей через верхнюю левую точку курсора. Реально просто очень интересно как это будет реализовано через Web.

SVG?

А что, без Web-а это так просто сделать? SVG, в конце концов, сказали уже...

посмотрите Adobe Flex. Мы с его помощью решили аналогичную задачу, без особенных проблем.

Бегло посмотрел описание формата. Как я понял все 3000000 точек будут записаны в svg файл и переданы клиенту? Если так то нет никакой разницы использовать Web или простое ПО.

>Как я понял все 3000000 точек будут записаны в svg файл и переданы клиенту?

В SVG, как и в HTML, работает DOM. Соответственно, можно в зависимости от текущего масштаба подгружать нужные элементы (точки кривой) скриптом.

> В SVG, как и в HTML, работает DOM. Соответственно, можно в зависимости от текущего масштаба подгружать нужные элементы (точки кривой) скриптом.

Ну и в простом ПО(которое не Web) я тоже могу подгружать в зависимости от текущего масштаба нужные элементы(точки кривой).

А если нет разницы, то - что? И, кстати, где проще получится это проделывать - в простом ПО или в Web+DOM и другие страшные слова?

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

Мсье пользуется wysiwyg-редакторм? Сочувствую. В текстовом редакторе, что <input type=..., что <a href=... набрать примерно одинаково по затратам.

>Тем не менее, отрисовка происходит иногда по-разному. Да и говорил я в первую очередь о JavaScript. Так, на вскидку, вещи, для которых приходилось писать две версии кода - для IE и для остальных, - позиционирование каретки в элементах ввода, работа с событиями. Поддержка IE 5.0 и старше - отдельная песня.

Вообще говоря, при создании веб-клиента вполне можно плюнуть на весь этот зоопарк и ограничиться каким-либо одним браузером, на посещаемость это не повлияет :D, как в случае с открытым ресурсом. При этом, естественно, весь код должен соответствовать спецификациям.

>А динамическое форматирование (пользовательский интерфейс ведь, а не статические документы) таки удобнее с помощью HTML+JavaScript делать.

Что есть динамическое форматирование и каким боком javascript к нему привязан?

> Переносимость. Работает на чем угодно, включая КПК и сотовые телефоны.

Но не у всех есть поддержка ActiveX (КПК, Телефоны), Flash(КПК, Телефоны), SVG(КПК, Телефоны), JavaScript(КПК, Телефоны) итд. В принцыпе с таким же успехом можно использовать какие либо кроссплатформенные библиотеки. То есть я хочу сказать что там и там есть много граблей которые мы и должны преодалеть.

> Работота через интернет. Слышу вопросы "Что за на? Оно и так будет работать!" Отвечаю, понятие "интернет" характеризуется потерями и задержками. И очень многие программы которые отлично работают в ЛВС или в корпоративном интранете не будут работать или работать ооочень плохо через интернет, например через GPRS.

А точнее можно? При каких условиях можно добится лутьших результатов используя Web?

> Высокая степень безопасности. Помимо аутентификации пользователей по SSL (именно пользователей, а не сервера т.е. поднимаешь свой ЦС и вперед) есть возможность защищать веб приложение маршрутизатором типа циски в т.ч. аутентификация через AD.

Это легко реализовать и без Web т.к. есть соответствующие библиотеки.

Не флейма ради просто сам думаю использовать Web технологии и пока не вижу таких колосальных преимуществ.

>Но не у всех есть поддержка ActiveX

А нафига это нужно?

Ну да все можно сделать и без Flash, JavaScript, SVG, ActiveX итд. Но для более менее сложных задачь я думаю без этого не обойдтись. А если без этого не обойдтись то о какой переносимости может быть и реч.

> И самое главное, все вышеперечисленное основано на стандартных технологиях и работает "из коробки". Значит меньше затраты на разработку, меньше вероятность ошибок и т.д.

Не все КПК и телефоны поддерживают стол обширный стандарт

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

>Не все КПК и телефоны поддерживают стол обширный стандарт

А что заниматься разработкой отдельного клиента для телефонов или КПК проще, чем оптимизировать код веб-клиента? Какую-нибудь Оперу воткнуть можно практически на любой телефон и оптимизировать всё под неё.

>Мсье пользуется wysiwyg-редакторм?

Нет, конечно. Но я не очень понимаю, как <A> заменит <INPUT> без написания обработки событий от мыши и клавиатуры + рисование курсора. Может я не понял идеи? Как установка стиля отображения "блоком" превращает <A> в <INPUT>? Мне нужен полноценный элемент ввода текста с возможностью устанавливать разные стили для разных участков текста, введенного в этот элемент.

>Вообще говоря, при создании веб-клиента вполне можно плюнуть на весь этот зоопарк

Увы... Дело в том, что одна из основных задач - построение одного интерфейса для однопользовательской (объединенные в одном приложении браузер и Web-сервер), intranet и internet версий. Должны поддерживаться все популярные браузеры.

>Что есть динамическое форматирование

Это когда содержимое страницы меняет вид в ответ на действия пользователя.

Я просто хочу сказать что переносимость данного класса приложений(Web) не такая уж и грандиозная. То есть мне все равно нужно писать код под (КПК телефоны) отдельно.

>То есть мне все равно нужно писать код под (КПК телефоны) отдельно.

Написать дополнительную таблицу стилей для мобильных устройств и вставить строчку <link rel="stylesheet" type="text/css" media="handheld" href="handheld.css"> это так сложно?

Если ты о простых чатах форумах и какихто информационных сайтов то да лутьше наверное поступить именно так.

Да было бы все так просто. Не делал бы никто дополнительных линков на своих сайтах (КПК версия | смарт версия)

Хочу спросить а без всех этих JavaScript, Flash, SVG, ActiveX итд. на голом html+css можно написать пользовательский интерфейс для вот этого:

>Меня интересует такая задача: Вот у меня есть 3 кривые по 1000000 точек. Как с помощью Web организовать отображение кривых? При этом все эти кривые должны масштабироватся. Также должны показыватся текущие значения на пересечени с вертикальной прямой проходящей через верхнюю левую точку курсора. Реально просто очень интересно как это будет реализовано через Web. iDeveloper (*) (03.09.2007 23:24:05)