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

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

Обработчиком события от мыши будет атрибут onclick(), обработчиком события клавиатуры может стать тот же input с visibility: hidden, курсор мыши задаётся свойством css cursor, а установка стиля отображения блоком позволяет превратить его именно в блок, с заданными параметрами ширины, высоты и прочих атрибутов визуального форматирования, благодаря чему легко достижим внешний вид какой угодно кнопки. Внутри же элемента <a> текст можно форматировать как душе угодно.

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

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

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

Типа ajax что ли? И что там изобретать нужно?

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

Ога, а ещё делают версию для печати, вместо использования media="print". И о чём это говорит? Попробуй, для интереса, проверь такие поделия на validator.w3.org, сомневаюсь, что они пройдут валидацию. Всё от безграмотности.

> Ога, а ещё делают версию для печати, вместо использования media="print". И о чём это говорит? Попробуй, для интереса, проверь такие поделия на validator.w3.org, сомневаюсь, что они пройдут валидацию. Всё от безграмотности.

Было бы интересно на сайт который сделанн по данному принципу. Ты не мог бы дать линк? Очень хочется посмотреть.

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

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

А кто говорил, что такие задачи надо делать без привлечения JavaScript, Flash, SVG? Про ActiveX забудем сразу, как об убогом быдлоподелии. Что несёт эта кривая, кроме упрощения визуальной информации. Для браузеров, не поддерживающих вышеуказанные технологии можно выводить данные нужного диапазона в таблице, только и всего. Или это сложнее, чем сваять своего клиента для мобильных устройств?

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

Расскажи, плиз, как, КАК его заставить через групповые политики понимать :hover для чего-нибудь, кроме ссылок.

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

Значит, хреново прога написана. Хреново написать веб-интерфейс тоже несложно.

> Вот и пусть занимаются стандартизацией.

Стандартизация браузеров - дело прогеров, а не админов.

> У нас, к примеру, именно так и сделано - собственный Web-сервер и собственная реализация JavaScript'а для более-менее высокоуровневой логики, в т.ч. для генерации ответов браузеру.

Оно, случайно, не kodweb/KScript называется?

Спецификация html - это, мягко скажем, наименьшая часть веб-интерфейса.

> это так сложно?

Это так мало...

>А кто говорил, что такие задачи надо делать без привлечения JavaScript, Flash, SVG?

Тот кто кричал о грандиозной переносимости!!!

> Что несёт эта кривая, кроме упрощения визуальной информации.

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

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

В виде таблыцы да как два пальца об асфальт.

>>А кто говорил, что такие задачи надо делать без привлечения JavaScript, Flash, SVG?

>Тот кто кричал о грандиозной переносимости!!!

JavaScript, Flash, SVG - это неплохая переносимость.

Лови, заодно каие-то простейшие примеры использования media="print" есть.

http://meyerweb.com/eric/articles/webrev/200001.html

>Спецификация html - это, мягко скажем, наименьшая часть веб-интерфейса.

Конечно, только его серверная часть к вопросам переносимости отношения вообще не имеет.

>Это так мало...

А что ещё нужно-то?

Вопросы начинаются с CSS и JavaScript.

>Вопросы начинаются с CSS и JavaScript.

Там тоже есть спецификакции. Об их поддержке в конкретных браузерах:

http://developer.mozilla.org/, http://www.opera.com/docs/specs/

Про зоопарк ИЕ информация очень разрозненная.

> JavaScript, Flash, SVG - это неплохая переносимость. qt, gtk, ruby, python, tcl/tk итд. тоже неплохо переносятся.

Но все это не 100% переносимость.

>Обработчиком события от мыши будет атрибут onclick(), обработчиком события клавиатуры может стать тот же input с visibility: hidden, курсор мыши задаётся свойством css cursor, а установка стиля отображения блоком позволяет превратить его именно в блок, с заданными параметрами ширины, высоты и прочих атрибутов визуального форматирования, благодаря чему легко достижим внешний вид какой угодно кнопки. Внутри же элемента <a> текст можно форматировать как душе угодно

Да, я понял идею правильно. Только вот речь идет о точном воссоздании поведения <INPUT TYPE=text>, т.е. еще надо как-то придумать рисование мигающего текстового курсора (я не о мышке говорил), двойной клик должен выделять целое слово, затем все строчку и т.д. Именно это я и понимаю под словами "бОльшие затраты".

>Это как это? Любой желающий из интернета входит и делает что хочет с данными?

Так ведь задачи бывают разные, не только разработка каких-то систем под конкретного заказчика. В данном случае имелась в виду не привязанная к заказчику система, которая может поставляться в нагрузку к информационному продукту (для работы с этим продуктом), причем может быть в разных воплощениях - однопользовательский вариант (должно выглядеть, как обычная программа), intranet - внутреннее решение, тут действительно можно ограничения на браузер накладывать, хотя разные заказчики хотят разного, в т.ч. и разных браузеров, internet - внешнее решение для организации публичного доступа к некоторой информации.

>Типа ajax что ли? И что там изобретать нужно?

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

