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

Во-первых, складывается (давно сложилось) впечатление, что люди, приходя в Лотус из традиционной разработки (C, Pascal, etc.), подсознательно не желают отказываться от своих умений и привычек, сопротивляясь новой среде с непохожей идеологией. Благо Лотус предоставляет им нишу под названием Lotus Script. Честно скажу, что лучшего объяснения "засилью" скрипта не представляю. Доводы о мощи скрипта по сравнению с формулами и т.п. , хоть и верны, но не слишком убеждают. Почему же в таком случае не С++ и Notes API? Потому, что для каждой работы есть свой инструмент: на мух -- с мухобойкой, на медведя -- с ружьишком, ну a на танк уже с С++... Это рассуждение плавно подводит нас к вопросу о том, какой же инструмент есть в Лотусе и для какой же работы он (инструмент, да и сам Лотус) предназначен? А это уже вопрос второй, имеющий явственный схоластически-философский оттенок...

Во-вторых, невооруженным глазом видно, как народ, воспитанный на классических языках программирования и впитавший сызмальства идею реляционной базы данных (Что, бывают другие!?), отчаянно пытается сделать на Лотусе то, и так, как он к тому привык и знает... Что греха таить, 10 лет назад, начиная работать с Лотусом (принимаю поздравления по поводу юбилея), около полугода переживал болезненный период ломки стереотипов и "врастания" в Лотус, его, в широком смысле слова, инструментарий и идеологию. С тех времен осталась формула "если это тяжело и никак не получается сделать -- это не Лотус". То есть, нужно искать "ассимметричный ответ", который легко решит вопрос другим образом, естественным для Лотуса. Это и есть (была) главная проблема: должно быть именно так, а иначе я не представляю и вообще, по-другому не бывает, потому, что не может быть никогда. Для признания существования этой проблемы нужны серьезные усилия. Лично мне помог такой случай: наряду с Лотусом, мы, как ярые новообращенные, поставили себе Lotus Suite взамен MS Office. Что тут началось! Даже не представлял, что редактирование текста может быть иным! Если Вы тоже "даже не представляете" -- попробуйте, не пожалеете. Именно то, что нужно для ломки стереотипов...

В-третьих, мне очень понравилась фраза какого-то зарубежного разработчика "За что я люблю Лотус? Представьте, приходит ко мне пользователь и говорит, что ему нужно не так, а эдак... И стоит над душой, возле меня, сложив руки, смотрит, пока я ему это не сделаю!" Представьте и вы: в какой иной среде, для какого продукта такое возможно?! Лотус сам по себе -- сплошная RAD. И не даром Лотус говорит о методологии "протоциклирования". Кстати, раньше было гораздо интереснее документацию к новым релизам читать: всегда было там что нибудь "воспитательное" про идеологию, методологию, правильное применение... И не даром у Лотуса, если не устарели цифры, что помнятся, второе место в мире по установочной базе после MS Office. Лотус, он гораздо ближе к офису, чем к монолитному высокоспециализированному приложению, целиком наваянному на ЯВУ. Соответственно, и способы решения одной и той же задачи для Лотуса и такого приложения -- разные. Но, как упоминалось, многие программисты пытаются работать на Лотусе, стремясь получить то самое монолитное приложение с высокоспецифичными и тесными взаимосвязями внутри своего проекта. Не всегда это правильно.

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

Вот.

По скриптам не согласен. У скриптов есть один ЖИРНЕЙШИЙ плюс: логику приложения можно сосредоточить в одном месте. Вот только ради этого. Например, мне нужно пред сохранением проверить форму на коректность заполнения. Да, есть такая штука как Input Validation. Но есть один недостаток: с первого взгляда я не вижу какие поля проверяются, какие нет. Мне надо "проклацать" каждое поле.

А если я повешу на QuerySave в скрипте? Сразу всё видно. Мало того, я проверку могу вообще сделать настраиваемой снаружи. Сделать много маленьких документиков с реквизитами "Название формы", "Название поля", "Формула проверки" и мааленький флажок "вкл/выкл" и проверять на основании этих документиков. Скриптом, ессно. Что получу? Казалось бы лишний гемморой. Но! Раз помучившись (при том не сильно, мин. 20 с перекуром и красивостями) в дальнейшем с лёгкостью и непринуждённостью истинного иллюзиониста смогу добавлять новые проверки и отключать уже имеющиеся. При этом влёт и на любую форму. А при наличии у заказчика лотусоида "средней паршивости" с меня вообще эта проблема слазит. Ещё потратив децл времени и один флажок в настроечный документ я смогу реализовать предупреждение, что де "некоторые поля не заполнены, в принципе они необязательные, но желательные, будем продолжать?". И у меня всё перед глазами. Не надо по полям формы прыгать аки сайгак.

