а какая, блин, разника тем, кто будет работать, MDI это или WWW интерфейс ??
какой поставите - такой и будет... первых пол часа будет непривычно а потом ничего.. привыкнут и не будут замечать разницы... так что используйте asp.net и не пожалеете..

> эта штука еще и требует сторонних компонент
и это то о C# ... не уж то при разработки под Win компоненты .Net (угадайте, кто производитель) считаются сторонними ?

ну Вы блин даёте ....

ну а серьёзно, если C# использоват для построения asp.net приложений то от клиентов ничего не надо кроме отобразить html и результат передать серверу.. ВСЁ!!

2ASCRUS:

> Речь шла о GUI-клиентах.
что есть в Вашем поняте GUI ?? и что есть признак GUI ?? то, что бы оно отображалось в графике... ??? так Вам напомнить, в каком режиме работает Windows ....

> Я что то как то не помню, что в CLR в комплекте есть тот же
> нормальный грид или отчетник.

признаки нормальности не приведены, но да ладно...
я смею утверждать, что есть ....


> Есть обрезанные версии продуктов, которые надо
> покупать за отдельные денюшки.
Мы с Вами точно говорим про одни и те же вещи ??
я говорю о .NET платформе ...
Или Вы говорите о другом или не знаете, о том, что .NET FrameWork SDK БЕСПЛАТНО качается с сайта одной небольшой и мягкой (если верить названию) софтверной компании ... и там есть всё, что бы Вы могли разрабатывать на этой платформе.. ну а хотите удобно разрабатывать - тогда "в кассу"... за всякими vs.net 2003 и т.д.


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

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

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

Вопрос на засыпку - а у вас в ASP.NET есть приличный грид (не статическая страничка с данными в виде таблицы) ?

Вы не поверите.. есть..
и создаётся она в том же самом бесплатном WebMatrix-е одни движением мышки... после этого можете его кустомайзить "под себя" (ну там цвета задавать, кол-во элементов на странице, названия колонок и т.д.) как хотите..

Кстати, Вы ASP.NET Starter Kits видели ? говорю сразу, что это примеры программирования на asp.net а не sql + asp.net ... т.е. некоторые вещи там с точки зрения sql можно улучшить.. но не их ставили задачу там продемонстрировать...

GUI клиент работает на ОС клиента, пользуется ее API, всеми возможностями и т.д. и т.п.

расскажите КАКИЕ возможности OS нужны клиенту.. да ещё и такие, что бы к ним в API лезть... я понимаю, ЧТО всё в итоге сводится к вызовам соотв. API ... но ведь не напрямую....

в моём понятии клиентская программа должна уметь что-либо отобразить на мониторе клиента и соотв. потом передать его действия на сервер (в оговорённых пределах, например координаты перемещения его мышки в 99.9% не нужны).... мне от клиента не нужно, например, эффективная работа с дисковым кэшэм под какую-то конкретную систему... меня устраивает то, что этим будет заниматся клиент, который есть в любой OS...

Web-клиент работает в браузере и соотвествующе изначально ограничивается рамками этого самого броузера.

вот и отлично.. я чётко знаю, что в 99% клиент без моего ведома ничего не запишем мне на диск, не сотрёт что не надо и т.д. (1% оставляю на баги)

Где виндовый клиент отрабатывает логику управления визуалом - на машине юзера.

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


Где программы написанные на ASP.NET отрабатывают логику - почти всю на сервере, легкую часть на машине юзера в виде того же JavaScript.

это при условии, что Вы это разрешили... всмысле на клиенте всякие скрипты.... если не разрешили - то всё на сервере.. особенно такую, как проверку правильности заполнения форм и т.д.

Кто получается трафик лишний гоняет туда сюда ?

сравним.. есть у меня клиент, написанный на delphi, который в один из моментов отображает список в 5K строк.. ( ну по построению работы нельзя отдать сразу меньше) ... а вот если бы я это реализовал на asp.net я бы всё это дело положил в грид и разделил бы на страницы... вот и считайте траффик.. а если Вы боитесь о трафике на обработку логики проверки на клиенте валидности введённых данных, то напомню о таком понятии, как кэширование... а именно о том, что файлы из директории "aspnet_client" кэшируются на клиенте (а перед этим и промежуточно на проксе для случаев использования приложений через интернет)

Виндовый клиент раз считал данные и к серваку более не обращается, пока не будет дана команда сохранения изменений в БД.

