Отправляет email-рассылки с помощью сервиса Sendsay

Кубики для взрослых

  Все выпуски  

Кубики для взрослых #28


Информационный Канал Subscribe.Ru

Кубики для взрослых


Новости
Появилась новая версия примера и самой среды разработки. Её можно взять на сайте.
К приятным возможностям, которые появились в новой версии, я бы отнес появление
буфера обмена. Это не совсем clipboard, но что-то очень похожее. Как вы помните,
одним из важных свойств документа, и любой его части, является возможность сохраняться
и восстанавливаться из XML файла. Именно это свойство использовано при реализации
буфера обмена. Мы можем скопировать, или вырезать любую строку документа (и все
что от нее зависит) в буфер обмена. А затем добавить в аналогичный раздел того
же, или любого другого документа такого типа содержимое буфера. Эта возможность
кажется нормальному человеку привычной и очевидной. Но это впечатление обманчиво.
И вот почему, эта возможность очень серьезно конфликтует с требованиями уникальности,
которая в отличие от файловой системы существует в базе данных.
Есть, конечно, вариант запрещать копирование – восстановление для разделов у
которых есть ограничения такого типа, но проблема может быть и не в том разделе,
который копируют, а например в глубоко подчиненном ему разделе. Поэтому, мы просто
будем помнить, что копирование в нашем случае не всегда может быть нормально
завершено.
Еще одно удобство – появление контекстных меню. Все мы уже к этому привыкли,
так зачем лишать пользователя привычных удобств.
Основной проблемой проекта теперь становится документация. По мере сил и возможностей
она создается и размещается на сайте.
Я долго сомневался и решил все-таки разделить рассылку на две, вернее открыть
еще одну рассылку, в которой  и будет происходить обсуждение разработки конкретных
прикладных систем. На нее можно подписаться на сайте.
Первые три выпуска новой рассылки уже написаны,  их можно прочитать в архиве
рассылки.
Причина  в том, что я сомневаюсь, что мне удастся описать весь процесс построения
системы на языке нормальных людей.
В этой рассылке я хотел бы сохранить сложившийся стиль рассуждения, а новая рассылка
будет немного более разработческая.

Физические ограничения.
Моделирование – хорошая вещь. Намоделиовать можно гораздо более сложные вещи
чем, то, что можно себе позволить, если начать это все сразу программировать.
Часто (даже очень) это приводит к проблеме физических ограничений. Работая с
Visual Basic-ом, я уже столкнулся с тремя существенными проблемами, о которых
полезно помнить. Первая проблема – длинна имен классов и библиотек. Есть такое
странное ограничение, сумма длин имен класса и библиотеки не может превышать
40 символов. Это хотя бы документировано.
Вторая проблема выяснилась совсем недавно, когда генератор научился делать выпадающие
меню. На форму можно положить только строго определенное количество компонент.
По моим подсчетам не такое уж и большое. Что-то вроде 512.
Вот это ограничение вообще не документировано.  Хотя, действительно, кому в здравом
уме придет в голову делать такую сложную форму.
Третья проблема известна, но не часто приходится ее решать. Пользователи, которые
работают с программой «База клиентов», просят сделать интерфейс системы более
АРМ-подобным. Фактически, им хочется видеть все документы в одном общем окошке,
хотя уже явно наметилась тенденция отхода от MDI интерфейса. Сделать это на Visual
Basic совсем не просто, если учесть, что документы у нас изолированы друг от
друга и даже физически хранятся в разных программных библиотеках.
Создать одно огромное приложение из всех документов – решение совсем не красивое,
я бы даже сказал – уродливое.

Хочется надеяться, что в других языках проблем меньше.  Впрочем, все это уже
не существенно, так как все проблемы могут быть решены. Просто надо помнить о
«физических ограничениях», а еще лучше знать о них не в самый последний момент.
Ведущий рассылки: Михаил М. Баранов
bami@murometz.spb.ru www.murometz.spb.ru Создаем свою информационную систему


http://subscribe.ru/
E-mail: ask@subscribe.ru
Отписаться
Убрать рекламу

В избранное