Если мне понравится - я с лёгкостью перенесу эту делу в другое приложение (чё там, вьюха+сабформа+форма). А сделать такое формулами? Отож... Так что скрипты мощнее формул. Именно из-за того что формулами нельзя логику сосредоточить в одном месте.
------------------------------------------------------------------------------------------------------------------------------------------------------------------

Про реляционку согласен! Лотус есть лотус. Вернее, вначале был документ, и документ был лотус, во! Но бухгалтерские системы - это не документ, это нечто страшное .


P.S. О методах разработки напишу потом . Муза ушла.

Сообщение отредактировал Mihal - 29:11:2006, 13:46

Опа, что я вижу, это же ПИАР в пользу одного только лотуса!!!!

А сабо в лотусе на форме табличку прокручиваемую вывести, берущую данные из другой базы лотусиной, и потом установить эту конфигруацию баз заказчику? )))

запросто: Embedded view, или вычисляемое поле с @DbLookup и формулами, обрабатывающими полученный список.

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

я устал... я ухожу

А я с Вами согласен У самого много лет используется типовая форма со скриптами на событиях, которая проверяет поля. Это тот самый случай, когда скрипты демонстрируют свою силу и применимость. Но это не тот случай, когда скрипты _всегда_и_везде_, где в них нет на деле ни малейшей нужды. Кстати, скрипты в Лотусе -- весьма локальная вещь. Поэтому логику приложения в _целом_ на них повесить очень трудно, если возможно. Логика приложения смещена в сторону взаимодействия крупных элементов дизайна.

Ээээ.... Я так глобально мыслить не умею . Что такое "крупный элемент дизайна"? Мне бы примерчик...

Для: Fossil Code
красиво излагаете... жаль нема у меня музы

А когда я начинаю глобально мыслить, и, не дай бог выскажу свои глобальные мысли в присутствии босса, обычно слышу в ответ неодобрительное: "Ну, это все лирика. Философия всякая. Ты по делу давай!" Ну прямо, как в анекдоте, когда капитан о курсе ответил <норд-норд-ост>, а в ответ получил совет не выпендриваться и показать пальцем

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



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

Так всё вышеперечисленное обплетается скриптами (окромя колонок и формул отбора, ессно). Естественно, если речь вести о функционале, а не об интерфейсе вцелом (компьютед-тексты, например, к функционалу имеют незначительное отношение, а вот к интирфейсу - прямое).

Хе-хе, а вот и нет!!!!
Первое правило в шахматах - не есть пешку противника сразу

1. Не сможете через Embedded view, так как он при создании жестко хранит ID реплики и перенастроить незя когда заказчику притащите

2. второе ИЛИ ВЫЧИСЛЯЕМОЕ ПОЛЕ не дает прокручиваемой таблицы плюс организчения на размер выводимой информации табличного вида.

Так что воспевать лотусину нужно осторожно.
Принципы традиционного программирования во многом сохраняются и в лотусе.
Принципы построения реляционной модели во многих задачах сохраняются и в лотусе!!!

Можно. Через DXL . Правда, нужны права дизайнера. Но при установке это не суть проблема, а очень даже логично.


А кто воспевает? ГДЕ тут было воспевание? Если есть принципы реляционной модели, которые сохраняются и в лотусе - то это означает, что это просто общие принципы, а не реляционные .

Ну-ну!!!! Знаем, пробовали
Приаттачте пример базы, где это работает.
Если Вы имеете в виду интертрастовский пример, то он херит дизайн предсталвения как мама дорогая.

Допольнительно по DXL меня поражает тот факт, что если просто распарсить дизайн вьюхи и засунуть обратно без единого изменения - ПОЛЗЕТ ДИЗАЙН!!!!!
Гуано это, а не метод.

Они не просто сохраняются, они ТРЕБУЮТ ОФИГЕННОГО, СОВСЕМ НЕ RAD программирования.