и "проспит" момент обновления данных на сервере....

Web клиент продолжает сотрудничать с сервером IIS, думаю Вы согласны.

конечно....

Далее - нужно мне на клиенте собственную графику рисовать. Как это на ASP.NET сделать без подгрузки ActiveX ?

а разве рисунки уже запретили ???
1. можете динамически создать на сервере файл и подгрузить его
2. можете (не трогая файловую систему сервера) динамически создать поток, который опять таки средствами <img src='что-то-там.aspx'> отдадите клиенту...
ну и т.д.
у меня такое ощущение, что Вы не были по приведённым мною ссылкам...
там есть такая вещь, как report kit, где всё, о чём Вы спрашивали есть...


Далее чисто вопрос разработки - что нужно знать, чтобы разрабатывать виндовых клиентов ?
и н только для виндовых, но и линуксоидных, яблочных и под все остальные платформы, где есть вэб-браузеры ... - минимум - это asp.net (любой из .net языков)... даже знания HTML не обязательны, хотя и желательны... ну а для работы с данными - желательно SQL.. хотя судя по всему Вам это знакомо ...

Ответ - его язык, иногда API и встроенные компоненты.

API в классическом виде Вам не нужны... ну а язык, раз речь идёт о выборе, то в любом случае как минимум один надо знать.. так почему бы и не один из .NET языков...


Про ASP.NET думаю и вопрос бестолку задавать - знать надо все - HTML, C#, XML, JavaScript, принципы работы IIS, опять же компоненты работы и т.д. Аналогию можно долго продолжать ...

Вы не поверите, но и для любого другого языка Вам нужно знать не меньше....
компоненты - ну это для любого языка надо.... хотя бы приблизительно..
C# - ну это язык... т.е. для программирования на любом из языков Вам его как минимум знать...
XML, JavaScript, принципы работы IIS- не обязательно..... хотя и жетально..
HTML (в классическом виде) - не обязательно... потому как всё полностью можно сделать средствами того, что можно отнести к 1-м пк-ту - компоненты....


Теперь насчет .NET - чтоже там такого в CLR, бесплатно предлагаемым MS, что позволяет писать полноценные GUI приложения ?

компиляторы всех 3-х поставляемых с fw sdk языков.. Вы можете в notepad написать .vb файл , далее его откомпилировать и использовать....
опять таки занятие "на-любителя" (я лично себя к ним не отношу и использую нормальные продукты разработки).... но можно....


Стандартный и жиденький супнабор, даже до стандартного набора компонент той же Delphi далекова то будет. Встроенный Grid явно срезанная версия FlexGrid. Отчетник Crystal Decision обрубок от Crystal Report.

у меня сложилось впечатление, что о программировании на .net вы только слышали... и не более.. т.е. даже основ не знаете... есть одно небольшое отличие .net и delphi... в том, что в delphi всё выставлено на показ из-за относительно небольшого кол-ва компонент.. а ms не стало всё выставлять на-показ .... но и тем не менее там хватает всего для выполнения большинства задач... а надо что-то дополнительно - как и в дэлфе - доставляйте.. на том же www.asp.net и готодотнэт.ру компонент (в том числе и бесплатных) достаточно..... а с учётом времени жизни технологии я бы сказал, что оччень много ..

Если Вы считаете это нормальными компонентами, то задам Вам коварный вопрос - а на чем Вы раньше программировали до C# ? :)

должен Вас огорчить - я на додиез не программирую... я всё больше на vb.net (сила привычки, что ли... хотя можно будет поискать что нить типа pascal.net .... хотя вроде есть что-то типа delphi.net или как там он называется в .net версии)

А то получается, что Вы считаете что в .Net всего много, а мне кажется, что вообще ничего почти пока нет. И самое главное оба считаем, что правы :)

причину таких расхождений я описал выше....

