Мозговой штурм на тему разработки клиент-серверного приложения

← →
Павел Калугин © (2012-12-27 15:27) [40]

> честно говоря нет желания сейчас программировать под браузеры

Броузер - это всего лишь вариант реализации клиентской части приложения.

← →
Сергей М. © (2012-12-27 15:37) [41]

> DevilDevil © (27.12.12 15:06) [38]
> честно говоря нет желания сейчас программировать под браузеры

А ты все же попробуй - потом за уши не оттянешь)

← →
DVM © (2012-12-27 15:58) [42]

> Павел Калугин © (27.12.12 15:26) [39]

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

Если разграничивать доступ не персонально по пользователям, а по группам, и иметь не более 64 групп, то разграничение прав даже на отдельных записях делается очень легко и совсем без снижения быстродействия при выборке. Просто каждой записи ставится в соответствие некоторое 64 бит число, каждый бит в котором означает доступ той или иной группе. Два таких числа дают возможность проверять доступ на чтение и запись. Маска группы передается в каждую хранимую процедуру делающую запрос, бинарными операциями (которые есть почти в каждой субд) можно отобрать подходящие под маску записи. Способ почти не снижает быстродействие.

← →
MonoLife © (2012-12-27 16:12) [43]

> обратить взор в сторону распределенного 3-хзвенного к/с
> веб-приложения : браузер (тонкий веб-клиент) + веб-сервер
> (со встроенным или отдельным сервером приложений) + СУБД-
> сервер

я в свое время попробовал на php написать это дело, внутри организации документооборот, понравилось
> за уши не оттянешь)
:)

← →
vuk © (2012-12-27 16:24) [44]

to DVM © (27.12.12 15:58) [42]:

> Если разграничивать доступ не персонально по пользователям,
> а по группам, и иметь не более 64 групп

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

← →
знайка (2012-12-27 16:39) [45]

> Броузер - это всего лишь вариант реализации клиентской части
> приложения
так уж прям и всего лишь.. есть и нехилая разница. И опять таки html определяет ГУИ или нет.

← →
Jeer © (2012-12-27 16:44) [46]

Начать с уже изобретенных "велосипедов" для создания АИС:

Datarun, CMM, Rational Software, Microsoft Solution Framework (MSF), Rational Unified Process (RUP), Oracle Method, SADT (IDEFx).

P.S.
И забыть об ассемблере:)

← →
Сергей М. © (2012-12-27 16:46) [47]

> знайка (27.12.12 16:39) [45]

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

← →
Jeer © (2012-12-27 16:52) [48]

> А ты все же попробуй - потом за уши не оттянешь)

Тем временем фрейворк raudus от Клопова уже доставляет приличное наслаждение.
Реализовал пару-тройку проектов для Интранет - клиент тащится:)
Добавил выход на мобильные девайсы - народ выпал в осадок.

← →
Сергей М. © (2012-12-27 17:03) [49]

> Jeer © (27.12.12 16:52) [48]

Я пока не решаюсь сделать на него ставку.

Да и вот это

This release starts a new branch.
Release 0.9.0 contains only RaVCL controls

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

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

← →
Сергей М. © (2012-12-27 17:38) [50]

Еще вот это напрягает:

Posted on 20.10.2012 by igorklopov
Raudus 0.9.2 is released.
..
2) New RaVCL control: TRaDBGrid. It has reduced functionality yet – cells are not editable, columns are not resizable. But rich UI for the grid is planned

дбгрид - настолько распространенная и нужная петрушка в веб-приложениях, что рожать его нужно бы первоочереднее и пошустрее, благо ExtJs обладает предостаточными возможностями для этого ..
На дворе 2013 год, однако, а дбгрид у Раудуса до сих пор имеет "жалкий вид и макаронную походку" - кому он нафих нужен без редактирования,ресайза и многих других вкусностей и полезностей ?)

← →
Jeer © (2012-12-27 18:18) [51]

> кому он нафих нужен без редактирования,ресайза

