Mark your calendars for this Friday, August 17th! The official announcement has been made: electronic software delivery of the English language version of Lotus Notes and Domino 8 is this Friday. The wait will soon be over -- along with the public beta program.

хттп://www-306.ibm.com/common/ssi/rep_ca/7/897/ENUS207-187/

А толку то что она выйдет ....
Была бы эта монстрина полегче...
Да и русский лангвичпак все равно ждать до конца января 2008 года (для юзверей)

монстра конечно большая, но по скорости работы вполне сносно. Я уже несколько месяцев пользуюсь 3й беттой и пока никаких нареканий нет. В некорых случаях стало удобнее Исчезли некорые шлюки при использовании нотеса на двух мониторах . А по скорости работы 8ка даже бстрее чем 7ка, если конечно не ставить ворд процессор и остального сырого софта.

Я некоторых случаях функционал с word и Excel - процессровами необходим...(имхо не нужно офис покупать)...а так же если еще и на Linux перевести то вообще получается красиво...

Супер! В Software Access Catalog уже всё доступно, и под винду и под линукс клиенты, сервер, C API, в выходные будем заценивать

ОпенОфисс2 тоже не нужно покупать, а пользоваться намного удобнее и не тормозит. Тем более что в 8м лотусе ворд процесор, таблицы и презентации реализованны на базе опен офиса, но почему-то версии 1,3 кажется. А первая версия офиса очень тормознуая. Поэтому лучше отдельно поставить опен офис 2, и тоже бесплатно использовать и глючит намго меньше. Без Productivity Tools Lotus8 работает даже быстрее чем 7ка, правда памяти ест много, на щас память дешевеет можно прикупить пару гигов .

Я опен офисом уже больше полу года юзаю на винде и на линухе, жаль что на мак ос нормального опен оффиса нет, поэтому на макинтоше пользуюсь МС Офисом.

ИМХО Productivity Tools это бесполезные рюшечки, полноценным офис пакетом его пока назвать трудно, и вообще непонятно зачем было городить огород кода у лотуса был суперкий пакет Lotus SmartSuite. Они его убили, а теперь снова изобретают колесо

Неприятная новость - под линукс нет дизайнера и администратора

Я опечален ...

Не будем горевать, зато он етсь под винду
фтп://lotusn.myftp.biz/Lotus/Client/IBM.Lotus.Notes.Client.Designer.8.En.Win32/IBM.Lotus.Notes.Client.Designer.8.En.Win32.exe

И, честно говоря, врядли будет.
А как там реализован функционал с word и Excel - процессорами? что, неужели можно напрямую документы или виды экспортировать без заморочек?
Потом еще вопрос, я слышал, у него проблемы (в бетке были точно), если работать с документами, содержащими поля с русскими именами? вроде как формулы / Lotus Script код их не видит...

А почему нет? Я видел где-то внете скриншоты, дизайнера в еклипсе, а раз еслипс, значит и на линухе будет 100%. А если можно дизайнер запихнуть то и до администратора не далеко . 8я версия использет еклипсу только для клиента, а в версии 8,5 обещали сделать много изменений и в дизайнере. К тому же техниески запустить в еслипсе нотес или дизайнер практьически одно и тоже. Еклипс выстумает своего рода оболочкой запуска. Вообще идея сильная Таким макаром можно запустить многие win32 приложения не исполующие функций ядра винды. wine отдыхает

Будет, будет, IBM уже давно Linux в массы двигает.


наверное, в блоге Maureen:
]]>http://mvgirl.blogspot.com/2007/06/we-didnt-forget.html]]>
]]>http://mvgirl.blogspot.com/2007/06/domino-...esentation.html]]>

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



Почему нет? OpenOffice на Маке нормально работает, как установил, так до сих пор им и пользуюсь. Хотя иногда встречаются отзывы о его проблемах с документами Microsoft Office, но мне пока ничего такого не попадалось.


Кстати, IBM грозился исправить в 8-й версии (или в 8.5, точно не помню) проблему с отображением кириллицы в лотусовом клиенте под Маком.

2Шваб про опечатки..

в LS ни разу с опечатками не сталкивался...

вау!!! да не ужели! не прошло и 10-ти лет

Наверное он имеет в виду отсутствие Option Declare

Declare/Explicit — это ерунда, которая всего лишь напоминает об объявлении переменных. А как быть с именами полей с присвоениями значений и т.д.

Пример:

1. Есть документ, в нем есть числовое поле с каким-то значением.
2. Нам нужно отобразить это значение (например, с помощью print)
3. Пишем print doc.SomeField(0) (и в спешке/запаре и т.д. забываем конвертировать значение в строковое c помощью cstr).
4. Сохраняем код — все ок
5. При работе — получаем ошибку

Теперь вопрос, накой черт мы поле как численное объявляли, если при написании кода это не учитывается.

Еще пример:
1. Нужно получить значение определенного поля документа
2. Пишем с ошибкой someValue = doc.SomeValeu(0) вместо .SomeValue(0)
3. Cохраняем код — все ок
4. При работе — чего-то не выходит

Примеры грубые, но смысл, думаю, и так понятен.

Для: Кирилл Шваб
как ты себе это представляешь? компилятору что, на лету обрабатывать коллекцию и проверять все документы на предмет правильного типа?

по умолчанию поля считаются текстовыми (если в поле на уровне формы не определено Default значение) и значение = "".

Кирилл, я понял о чем вы.
Когда я пишу doc.name и функция Autolist Members мне впихивает вместо имени поля name - свойство NameOfProfile, я тихо матерюсь

Увы, IDE лотуса устарел лет на 10, и судя по скриншотам нового дизайнера (я видел один где была показана LS-либа) он так и останется на этом старом уровне.

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

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

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

З.Ы. А работа LS компилятора действительно мистичекая . Про иде я и не говорю это вообще программерский треш

oshmianski,

Об этом уже в IBM должны думать. Посмотри в качестве примера, как та же Borland Delphi Studio сравнивает соответствие типов переменных.

На лету можно простые соответствия проверять. Список свойств и методов почему-то спокойно отображается для объявленных переменных. И ничто не мешает выполнять проверки в фоне.

Пример:

1. Написал, someValue = doc.SomeValeu(0)
2. Перешел на новую строку, пишешь себе чего-то дальше, а среда в это время в фоне проверила тип поля и, если есть ошибка, то отобразила соответствующее сообщение

Поэтому не вижу никакой сложности в этой задаче. Даже если проверка очень трудоемкая, ее все равно можно выполнять, но не на ходу, а например как сейчас — при сохранении кода.

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

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

RAJ,

Простым анализом:

1. Берем список всех полей в базе
2. Находим нужное нам поле SomeValue
3. Поле SomeValue одно в базе?
3.1 Да, поле одно — сравниваем тип поля с тем что в коде, если не совпадает — отображаем ошибку
3.1 Нет, таких полей несколько
4. Совпадают ли типы у этих полей (т.е. в двух разных формах SomeValue — текст)
4.1 Да, они одинакового типа — сравниваем с тем что в коде, если не совпадает — отображаем ошибку
4.2 Нет, они разных типов — отображаем сообщение о возможной ошибке (мол смотри не напутай, поле то у тебя в одной форме как текст, а в другой как номер)

Только не надо отображение ошибок воспринимать как в Лотусе, посмотрите как тот же самый Эклипс сообщает об ошибках при работе с java-кодом.

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

Для: Кирилл Шваб
О чем вы вообще говорите. Давайте "мухи отдельно, котлеты отдельно".

1) Notes - это система документооборота. Это тип систем с неструктурированными данными, в отличии от реляционных баз, где структура четко описывается. И в этих системах нет нормализации и обязательности следования структуры. Это системы для специфических задач, которые и называются документооборотом. Можно, конечно, накладывать ограничения, требования, связи и тп. Но это уже дело вкуса и требований конкретной задачи. Но в общем случае, см. выше...
2) Есть элементы дизайна и есть данные. Данные могут открываться с разными формами, что, кстати, часто используется. Что вы хотите, чтобы дизайнер проверял? То, чего может вообще не выводиться ни в какой в форме? Или может выводиться, но не в одной форме? Может в разных документах (формах) иметь разные типы поля? Может быть специальным полем, для backend операций? Вообще может быть новым полем и нигде еще не существует? ЭТО ДОКУМЕНТООБОРОТ!!! Со всеми плюсами и недостатками.

Вообще, мое мнение, что все упрощения работы разработчика с подсказкам и проверками и тп приводят к тому же результату, что и пользование калькулятором школьника, который не научился вручную делать операции. В образовании это называется "Microsoft education". За всей простотой click-click совершенно теряется понимание, аккуратность работы и знания, так как ответственность за проверку перекладывается на разработчика софта.

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