кстати, я так понимаю что Вы сторонник клиент-серверных решений с использованием исполняемых файлов... у меня к Вам вопрос.. есть сетка.. в ней проект, который я доделываю на delphi (тот, после которого я решил не связыватся больше с дэсктопными программами)... и у меня в программе, как в любой друго программе, есть исправления.. например где-то нашли опечатку, где-то надо поменять 2 п-кта меню местами ... не столь важно, что именно, но вот что получается... появился новый exe файл.. я его выкладываю на сервер на общедоступный ресурс с другим именем... типа project_versionN.exe ... (по причине того, что из-за занятости файла клиентами, что с ним работают - я не могу заменить сам файл)... и соотв. после этого мне приходится бежать по всем клиентам, что бы править им ярлыки на запуск (пусть даже и по сети - доступ есть)... в asp.net эта проблема решается настолько прозрачно для клиента, что даже говорить про это не хочется.. а как быть для .exe файлов ??? хорошо, когда клиентов всего полтора десятка и половине из них достаточно сказать по телефону "возьми ту бумажку, где я описал как менять ярлык на запуск другой версии и поменяй на N" ... а если бы клиентов было несколько сотен ??? или несколько тысяч ??? как Вы у себя обновляете программу ???

2ASCRUS:

ну вот.. разговор только - только начал к чему-то приходить, а Вы ушли..
рановато.... но на случай, если всё же надумаете вернутся - оставлю и я свой пост... хотя у нас получается что тему надо менять на "asp.net vs delphi"

Ссылки я посмотрел. Примеры очень простенькие. Может они для web-клиентов и считаются крутыми, но для меня лично этого было бы мало.

маловато для чего ??
для клиента MSSQL, которому, в 95% (IMHO) нужно от сервера получить данные в определённом виде (часто табличном), отредактировать данные в некой форме с проверкой валидности введённых данных и передать всё на сервер... всё это asp.net позволяет сделать легко и непринуждённо...

да и ведь это только примеры... Вы ведь не будете настаивать на том, что бы в букварь для 2-го класса добавили "войну и мир" :_)

На Delphi конечно гонять 5к записей не надо, легче сделать фильтр и дать пользователю возможность ограничивать получаемую информацию задаваемыми масками - все равно ему 5к многова то будет :)

фильтры есть... вот видит народ свои 5K и после этого решают, что им оставить.. - ну так уж спроектирован процесс работы...

пользователь не должен быть так жестко завязан от обновления данных.

но и старые данные ему показывать не стоит...


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

если данные хранятся в БД (а вроде обсуждаем построение клиента для MSSQL) то можно динамически строить и эту схему...

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

повторю ещё раз но более внятно: если на клиенте запрещены скрипты или он их не умеет отрабатывать, то он может их переслать серверу и тот проверит и выдаст ответ о их правильности.. но в нормальных условиях всё проверяется на клиенте....

Насчет кроссплатформенности - это действительно круто, если все навороченные решения ASP.NET работают не только на IE.

работают во вмех браузерах, правильно работающих с HTML.. а ещё лучше DHTML ...

Не знаю, поэтому с Вами соглашаюсь. Насчет GUI клиентов - берем Power Builder, легким движением руки лепим навороченного клиента, который будет работать на любой из перечисленных Вами ОС и в придачу на Windows 3.1 :)

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

Насчет незнания .NET - знаю, но поверхносто. Побаловался, пописал компоненты, поизучал иеархию и решил что сыровата для крупных проектов (правда было это давно, так что возможно ситуация изменилась). Если Вы утверждаете, что в глубинах CLR лежат невостребованными кучи полезных визуальных компонент (я говорил тогда о них !!!)

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

- то почему их не видно в иеархии классов в том же Object Browser и ничего нет о них в помощи ?

там видно всё, что есть... см. на 2 абзаца выше..

Так кстати Вы так и не ответили на вопрос, на чем Вы раньше сидели до .NET ?

я думал, что по тому, что я говорю о asp.net и delphi (а не там о жабах или о vb) Вы поймёте, что delphi , pascal ...

Если на VB или ASP, то я вполне разделяю Ваше восхищение новыми возможностями .NET по сравнению с этими средствами. Действительно был сделан большой шаг вперед, пусть и MS нужно было его сделать давно, но как говориться лучше поздно, чем никогда :)


напрастно Вы так с иронией говорите про asp и vb ..
у меня есть неплохая библиотека (правда с выходом и моим переходом на .net она может быть использована только как пример хорошего программирования) для работы с основными визуальными элементами... т.е .я в XML файле описываю список\форму и т.д., там же задаю все параметры, а из asp страницы только говорю, какую форму\список мне отобразить\отработать и пишу, куда перейти при правильной обработке данных (в смысле правильно заполнили форму)



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

и плодим тем самым кучу копий одних и тех же данных...

"А у нас водопровод - вот" :)

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


Каждый остался при своем мнении - я считаю, что IE нужен для просмотра сайтов, Вы считаете, что не только для этого. Каждый из нас по своему прав :)