Мне проще - практически никогда не применял какой-либо грид в качестве инструмента редактирирования. Можно считать бзиком:)

← →
DevilDevil © (2012-12-27 19:48) [52]

всем участникам дискуссии спасибо!
информации достаточно

← →
знайка (2012-12-27 19:54) [53]

> Сергей М. © (27.12.12 16:46) [47]
я и не говорю про возможности, с ними все как раз в порядке. ;)
Я про то, что - как делать клиента, влияет и на серверную сторону.
Одно дело это какие-нить веб-сервисы (отдающие, к примеру, джсон ну и там сессии поддержать), и совсем другое веб-приложение со всеми рюшечками.

← →
Пит (2012-12-27 23:01) [54]

> практически никогда не применял какой-либо грид в качестве
> инструмента редактирирования. Можно считать бзиком:)

почему бзик. Абсолютно оправданный подход.

Убью любого, который начнет использовать грид для редактирования, это жутко неудобно для пользователя. Даже cxGrid не катит. Где начало редактирования, где окончание - хрен разберешь.
Вставка новой записи - это уже на грани фола по интуитивности интерфейса. Прибавляем фильтрацию данных - и полный конец обеда.

Единственный в мире грид, который я видел и который подходит для редактирования данных - это excel.

← →
Пит (2012-12-27 23:08) [55]

> Читать Дейта, разбиратся с моделью Сущностей-Связей и т.
> д.

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

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

← →
знайка (2012-12-27 23:22) [56]

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

← →
vuk © (2012-12-27 23:41) [57]

to Пит (27.12.12 23:01) [54]:

> Убью любого, который начнет использовать грид для редактирования

Руки коротки! :P Гриды для редактирования используем лет 10, никаких проблем в этом нет.

> это жутко неудобно для пользователя.

Тут все зависит от реализации и от методики взаимодействия с серверной частью.

> Где начало редактирования, где окончание - хрен разберешь.

Зависит от того, что понимается под понятием "редактирование". Где конец редактирования у одного поля БД - вполне понятно.

> Вставка новой записи - это уже на грани фола по интуитивности
> интерфейса.

Вот вставка в гриде - это да, неинтуитивно. У нас не используется.

> Прибавляем фильтрацию данных - и полный конец обеда.

А какая нафиг разница для редактирования, есть фильтрация или нет?

← →
Jeer © (2012-12-27 23:57) [58]

> А какая нафиг разница для редактирования, есть фильтрация
> или нет?

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

← →
Пит (2012-12-28 00:01) [59]

> Гриды для редактирования используем лет 10, никаких проблем
> в этом нет.

ну знаешь, Алексей, иногда программистов послушаешь - действительно никаких проблем и нету. А поговоришь с пользователями - они волком воют.

> Зависит от того, что понимается под понятием "редактирование".

вот именно

> Где конец редактирования у одного поля БД - вполне понятно.

ты хотел сказать - у одного поля грида?
И где же?

Когда происходит комит в базу?
На каком этапе и как можно отменить редактирование? Каким образом можно подтвердить сохранение изменения?
Как дать команду на начало изменения данных?

> Вот вставка в гриде - это да, неинтуитивно

согласен

> А какая нафиг разница для редактирования, есть фильтрация
> или нет?

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

Конечно, данная проблема существует и в классической интерпретации аля "Журнал записей в виде грида + карточка записи в виде отдельной формы". Что делать с гридом после изменения записи в отдельной форме?

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

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

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

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

← →
vuk © (2012-12-28 00:48) [60]

to Пит (28.12.12 00:01) [59]

> ты хотел сказать - у одного поля грида?
> И где же?

Я немного неверно выразился. Имел в виде поля в DataSet - грид, он же не в вакууме, как правило, а к датасету подключен. А там по окончани редактирования OnChange срабатывает.

> Когда происходит комит в базу?

Вот у нас - ровно там и происходит. В OnChange.

> На каком этапе и как можно отменить редактирование? Каким образом можно подтвердить сохранение изменения?