>Лови, заодно каие-то простейшие примеры использования media="print" есть.

>http://meyerweb.com/eric/articles/webrev/200001.html

У крутых перцев тоже не все впорядке http://validator.w3.org./check?uri=http%3A%2F%2Fmeyerweb.com%2Feric%2Farticles% 2Fwebrev%2F200001%2Fexample1.html&charset=%28detect+automatically%29&doctype=Inl ine&group=0

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

>Ога, а ещё делают версию для печати, вместо использования media="print". И о чём это говорит? Попробуй, для интереса, проверь такие поделия на validator.w3.org, сомневаюсь, что они пройдут валидацию. Всё от безграмотности.

>Да, я понял идею правильно. Только вот речь идет о точном воссоздании поведения <INPUT TYPE=text>, т.е. еще надо как-то придумать рисование мигающего текстового курсора (я не о мышке говорил), двойной клик должен выделять целое слово, затем все строчку и т.д. Именно это я и понимаю под словами "бОльшие затраты".

Тебе ввод форматированного текста нужен что-ли? Так бы и говорил по-русски. Возьми готовый элемент из какой-нибудь открытой cms, типа joomla.

>Так ведь задачи бывают разные, не только разработка каких-то систем под конкретного заказчика.

Мы о чём говорим в этом топике, о конкретной задаче или о мировых проблемах сайтостроительства вообще?

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

Смеялсо. Именно для этой задачи более 10 лет назад придумали фреймы. Работало ещё в NN3 безо всяких левых захватов мышиного курсора.

>У крутых перцев тоже не все впорядке

Что у них не в порядке?

This Page Is Valid HTML 4.0 Transitional!

Result: Passed validation

вот этот Example1 скорми валидатору: http://meyerweb.com/eric/articles/webrev/200001/example1.html

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

>вот этот Example1 скорми валидатору

2 шибки в примере - это катастрофа :D

Кстати, только что сильно удивился, yandex стал валидным, даже Лебедев научился по стандартам делать

Предполагается на клиенте использовать графику, поля текстового ввода, кнопИчки и radiobutton всякие (может, и нестандартной формы), анимацию какую-нить, графикорисовалку с масштабированием и разноцветную :-), таблицы.

Внешний вид элементов форм регулируется с помощью css, а со всеми свистелками и перделками во Flash/SVG.

>Тебе ввод форматированного текста нужен что-ли

Нет. Нужен обычный элемент ввода типа <INPUT TYPE=text>, но с возможностью из браузерных скриптов менять стиль некоторых участков введенного в него текста.

>Мы о чём говорим в этом топике, о конкретной задаче или о мировых проблемах сайтостроительства вообще?

При чем тут сайтостроительство? Мы здесь говорим о замене графического интерфейса Web-интерфейсом в прикладных приложениях. Я, в частности, считаю некорректным заявление "работает везде, всегда, на любых платформах, под любыми браузерами" касательно мало-мальски сложного пользовательского интерфейса, а также считаю, что реализация мало-мальски сложного пользовательского интерфейса на базе Web'а может быть в некоторых деталях сложнее, чем на базе библиотек графических элементов. Вот и все.

>Именно для этой задачи более 10 лет назад придумали фреймы

Я в курсе насчет frameset. Не всегда удобно. И это самый простой пример, обычно в прикладных программах много более сложных интерфейсных вещей.

Разработка нормального Web-интерфейса трудна (в сравнении с граф. библиотеками) в принципе, или из-за относительной молодости самой темы?

Вот, уже начались грабли.

Зачем все эти извращения с Web интерфейсом клиента на ruby, python, или tcl/tk.

s/интерфейсом клиента/интерфейсом, пиши клиента/

В смысле "зачем с Web-интерфейсом", или "зачем с ruby, python etc..."? Да, и ещё, система будет управлять технологическим производством, но не real time.

Угу, понял, просто захотелось прояснить сильные и слабые стороны обоих решений.

>Нужен обычный элемент ввода типа <INPUT TYPE=text>, но с возможностью из браузерных скриптов менять стиль некоторых участков введенного в него текста.

То, о чём ты говоришь, как раз и есть ввод текста с возможностью его форматирования, или изменение стиля, по твоему к форматированию не относится?

>При чем тут сайтостроительство?

>>internet - внешнее решение для организации публичного доступа к некоторой информации

>"работает везде, всегда, на любых платформах, под любыми браузерами"

Именно так. Простой html отобразится на любой платформе. Этого достаточно для чтения и изменения информации. Всё остальное визуальное оформление находится на совести разработчика.

>Я в курсе насчет frameset. Не всегда удобно.

И когда неудобно? Примеры в студию.

Web-интерфейс тоже имеет свои преимущества, надо отдать ему должное. Дизайн интерфейса на базе Web'а быстро поменять значительно проще, чем на базе традиционных средств. И занимаются этим специально обученные дизайнеры, а не программисты.

Ну и сетевое взаимодействие во многом получаем готовое.

> Да, и ещё, система будет управлять технологическим производством, но не real time.

