С чего начинать? Направление потоков бумажных документов (выборки из различных БД) выяснили, права пользователей по отношению к данным определили, и сейчас в сомнении - на какой платформе лучше все писать - Java, Delphi, Perl? Базы данных планируется размещать на PostgreSQL.
>С чего начинать? Направление потоков бумажных документов (выборки из различных БД) выяснили,
>права пользователей по отношению к данным определили, и сейчас в сомнении
>- на какой платформе лучше все писать - Java, Delphi, Perl?
>Базы данных планируется размещать на PostgreSQL.Если PostgreSQL, то своетую писать на perl.
А чего писать-то ? Интерфейс пользователя ? И народ будет по ssh заходить на *nix-машину или перл на win ставить ?
>А чего писать-то ? Интерфейс пользователя ? И народ будет по ssh
>заходить на *nix-машину или перл на win ставить ?web-интерфейс еще никто не отменял, выносить программу на сторону клиента смысла нет.
Иногда есть. Например, на больших объемах данных - траффик резко снижается по сравнению в HTML. Да и возможностей больше можно заложить.
>А чего писать-то ? Интерфейс пользователя ? И народ будет по ssh
>заходить на *nix-машину или перл на win ставить ?
Зачем - Web, GUI (delphi,Java). По большей части интересует _удобность_ разработки. Т.е. например, Web интерфейс является первым что приходит в голову. Но возникают вопросы примерно такого плана - скорость работы такого интерфейса не слишком высока да и разбираться в лапше из кусков HTML и перловых занятие не для слабонервных, хотя грамотно написанный шаблону задачу несколько облегчат.
Далее java - все классно (скорость приемлема, разработка довольно быстрая, встроенные средства шифрования трафика, развитые механизм рабьоты с БД), но вот реального опыта больших проектов на нем нет, как себя это все покажет неизвестно. Вносит свою долю сомнений и технология JSP - как ее использовать применительно к нашему проекту несколько непонятно, по первым впечатлениям та же самая мешанина из исполняемого кода и HTML? Или все таки нет?
Delphi - быстро, но не хватает кучи вещей начиная от невозможности шифровать трафик, отсутствие механизма развитых regexp'ов, BDE опять же.
В общем, на распутье.
> По большей части интересует _удобность_ разработки.Именно разработки или все-таки работы ? Если первое, то писать на том, что хорошо знаешь. Если второе, то веб-интерфейс забодаешься писать. Его, конечно, проще всего поправить?, но заставить его работать красиво и одновременно удобно для пользователя, да при этом еще и одинаково на разных броузерах и под разными ОС - это задачка еще та. Проходили :)
> BDE опять же.
На любом дельфийском форуме на слово BDE будут тыкать пальцами и громко хохотать :)
Эту технологию уже давно никто не пользует. Для postgres имеется компонента и драйвер ODBC, но и там и там есть свои глюки. Потому мой знакомый разработчик в программе держит сразу два соединения - одно через ODBC, а другое через компоненту. На одних запросах он пользует первое соединение, а на других - второе.
>для пользователя, да при этом еще и одинаково на разных броузерах
>и под разными ОС - это задачка еще та. Проходили :)
Если интерфейс сильно не заморачивать, то довольно единообразно получается.>> BDE опять же.
>На любом дельфийском форуме на слово BDE будут тыкать пальцами и громко
>хохотать :)
Я использовал BDE и драйвер PostgreSQL для ODBC - нмкаких проблем не возникало. Проект работает уже 1,5 года без моего вмешательства (БД отдела строительства).
> Если интерфейс сильно не заморачивать, то довольно единообразно получается.Да. У меня так база данных по оборудованию работает. Но при этом функциональности не хватает.
> Я использовал BDE и драйвер PostgreSQL для ODBC - нмкаких проблем не возникало. Проект работает уже 1,5 года без моего вмешательства (БД отдела строительства).
Просто в последнее время (типа, с версии эдак четвертой) BDE пользовать не рекомендуется, дабы не таскать его за собой. А и в драйвере и в ODBC есть мелкие недоработки, из-за которых один из наших программеров пользует и то и другое. Если интересно - могу уточнить у него.
>> Если интерфейс сильно не заморачивать, то довольно единообразно получается.
>
>Да. У меня так база данных по оборудованию работает. Но при этом
>функциональности не хватает.
А вот здесь поподробнее можно? Чтобы знать хотя бы на чем можно затормозиться при разработке.>программеров пользует и то и другое. Если интересно - могу уточнить
>у него.
Да нет, думаю не стоит. Спасибо.
Ну, например, контекстный поиск по колонке таблицы. Реализовать можно, но на JavaScript и все равно будет не так удобно. Да и вопрос совместимости броузеров поднимается.Или множественная выборка по клику мышей (чтобы набирать не пришлось содержимого ячейки). Никаких JS, но возникает ограничение строки, которая передается HTTP-серверу (метод POST на href я прицепить не смог). Если строка больше предела (у меня было что-то около 1 Kb) - она просто обрезается. А учитывая передачу русского нужно умножать количество букв на 3. Можно сделать и формой с чекбоксами, но представь как перегружена страница будет...
Или фильтры и преобразователи при выводе информации. Например, замена "Фамилия Имя Отчество" на "Фамилия И. О." и выборка по фамилии (без учета ИО).
Такого плана функциональность. Оно работает, но сам понимаешь, что было бы удобнее. Ну и кроме того объем данных, которые передаются по сети, раза в 3 больше получается за счет HTML.
>Или множественная выборка по клику мышей (чтобы набирать не пришлось
>содержимого ячейки).
>Никаких JS, но возникает ограничение строки, которая передается >HTTP-серверу (метод POST на href я прицепить не смог).Ну нельзя же до *такой* степени избегать JS.
>Ну, например, контекстный поиск по колонке таблицы. Реализовать можно, но на JavaScript
[..]
>Такого плана функциональность. Оно работает, но сам понимаешь, что было бы удобнее.
>Ну и кроме того объем данных, которые передаются по сети, раза
>в 3 больше получается за счет HTML.
М-да, однако думаю что использование JavaScript и вообще HTML в контексте обсуждаемой темы, может и имеет смысл, но, ИМХО, для не очень сложных систем, мы изначально не рассматривали широкое примененение JavaScript, имея ввиду использование чистой Java c оконными Java-приложениями на стороне клиента. Думаю, таким образом реализованное приложение будет гораздо эффективней как в скорости работы, так и в удобстве последующей, например, модернизации и даже повторном использовании кода.
ИМХО, имеет смысл использовать JavaScript не для активной работы с данными, а для например, вывода какого-то массива подготовленной информации для просмотра. Как пример, можно привести различные расписания, постановления и пр., призванное донести до пользователей какую-либо информацию.
> систем, мы изначально не рассматривали широкое примененение JavaScript, имея ввиду
>использование чистой Java c оконными Java-приложениями на стороне клиента. Думаю, таким
>образом реализованное приложение будет гораздо эффективней как в скорости работы, так
>и в удобстве последующей, например, модернизации и даже повторном использовании кода.
>
Такое утверждение верно для систем функционирующих в слабо распределенных корпоративных сетях с небольшим (до 100) количеством клиентов. В нашей конторе (СНГ и около 800 "пассажиров") client-side приложения оборачиваются ТАКИМ ГЕМОРОМ support'a, что оттуда уже народ убегать начинает. Проще оказалось исправлять находу JS, только лежать они должны на сервере, ессно.