Берем тот же cxGrid и начинаем редактировать. Для примера возьмем текстовое поле. Пока не нажали Enter находимся в режиме редактирования поля, если в это время нажать Esc, из редактирования выпадаем с восстановлением оригинального значения. Вот именно для этого не нужно делать ничего вообще.

> Как дать команду на начало изменения данных?

Что есть "команда на начало изменений"? DataSet переводится в состояние редактирования тем же гридом автоматически.

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

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

← →
Германн © (2012-12-28 01:31) [61]

> vuk © (27.12.12 23:41) [57]
>
> to Пит (27.12.12 23:01) [54]:
>
> > Убью любого, который начнет использовать грид для редактирования
>
> Руки коротки! :P Гриды для редактирования используем лет
> 10, никаких проблем в этом нет.
>

Я использую уже 16 лет с хвостиком. Первая программа, в которой используется редактирование в гриде впервые вышла в 1996. И продаётся и поддерживается (в т.ч. с выходом новых версий) до сих пор.
Но естественно редактирование в гриде в этом ПО используется не везде, а только там, где это удобно для пользователя и не опасно для БД.

← →
Сергей М. © (2012-12-28 10:09) [62]

> Пит (27.12.12 23:01) [54]

Это тебе просто посчастливилось не застать времена "расцвета" SuperCalc"а)

← →
sniknik © (2012-12-28 11:07) [63]

> А поговоришь с пользователями - они волком воют.
дело привычки... у меня "выли" при переходе с досовского фокса/редактирования в гриде на 1С с редактированием в формах. время ввода/проверки накладных с нескольких секунд (взять "на основании", пробежаться/поменять в гриде по "количествам", сравнить получившуюся сумму. добавление было как формой так и в гриде из списка товаров поставщика (в 1с-ном модуле такого тогда так не сделали)/вводом кода/артикула в гриде) до 10 - 15 мин... (с вводом системы взяли дополнительно 2х операторов, и если раньше один казалось "ничего не делал" то после все 3 были "сильно заняты").

> Это тебе просто посчастливилось не застать времена "расцвета" SuperCalc"а)
до сих пор фокс (старую систему) с ностальгией вспоминаю. а почитаешь сейчас "как надо" и понимаешь, тогда все было "не правильно", но блин УДОБНО.

← →
MsGuns © (2012-12-28 12:17) [64]

>Пит (28.12.12 00:01) [59]
>ну знаешь, Алексей, иногда программистов послушаешь - действительно >никаких проблем и нету. А поговоришь с пользователями - они волком воют.

Это потому что так криво реализовано. Редактирование в сетке незаменимо если требуется изменение большого кол-ва однотипных данных в сжатый отрезок времени, в т.ч. и похожих записей. Модальные окна с подсказками, варнингами и подтверждениями в данном случае просто неуместны.
Конечно, тупым бросанием и "мушечной" настройком компонент такое не реализуется (если какой-нибудь Архонов будет утверждать обратное - плюньте ему в лицо), надо ручками и головой поработать, это да !

>sniknik © (28.12.12 11:07) [63]
>до сих пор фокс (старую систему) с ностальгией вспоминаю. а почитаешь >сейчас "как надо" и понимаешь, тогда все было "не правильно", но блин >УДОБНО.

Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)

← →
знайка (2012-12-28 12:25) [65]

Откройте SQL Server Menagement Studio, и в ней добавить новую таблицу в базу. Все в гриде, и добавляется и редактируется.
И где там чего не понятно, и капец всему? Или там писали инопланетяне? :)

← →
Ega23 © (2012-12-28 12:43) [66]

В Excel-е тоже вот сетка. И как-то редактируют в ней.

← →
vuk © (2012-12-28 12:52) [67]

to MsGuns © (28.12.12 12:17) [64]:

> Тогда не было многопользовательсконо доступа, транзакций
> и много чего еще :)