зы: выпадающий список свойств и методов мне и не нужен, он даже отвлекает. а вот от перекрестных ссылок на описание функций и процедур не отказался бы (как стандартных, так и написаных разработчиком) + интерактивные ссылки на описание метод и свойств из хелпа (естественно, только для стандартных).
и вообще, может откроем свою ветку - "чего мне не хватает в лотусе (дизайнере\клиенте\серваке)", подобно ]]>My Domino Designer 9.0 Wish List]]>? не уверен,что разработчики лотуса обратят на него внимание, а вот разработчикам различных add-on'ов будет полезно. опять же, имхо.

Для: Кирилл Шваб
про нелепые примеры..

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

а print в приведенном примере приводит данные к строковому виду и выводит.. ошибки - ваши выдумки..

Ошибки естественно в голове, где же им еще быть, это никто и не отрицает.

Print приведен для примера. Поэтому написал, что примеры грубы, но главное смысл — отслеживание соответствии типов данных.

Не занудствуйте, почитайте чего-нить по эргономике. Человек не робот, будь ты супер мозгом, ты все равно иногда будешь допускать ошибки. Если среда, в которой ты работаешь, будет предотвращает максимальное кол-во ошибок, то их будет заведомо меньше.

Смысл в том, что текущую среду еще улучшать и улучшать, поскольку некоторые моменты задаются вручную и не контроллируются — соответствено при этом никто не застрахован от ошибок. Хотя вы все равно можете твердить свое и остаться при своих мнениях — ваше право.

На самом деле, Кирилл поднял интересную тему. В моей голове вчера вечером эта тема трансформировалась в такой вопрос:
Почему IBM до сих пор не сделала нормальный IDE для лотуса? Ресурсов у IBM немеряно, посадить 1000 индусов - не проблема. Но почему-то с момента покупки Lotus-а, никаких серьезных изменений в дизайнере просто не было сделано. Это неспроста
Далее у меня возникло предположение: (естессно думать за боссов IBM Lotus трудно, но можно) - они позиционируют Лотус не как средство для разработки каких-либо кастомных приложений вообще.
Лотус позиционируется ТОЛЬКО как средство групповой работы.



А я вот сомневаюсь в этом! Давайте посмотрим на наш рынок систем док-оборота: На рынке с десяток основных игроков, из них документооборот на лотусе - всего у 2х (Интертраст, и забыл еще кто-то).
При том основная часть рынка - далеко не у них. Например ДЕЛО - самописная система на реляционке. Используют в массе мест и тендеры замечательно выигрывают у лотусовых решений.

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


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


P.S.
Только что вышедшая 8я версия Лотуса - замечательный пример. В дизайнер были добавлены какие-то рюшечки, фичи маленькие, целый новый (!) блок Composite Applications в котором почти ничего делать нельзя. Так новые версии не выпускаются ИМХО! Обращаю внимание - это новая major версия очень распространенного продукта. Версия, в которой для разработчика не добавилось практически ничего. То что нам в 8.5 обещают - это всё равно что сказать - покупайте бета-версию , а где-то через полгода мы выпустим релиз.

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

Глупости. Мозги заштампованы реляционками.
У Домины НЕреляционная база (если это можно назвать базой). В ней мета-данные НЕ отделены от данных. Соотв. списка всех полей и нет. Таковой можно исчислить как снимок состояния базы (не дизайна!) в конкретный момент времени. А через секунду - он уже другой.
Список полей упомянутых в дизайне базы? Тоже глупость: док-ты м.б. записаны кодом НЕ из данной базы...
С типом полей разобрались.

Теперь, почему не ругается на конструкции типа doc.Valeus(0)?
А это побочный эффект уступки ленивым программистам (т.н. расширенный синтаксис). Ведь в базе вполне может оказаться док-т с ПОЛЕМ "Valeus".
Вот почему я этот "расширенный синтаксис" ужасно не люблю (и почти не использую). Жаль, что его нельзя выключить (как options в 6-ке)

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

Юзай Делфу+Оракл и радуйся.

Доказывается как теорема (домашнее задание. Предлагаю по-шевелить мозгами, а не лязгать догмами): транзакции и репликация две вещи несовместные. Т.е. на уровне системы. Для отдельно взятого СУБД-приложения часто можно изготовить репликатор; для отдельно взятой базы LND иногда можно состряпать журнал транзакций.

Вот и решай, который из инструментов более адекватен для той или иной конкретной задачи (для централизованной обработки - безусловно СУБД, для распределенной - часто выигрывает LND).