да уж... вижу старого VB-шника.... чувствуется старая закалка....
т.е. все те технологии, что MS продвигает для переноса работы в inet-технологии Вы считаете глупостями ?? а мне например удобно с любой точки планеты суметь получить доступ к своим данным... узнать о состоянии дел в моём отделе (к примеру) и т.д. и не обязательно с IE ... а и просто с мобилки или наладонника....

С чем и разрешите откланяться почтенной публике на данной ветке :)
он ушёл, но обещал вернутся (c) карлсон :-)

2Pavel:
что именно полезное Вы хотели бы увидеть но не увидели ??
да и речь, как я в своём предыдущем посте сказал, идёт не о понтах а о сравнении того, с использованием какого инструмента проще или сложнее сделать и соотв. потом сопровождать программу, которая работает с БД...
да.. я сторонник использования WEB технологий для создания клиент-серверных приложений... но в тоже время это мне не мешает сопровождать и дорабатывать приложение на delphi (вон последний из них : .pas файлов с пол сотни : 144,899 bytes in 49 files по мнению FAR -а, а если ещё и другие файлы: 2,018,395 bytes in 198 files без учёта .exe и .~* ) ... так что я считаю, что я могу сравнивать эти технологии.... как аргументы ЗА asp.net я привёл:

1. простота разворачивания на клиентах
2. простота обновления (клиентские машины вообще не нужно трогать)
3. многоплатформенность клиентов (может быть что угодно с WEB браузером)
4. для доступа к БД используется ado.net а не ado (отличий ado.net от ado хватит на хорошую книгу, и всё не в пользу ado )... кстати, не все программисты для доступа к данным из delphi используют ado... многие используют odbc, что не лучшим образом сказывается на производительности приложений....
5. Вы не ограничены при использовании этого клиента гланицами LAN - весь интернет к Вашим услугам (для тех, кто скривился из-за того, что инет открытая сеть и т.д. напоминаю пол https :-) )
6. средствами asp.net (а эта технология, кстати, ещё активно развивается - не зря в ms есть отдел с названием типа .net platform strategy group или что то типа такого - давно видел и точно не помню) можно сделать всё.. причём движёк asp.net достаточно интеллектуальный что бы самому выбирать многие вещи (например если можно валидность введённых данных в форму можно проверить на клиенте средствами клиентских скриптов - так и будет сделано.. нельзя - значит данные будут проверены на сервере и т.д.)
7....
в общем можно продолжать долго... но и этого достаточно для получений общего мнения...

в общем подвожу итог по теме "На чём клиента для MSSQLServer писать быстрей всего?" с своей точки зрения.
1. лучше (и быстрее) писать на том, что знаешь
2. если ничего не знаешь или знаешь всё, то лучше "смотреть в сторону" asp.net...


2Pavel: я ответил на все Ваши вопросы ???

2n:
интересно, если Вы стремитесь споры 1-м делом разрешить, то зачем в них участвуете... пусть даже как читатель :-))

2Pavel:

Я уже сказал - ...хочется кроме понтов вынести нечто полезное.

6 п-ктов , где я "по-полочкам" разложил плюсы WEB технологий особенно при их использовании из asp.net - это понты ?? ну ...... ээээ... слова закончидись :-(

Очень хорошо знаю помирающий Paradox. И в голову не придет писать на нем клиента.

а я парадокс не знаю.. расскажите pls в целях моего образования в 2-3 п-ктах, чем он так плох ??

Не плохо знаю Access. С ним и пурхаюсь - есть обоснованные претензии.

..... завязывайте Вы с этим грязным делом... тока время зря потратите....

Пробовал перейти на Delphi. Не ощутил супер преимуществ.

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

ASCRUS заинтересовал PowerBuilder'ом. Будем посмотреть.
угу.. жду от него скриншотов...

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

Нет. Их у мнея слишком много. Боюсь утомить.
а Вы не бойтесь... будет напрягать - сообщу... кстати, если вопросы только про asp.net а не про выбор инструмента - можно переехать в соотв. тему на этом форуме..

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

мысль хорошая... по-свободе подумаю над этим (Штирлиц подумал, ему понравилось :-) ).. но пока не вижу смысла: делать что-то сложное без видимой отдачи - не интересно.. делать простое типа "что бы показать клиенту список по результатам работы sql запроса делай мышкой раз, делай два в одной среде разработки и делай три делай четыре в другой" - это не будет инкому интересно, тем более, что книг хватает и по одной и по другой теме.... но на конкретные вопросы могу ответить (если знаю ответы, соответственно)...