Не, я понимаю, кнечно, что есть люди, которые на вопрос, "А почему не сделать редактирование прямо в гриде?" отвечают - "Кааааак?!!1111 Там же транзакцыйа!!!1111 =8[ ]" Но вот лично я между этими вещами связи нифига не улавливаю. :)

← →
Inovet © (2012-12-28 13:59) [68]

> [64] MsGuns © (28.12.12 12:17)
> Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)

Многоползователей было, транзакций не было.

>Но вот лично я между этими вещами связи нифига не улавливаю.

Связь однако есть. Тот, кто писал "локалки", юзал блокировки ибо другого ничего не было. И думал что все конфликты разрулятся автоматически (впрочем, часто создавалось такое впечатление). При этом "гридное" редактирование было чуть ли не единственной технологией. А реализация его средами была построена на блокировках.
Но со временем кол-во пользователей и след-но конфликтов резко возросло и весь этот "блокировочный" механизм (в его той еще реализации) издал громкой звук. Ярчайший пример - BDE+Paradox.
В результате имеем что если хочешь работать в локалках надежно, то забудь про гридное редактирование либо используй, но контролируя каждый клик, шмяк и чих юзера.

> Тогда не было многопользовательсконо доступа, транзакций и много чего еще :)
что характерно в первых 1С тоже... но написано было "по правилам".

> Но вот лично я между этими вещами связи нифига не улавливаю. :)
+ 1

ну, не было, ну был файл сервер, и что?
насколько помню там каждая накладная это был отдельный файл, редактировал каждую один оператор (он и был один :), но теоретически могло быть сколько угодно, и накладную можно было вводить частями (перед приемкой "склеивало").
в таком стиле, хоть счас на клиент сервер переноси, никаких коллизий не будет. но методов подобных почему то нет (не распространены), а вот правил (как сделать неудобно и оправдаться, ИМХО) навалом.

> MsGuns © (28.12.12 14:01) [69]

А как там сейчас в 1С обстоят дела с транзакционными делами при использовании системы в файловом режиме ?

to MsGuns © (28.12.12 14:01) [69]:

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

Фигзнает. В VCL любой механизм редактирования набора данных сводится к DataSet.Edit -> ... -> DataSet.Post. При этом всё это нормально прехватывается и приводится к любому виду взаимодействия с БД, какой нужен.

>В VCL любой механизм редактирования набора данных сводится к DataSet.Edit -> ... -> DataSet.Post.

Нет, далеко не ЛЮБОЙ.

>При этом всё это нормально прехватывается и приводится к любому виду взаимодействия с БД, какой нужен

Нет, не все. Я уже рассказывал про BDE и TTable например. Если лично у Вас не было проблем с гридной технологией, то это не значит что их вообще не было.

> Нет, далеко не ЛЮБОЙ.

Приведи пример.

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

>Приведи пример.

Append/Insert/AppendRecord/Delete,Refresh etc

> [69] MsGuns © (28.12.12 14:01)
> В результате имеем что если хочешь работать в локалках надежно,
> то забудь про гридное редактирование либо используй, но
> контролируя каждый клик, шмяк и чих юзера.

Да ладно. На FoxPro 2.6 в гриде
locate all for rlock() && найти и заблокировать первую незаблокированную запись browse fields ; field1 параметры, ; и т.д. прописываем какие и как отобраджать поля ; when rlock() valid funlock() ******************************** function funlock unlock return .t.

> Append/Insert/AppendRecord/Delete,Refresh etc

По-сути - одно и то же.

> знайка (28.12.12 12:25) [65]
> Откройте SQL Server Menagement Studio, и в ней добавить
> новую таблицу в базу. Все в гриде, и добавляется и редактируется.
>
> И где там чего не понятно, и капец всему? Или там писали
> инопланетяне? :)

пересадить всех бухгалтеров на нее

Ганс вроде прав :)

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

например
procedure TCustomADODataSet.EnableEvents;
if (CommandType = cmdTableDirect)

then
DatabaseError(SEventsNotSupported);

Мозговой штурм на тему разработки клиент-серверного приложения Найти похожие ветки