И не надо отверткой забивать гвозди

Константин, не надо так распаляться

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



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

Константин,

после вашего сообщения почему-то вспомил следующую фразу: «Нежелание всегда найдет причину, желание — способ». Если бы все при решении задач размышляли с точки зрении «это невозможно», то мы бы сейчас жили в каменном веке (хотя и до него надо было развиваться и искать решения). Сумбурно, но, думаю, понятно о чем я.


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


Ага, и при этом есть ли такое поле не проверяется. Отличный синтаксис!

Повторюсь в третий раз, это всего лишь примеры. Хотя и для этих примеров можно найти решение — было бы желание. Тут уже вопрос в другом — разумно ли это, т.е. стоит ли над этим работать и будет ли от этого польза.

Подвел для себя маленький итог затронутой темы. Ничего нового для себя не открыл, посмотрел несколько ответов — конструктивных мыслей не видел, везде глупость/ты дурак/так нельзя сделать. Всем спасибо.

Не знаю. Ну, разве что Pick какой-нибудь
Конечно не очевидно. Потому и "домашнее задание". С примером не просто, т.к. в частных случаях (т.е в некоторых конкретных приложениях) эти ф-ции совмещаются. В общем (т.е. на уровне движка СУБД или LND) - нет.
Попробуйте для начала разобрать возможные проблемы транзакции в LND.
Со стороны СУБД найти/обосновать невозможность репликации сложнее...

Ну... Да уж...
Вы дизайните ШАБЛОН. В каких базах надо искать док-ты с полями? Их (баз) м.б. и нет еще. Или есть - в др. доменах на др. серверах.

Вы-б еще от MS потребовали, что-б Publisher проверял целостность http-ссылок. Задачки одного порядка сложности и осмысленности

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

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

Еще раз посмотри то, что тебе написали. Форма - это еще не документ. Это всего лишь элемент дизайна, через который ты будешь смотреть на данные. А данные могут содержать поля, которых может не быть не только в этой форме, но и вообще во всех остальных элементах дизайна.

Вот такую вещь мы однозначно считаем "фичей" Лотуса. Хотя по большому счету это лень программиста, который завел какой-нить флаг в документе, а на форму поленился положить скрытое поле+комментарий. И потом кроме него уже никто не вспомнит что это за поле и зачем оно
Конечно есть случаи, когда заранее невозможно знать что за поля будут в документе, но, я считаю, такую архитектуру всегда можно редизайнить до случая когда все поля известны заранее.

В общем наше обсуждение идет к холи-вару, что лучше для лотуса, его "объектная" модель или реляционка Хотя если бы БД лотуса работала хотя бы в 5 раз быстрее чем сейчас, я бы даже и не вспоминал о таких вещах.


P.S. Сегодня был случай: надо было модифицировать некоторый код в Java-библиотеке. У нас она писалась в Eclipse. Так вот человек используя стандартные рефакторинговые фишки Эклипса изменил кучу вызовов буквально за 5 минут. У меня просто слюнки текли, когда смотрел как это офигенно удобно и просто делается там, вспоминая, насколько геморно и долго это делалось бы в лотусовом дизайнере.
Так что если в 8.5 айбиэмовцы не сделают нормальный современный IDE под лотус, я специально поеду в штаты и всех их там зарЭжу

Кто-нибудь сапгрейдил сервер с 7 до 8? Как полет?

Это означает, что ты предполагаешь обрабатывать ТОЛЬКО структурированную информацию. А как известно, более 90% информации в мире НЕструктурировано.
Еще: хорошо, если адекватная структура данных для некоей конкретной задачи достоверно определяется к тому моменту, как задача уже полностью решена. Чаще она устаканивается только к тому моменту, как обработаны все данные (потому что они структурируются именно в процессе обработки)

А я слышал цифру 80%, если не ошибаюсь, ну да ладно
Но возникает вопрос: а можно ли вообще обрабатывать неструктурированную информацию на компьютере? Хранить - да, безусловно можно, но вот обрабатывать?
Это я к тому, что некое приложение написанное, допустим, на лотусе, должно удовлетворять условию - системе известен тип информации, чтобы она знала как её обрабатывать. Если тип известен - значит должны быть известны какие-то атрибуты. Иначе в обработке этой информации нет никакого смысла, т.к. нельзя обработать неизвестно что. Приходим к тому что информация ОБЯЗАНА быть структурирована, если мы хотим хотя бы минимальной автоматизации работы с ней.