2Mik Prokoshin:
создаем .bat файл, ...

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

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

см. выше... ну не нравится мне идея батников...
это (bat) - технологии времён доса... и мне это не нравится...
не надо мне рассказывать о том, что эту проблему можно решить с использованием .vbs и прочих скриптовых windows иснтрументов... я говорю о другом- до этой проблемы можно ситуацию не доводить...

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

2AAron


Сейчас все-таки уже не каменный век, и иногда можно подумать на тему терминального сервера. Мысль проста - устанавливается один мощный сервер, на котором реально все и работают, для клиентских машин хватит win3.1. Хм, подумалось, вот здесь как раз и проиграют все Delphi и IE.
скажу больше...
т.к. сейчас не каменный век, то терминальные клиенты есть уже аппаратные.. т.е. не надо даже на 3.х лицензии покупать... да и с обслуживанием попроще, потому как там ломатся нечему...

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

Если требуется строить графический редактор (Adobe PS, к примеру :)), то имеет смысл задуматься о desktop приложении.

Уважаемый 2AAron !!!

речь шла о клиенте базы данных.. а не о графических редакторах.. и мнение о asp.net я высказывал только в контексте клиента БД.. я не утверждал, что asp.net - это панацея от всех бед... нет... мне такое и в пьюяном бреду не придёт.. так что не надо сравнивать хрен с яишницей ....

Возвращаясь к теме топика - web больше тянет на тонкого клиента на мой взгляд, Delphi меньше. Но Delphi может быть удобнее или мощнее.
как пример того, что delphi мощнее.. вот реальные задачи из тех, что я не смог бравым-гусарским наскоком решить в delphi а в .net они решены от рождения..
1. как организовать md5 криптование в delphi (в .net есть соотв security провайдеры, позволяющие это делать)
2. не нашёл поддержку regexp-а ...

2andsm:
расскажите , как прозрачно для клиента (в идеале так, что бы клиент увидел только то, что ошибка исправлена, даже не заморачивался с перезапуском программы... потому как она может ему принудительно запускатся при логине) обновлять программу, которую клиент выполняет...

Вообще-то первоначальный вопрос был от том, на чем писать быстрее
на этот вопрос ответил eNose : "Хорошо то средство, которое знаешь"

И что-то мне подсказывает, что написание интерфейса на дельфях несколько быстрее, чем на JavaScript.

я не говорил за *script..

Ведь Вы же, кажется речь ведете о просмотре в любом броузере? Разумеется, можно создать Большую Главную Кнопочную Форму a'la Access, но меня от таких интерфейсов воротит.

а что, признак программы для Вас - это наличие верхнего меню ??



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

Да еще и заботится от том, что бы это было совместимо с разными броузерами.

зачем ??
система (asp.net) сама это делает...

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

извините, но после этого высказывания я начинаю сомневатся в Вас, как в программисте высокого уровня... по крайней мере для Win платформы (хотя судя по тому, как Вы отстаиваете delphi, то не похоже, что бы Вы были из линуксоидов).. иначе видели бы как сделана навигация на таких сайтах, как MSDN.microsoft.com, www.microsoft.com и т.д. и ведь без активиксов там обошлись...

ActivX? И причем тут тогда WEB?
а при чём здесь activeX ??

И еще ситуация. Юзер ввел данные, страничка обновилась. Юзер сдуру жамкает "back" и видит прежние данные. Вводит снова. Обновление. Юзер видит двойные данные. Жамкает "back". Наконец-то все нормально! Реальная история, после которой я бросил писать веб-клиентов.

а что, content expire уже отменили ??

Я не спорю, возможно эта проблема решена. Тогда поделитесь, пожалуйста НОУ-ХАУ.

должен огорчить.. но это не ноу-хау и им никогда небыло... это называется content expire...
так же для форм добавления данных можно юзеру открывать новое окно (а для приложений это нормальная практика) в таком виде, что бы он не видел не строку адрес, не кнопки back и иже с ними.. а только заголовок и содержимое формы.... а если один раз настроить стили отображения всех элементов соотв. образом, то можно добится даже того, что бы web приложения выглядили как win32 ...

я так понимаю, что Вы не видели не одного серёьзного решения на базе www ... тогда настоятельно рекомендую посмотреть на OWA (outlook web access), sharepoint portal server и прочие решения, что сделали "взрослые" программисты...