А что за производство если не секрет?

Выращивание монокристаллов.

>То, о чём ты говоришь, как раз и есть ввод текста с возможностью его форматирования

Обычно под "ввод текста с возможностью его форматирования" понимают какой-нибудь rich text edit. Здесь задачка немного другая. Но это не суть важно. Я имел в виду: средствами HTML/CSS/JavaScript сделать такой элемент существенно сложнее, чем вставить стандартный элемент. Можно позаимствовать готовое решение, но не на каждый случай можно найти хорошее готовое решение.

>Именно так. Простой html отобразится на любой платформе

Какое отношение "простой html" имеет к пользовательскому интерфейсу?

>И когда неудобно

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

>Какое отношение "простой html" имеет к пользовательскому интерфейсу?

А что по твоему есть пользовательский интерфейс?

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

Каких, например?

> Дизайн интерфейса на базе Web'а быстро поменять значительно проще, чем на базе традиционных средств

Перетащить элементы и поменять цвета, вы это имели ввиду? Если да то и в традиционных по это делается не долго.

> И занимаются этим специально обученные дизайнеры, а не программисты.

Дизайнеры пусть придумывают дизайн, а программисты воплощают в реальность.

> Ну и сетевое взаимодействие во многом получаем готовое.

Наверное. Но не для всего и вся, это нужно понимать.

>А что по твоему есть пользовательский интерфейс?

В общем случае - это набор интерактивных элементов управления и элементов отображения данных. То, что имеется в HTML - годится лишь для самых простых случаев (да даже такой простой случай, как диалог выбора файла с использованием набора вариантов расширений файлов, отличающихся от стандартного для браузера, нормально не решается). JavaScript и CSS позволяют создать нужные элементы в некоторых случаях, но далеко не всегда это получается сделать просто. Большинство средств графического интерфейса значительно богаче в этом плане.

>Каких, например?

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

>Перетащить элементы и поменять цвета

Когда начинают делать красивый интерфейс, тогда обычно каждый элемент начинает выглядеть весьма причудливо. И внешний вид его становится сделать проще на HTML/CSS. За последний месяц я наблюдал, как в проекте, в котором принимаю участие, дизайн поменялся трижды, причем визуально три разных версии не кажутся одним и тем же приложением. Квадратное стало круглым, круглое - квадратным, выпуклое - плоским, плоское - выпуклым, скрывающиеся/открывающиеся элементы по-разному выезжают/появляются/прячутся и т.д. Если бы не наличие хорошего Web-дизайнера, который все это рисовал, сделать даже одну такую версию внешнего вида было бы очень сложно.

> Когда начинают делать красивый интерфейс, тогда обычно каждый элемент начинает выглядеть весьма причудливо. И внешний вид его становится сделать проще на HTML/CSS. За последний месяц я наблюдал, как в проекте, в котором принимаю участие, дизайн поменялся трижды, причем визуально три разных версии не кажутся одним и тем же приложением. Квадратное стало круглым, круглое - квадратным, выпуклое - плоским, плоское - выпуклым, скрывающиеся/открывающиеся элементы по-разному выезжают/появляются/прячутся и т.д. Если бы не наличие хорошего Web-дизайнера, который все это рисовал, сделать даже одну такую версию внешнего вида было бы очень сложно.

Тоесть все элементуправления остались на месте но поменялся их вид?

>То, что имеется в HTML - годится лишь для самых простых случаев (да даже такой простой случай, как диалог выбора файла с использованием набора вариантов расширений файлов, отличающихся от стандартного для браузера, нормально не решается)

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

>Например, хочется менять относительные размеры двух элементов ввода внутри формы.

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

А Java уже не в моде?

Тут один товарищ спрашивал про отображение 1000...00 точек через браузер. Это делается легко через Java, насколько, вообще, может быть легко вывести такое огромное количество точек.

Тебя тут не поймут. Они только на Пэрле могут и на Си. Ну еще немного Лиспа и Хаскеля для понтов. Java быдлоязычок для быдлокодеров

>Тоесть все элементуправления остались на месте но поменялся их вид?

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

Да ну? По-моему, бред - это решать за пользователя что ему удобно, а что нет, чем следует заниматься, а чем - нет.

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

JavaScript != Web, JavaScript есть подмножество Web.

Никто не спорит что легко но также легко это реализовывается и в обычном ПО.

PS: А если нет разницы тогда зачем платить больше.

> Никто не спорит что легко но также легко это реализовывается и в обычном ПО.

Не понял сравнения. По-моему Java и есть обычное ПО для этой задачи. Например, Java applets успешно ее решали еще 10-12 лет назад. Лет 8 или около того появились Java Server Pages и Java Servlets.

В общем, классику жанра надо знать. А Java - это безусловно классика. Особенно в силу все возрастающей популярности решений на основе .NET, корни которого глубоко растут из той же Java, точнее ее ранней микрософтовской реализации.

Тем более, с таким никнеймом Java надо знать ;)

> Тем более, с таким никнеймом Java надо знать ;)

Это клеймо на вечно ;)