Я встречал задачи, когда заказчик говорил - "нам надо базу для чего-то такого, чего мы пока не знаем". Стандартным ответом было - создайте базу по шаблону Discussion или Doc Library и пользуйтесь. Люди создавали и радовались жизни. Но вы же понимаете что для подобных вещей нам вообще Лотус не нужен, это уровень информационной системы на 2 порядка ниже. У кого нет лотуса хранят доки на диске и пользуются проводником. И тоже иногда радуются жизни



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

Мого-быт. 90 - внушительнее Автоматически - нет. Автоматизированно - да. Чувствуете тонкую разницу?
Еще: что такое "база знаний"? Это неструктурированная информация, пропущенная через мозги экспертов. Типичная задачка для LND, мои юзера сами придумали: в стандартную базу ("дискуссия") "втягиваются" ЦБ-шные нормативные документы (это бесконечный поток Word-овых дополнений к изменениям), эксперты "обвешивают" их Категориями и перекрестными ссылками. Ну, и + FT-индекс. Вся банка потом млела от восторгаА может в этом и есть смысл приложения - искать/строить структуру?Вот тут не согласен. "Затыкание дыр" - основное IMHO предназначение LND
Да, ЧАСТО (если не как правило) в LND так и делается. Его неряляционная база такому способствует.
Это её преимущество (которое провоцирует разгильдяйство программера )

Интересная дискусия получилась ИМХО Лотус - это не программный продукт, это образ мысли.... но это немного оффтоп.

У меня немного приземлунный вопрос - кто-нибудь начал работать с Composite Applications. Кто уже это делалраскажите что из этого получается. Лично мне 8 версия нужна, как зайцу стоп кран, единственное что мне для щастя нужно это возможность найти пути встраивания ява бинов/аплетов в формы заставить из взаимодействовать с родными лотус UI компонентами...

В 8ке вышли новые фичи с еклипсой и я тлеял надежды на то это станет немного проще чем раньше. Где-то на блогах я видел описание того что это станет возможным с использованием Composite Applications. так ли это или нет? а то что-то я разобраться в "куче" документации не могу.

Я не слишком активно лазил в 8м дизайнере, но создание Composite Applications там ограничивается созданием некоего документа с парой свойств.
Как я понимаю, что-то полезное мы сможем начать делать только с 8.5 версии.

Покапался в редбуке, и оказалосьб что для создания композитов используется совсем другая прога, Composite Application Editor, он встроен в еклипс и работает на его платформе, но его функционал что то больно ограничен, я так понял он создает связи между лотус приложением и композитным приложением. Причем для создания композитного приложения нужно создать базу по специальному шаблону "-Blank Compozite Application-". Создал первое композитное приложение, но все равно что то я не догоняю, а зачем это вообще нужно в лотусе?

Простите что запоздал со своим меседжем.

Список полей? На основании форм? Так doc.ItemName - это значение итема. Между полем и итемом есть разница.

Ну, да ладно с этим.

Допустим такое сделали (тока мне такое не надо, шустрить постоянно по базе и перебирать все поля ВСЕХ форм - я лучше Cstr() впишу). Теперь картина маслом.
1. Разработчик сохраняет библиотеку - всё ОК.
2. На след. день меняют тип поля в форме.
3. И библиотека ВДРУГ начинает плевать варнинг.

Знаете, я бы как минимум растерялся.

Ты не много потерял. Здесь у нас споры на религиозные темы. Может нам для этого отдельную тему - религиозную?

В точку!:) Все религии важны, все религии нужны . Главное - не лезть со своим уставом в чужой монастырь. Ну, не пытаться намаз в церкви православной совершать. Или транзакции в лотус впихивать .

Ну тогда было бы не интересно. Нечего было бы обсуждать. А так всем весело...

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

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

1.ЛотусЁвая модель данных более общая, реляционная для неё - частный случай.
2.Или ты не о модели, а о тех замечательных механизмах, которые имеют большинство реляционных СУБД?
Типа: декларативных правил целостности, транзакции, etc?
С 1-м все понятно. Транзакция: ну обеспечишь ты обновление нескольких док-тов "одним квантом" - в данной реплике. А в соседней?? Туда-то эти док-ты будут подтягиваться порознь...

Блин! Ведь было-же что-то очень простенькое. Кто-то из иностранцев на том ежегодном форуме IBM, где презентовали 6-ку, докладывал. Если вспомню - напишу