у меня есть одно решение на базе www, которое, после краткой разъяснительной беседы (часть аргументов я привёл здесь, оставшуюся не стал приводить т.к. она касалась только asp.. а не asp.net ), настолько понравилось клиенту что он уже более года не может найту лучшее для ведения учёта кадров, производительности труда сотрудников и из зарплаты из других систем типа акцент, 1ц и прочее... это при том, что моя система не суппортится (сразу была настолько гибко сделана, что все изменения они вносят сами, если у того, кто работает есть соотв. права... хотел ещё интегрировать по системе безопасности с доменом, но заказчик захотел, что бы сотрудники сами вводили логин\пароль )

ps: всех админов подздравляю с их проф. праздником

Я вроде не про программы говорил, а про интерфейсы. Или для Вас это одно и тоже?
какие именно из интерфейсов ??
программных типа API или интерфейса в контексте внешний вид (GUI) ???


Про совместимость броузеров - asp.net сама делает. А вы свое чудо в других броузерах смотрели? И отличий не нашли?
смотрел (пришлось даже из-за этого машину испортить неэшкафом)... нашёл отличия... но они насколько незначительные, что на них можно не обращать внимание...


Sorry. Хотел ссылку дать, но владелец сайта убрал свой проект где был мой прикол, в котором использовались менюшки.

если прикол Ваш и у Вас сохранились html - можете прямо на мыло...


Ну ладно ЭТО тоже что то про меня говорит. Правда надо смотреть только в IE >= 5

извините, но в Win2k3 младшую версию сложно найти.. :-)

==========
И в конце-то концов оказалось, что на web написаны КАДРЫ.

из внутрикорпоративных - да..
а так же ещё остаётся куча сделанных мною сайтов...

Самая простая база, которая только может быть. Расширенная телефонная книжка.
расскажите это тем, что внедряет модуль кадры системы r/3 .. они Вам подробно объяснят, чем кадры предприятия отличаются от телефонной книги... :-)


И если Ваши клиенты переходили на нее с полного дерьма написанного на Fox 2.0 парочкой студентов, то они и посчитали ее счастьем.

нет.. они переходили с других коммерческих продуктов, которые не смогли обеспечить нужную им функциональность... (извините, но не буду суда постить ТЗ... оно здесь и не надо да и денег стоит, что бы бесплатно раздавать)

Скриншотик главной страницы на мыло или ссылочку на него, плиз.

http://server.domain.local :-)) ...

извините, но БД внутрикорпоративная.......... и из инета, как Вы можете догадатся, недоступна (что поделать, требования безопасности)...

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

Ну, будь.
извинете, но это не фидо и мы вместе ("на брудершафт") не пили, что бы "на ты" общатся... ещё раз сорри...

С днем, так с днем. Те более у меня тоже два домена имеется.

не густо... но все с малого начинали :-)

2andsm:
скажите честно, Вы прочитали моё сообщение ?? при чём здесь сервера приложений ?? при чём здесь организация отказоустойчивой системы ???

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

ну что же.. повторю ещё раз... на пАльцах.. что бы было понятно...

итак.. есть сетка.. в ней народ... юзает какую-нить внутрикорпоративную задачу, сделанную на delphi ... т.е. запустили .exe файл (с сервера, с локального диска.. не важно)... возможно при автозагрузке... и оказалось, что в одном месте надо на форме в контрола нужно поменять местами... расскажите, как это сделать так, что бы народ и не напрягать перезапусками программы ?? потому как если сетка достаточно большая и народу нужна всего одна программа для выполнения своих обязанностей, то в ней у них одна единственная нужная им программа может быть запущена в автозагрузке и они даже не умеют вообще программы запускать... в asp.net проблем с этим нет... всё делается прозрачно- Вы на сервере обновили файл с исправлением (которые, кстати, всегда открыты для записи теми, кому можно) и всё.. и при следующей прорисовке этой формы данные берутся из обновлённого файла и народ просто продолжает счастиливо юзать новое.. без перезапусков... всё прозрачно... а как такого же добится на delphi ???


2Mik Prokoshin:
не пугайтесь, это andsm говорил про delphi приложения, а не про asp.net-овские.... :-) да и не совсем правильно :-( ... вернее так, как он говорил тоже, наверное, можно.. но умные книги рекомендую делать немного не так...