Выскажусь и я о наболевшем.
Как справедливо отметил топикстартер, пересаживаться на Лотус после традиционных средств разработки и СУБД довольно тяжко: "реляционное" наследие дает о себе знать постоянно. В этом свете особенно неприятно отсутствие толковой литературы, описывающей, как именно стоит создавать базы данных в Лотус. Т.е. не формочки-вьюшки клепать, а именно создавать модель данных, удовлетворяющую как требованиям заказчика, так и особенностям Лотуса. Единственное, что я для себя уяснил пока - стремиться к нормализации в любом ее проявлении как правило не имеет смысла, проблем будет больше, чем пользы.
Механизмов, автоматически поддерживающих целостность данных, тоже нет по сути, все приходится делать руками (у меня вон пара агентов бегают временами по базе, синхронизируя содержимое различных документов). Транзакций нет, блокировок (в R5 по крайней мере) тоже нет.
Если рассматривать Лотус как среду разработки, то тут тоже многое крайне непривычно. Формулы хороши, но ограничены в своих возможностях (как, например, на формулах перебрать ответы на документ без создания доп. вьюх?), да и отлаживать их нельзя (хотя у меня LS-отладчик временами в формулы "залетает", выдавая какой-то LS-код ). Насчет LS я уже поворчал в соседней теме.
Но больше всего, конечно, мешает жить ограниченность средств построения UI. Ну ладно, допустим, я еще смогу пережить отсутствие возможности обработывать события различных компонентов, кроме Click для кнопок, но вот простой таблички на форме мне зачастую весьма и весьма не хватает. Да, можно воспользоваться embedded view, только вот взаимодействовать с ним никак нельзя (риторический вопрос: как получить выбранный в emb. view документ? ), да и вообще, иногда нужно отобразить какие-то агрегированные данные (количества документов определенных типов, минимумы-максимумы какие-нибудь), а view этого не умеют.
Понимаю конечно, что многие мои проблемы обусловлены недостаточным пониманием идеологии Лотус, а также непониманием нынешнего заказчика того простого факта, что Лотус для его задачи подходит крайне неважно, но тем не менее, после перехода на Лотус ощущаю одни сплошные ограничения
Есть вещи, конечно, которые нравятся. Прежде всего, это возможность очень гибкой работы с данными: можно свободно менять структуры данных, добавлять/удалять поля, и все при сохранении работоспособности системы (при наличии прямых рук, ессно). В реляционных СУБД это было бы куда сложнее. Возможность быстро дорабатывать систему на месте тоже весьма приятна, хотя частые доработки по запросу пользователей, которым чего-то не хватает, не одобряю. Таким макаром легко довести систему до состояния, когда никто толком не будет знать, что в ней творится и как устроено (не голословное утверждение, есть у меня один пример перед глазами).
Вот, вроде высказался, аж полегчало

Согласен.... сам долго не мог понят шо оно такое


А в чем собственно проблема?

да... нехватало раньше, приходилось руками докручивать


>Понимаю конечно, что многие мои проблемы обусловлены недостаточным пониманием идеологии Лотус
Но! Ведь попробовав раз - ем и сейчас )))

Сообщение отредактировал Morpheus - 30:11:2006, 07:17

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

А насчет показа таблички в форме, который "не смогу" сделать, правильный ответ (не геройский) таков, что я бы вообще не стал этого делать! Цена вопроса играет роль: вынь да положь табличку в форме потому, что "надо так и не иначе"? Чтобы предоставить соотв. информацию не обязательно "вставлять в форму" динамическую табличку. Можно генерировать по запросу статический документ, куда инф. и пропишется табличном виде. А то и без таблички -- видом, фолдером, а то и полнотекстовым поиском. Право слово, не стал бы "упираться", поискал бы содержательно такое же, а интерфейно -- иное, решение.

Принципы программирования одни и те же в Лотусе и везде. Способы осознания и постановки задач программисту, методы и приемы их решения программистом, сильно зависят от применяемого инструментария и в этом Лотус заметно отличается.

Лотусе -- не реляционная база. Принципов построения реляционной модели в Лотусе просто нет! То что Вы называете так -- часть общих принципов построения баз данных, безотносительных к ярлыкам, которые на них навешены.

1. Я требую примера чиста реляционного принципа, справедливого для Лотуса!
2. Примерчик будет как только у мя руки освободятся да желание возникнет.