Swing + Multilingual Database

[nvyush]

Здравствуйте, все!
Собственно вопрос в теме. Хотелось бы хранить локализованные тексты в одном месте.
На LS делал библиотеки со строковыми константами, строку на нужном языке получал через Execute({Use "} + имя_библиотеки + {" : ResultStringForExecute = } + имя_константы), где ResultStringForExecute — глобальная переменная. Как в java получить данные LS библиотеки не представляю, кроме как через dxl (но это не интересно). Использовать настроечные документы тоже проблематично — они при наследовании дизайна не наследуются. Создавать java-библиотеки и "дёргать" через LS2J — подозреваю, будут тормоза. У кого ещё какие есть идеи?

 

[lmike]

есть Shared Resources->Files
там же Style Sheets
детали программного доступа не помню, но он точно есть

Добавлено: в конце-концов - можно просто в форму забить (в поле) и делать её композе/ComputeWithForm/Save (проверяя присутствие и время) в БД и перезаписывая новые настройки (порядок во вьюшке, по времени)
для случая с небольшим списком

 

[lmike]

Создавать java-библиотеки и "дёргать" через LS2J — подозреваю, будут тормоза

на какой стадии - если вынести в инициализацию либы....

 

[nvyush]

Вспомнил про такой элемент дизайна, как outline. Легко получается по имени, имеет коллекцию энтрисов со свойствами label и alias. Вот только не помню, какое ограничение по "ёмкости".

Добавлено

Table of Notes and Domino known limits
Outline entries in an outline — ~21,000 entries

Думаю, хватит.

 

[nvyush]

Поэкспериментировал с outline — всё получается, но "кушает" много памяти на запись. Попробовал использовать папку — дописывать в документ папки два мульти-поля, одно с названиями, другое — с псевдонимами. Получаю документ так: db.getDocumentByUNID(db.getView("viewName").getUniversalID());
Для двадцати записей словарь на outline "весит" 4,6к, на папке — 3,3к (поле подписи в обоих случаях около 1,7к).
Смущает только индексёр — ему "лишние" папки не помешают, если им установить ручное обновление?

 

[nvyush]

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

 

[Kizarek86]

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

Чет сурово как то дла настроечных документов
Библиотека с параметрами Const неустраивает?

 

[VladSh]

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

Хоть, думаю, что индексер особо не будет на такие папки реагировать, идея с папками для хранения настроек что-то мне не нравится...
Фиксированные UNID'ы ещё есть в документах About This Database и Using This Database, только их надо сначаоа вручную создать..

Чет сурово как то дла настроечных документов
Библиотека с параметрами Const неустраивает?

Ага..
Меня как-то профайлы вполне устраивают ))

 

[nvyush]

Библиотека с параметрами Const неустраивает?

Хочу использовать единый источник (по сути — словарь) и для LS и для Java. Хранить там, например, пары значений название поля—подпись. Для каждой формы свой набор словарей под разные языки. Также словари сообщений.

Фиксированные UNID'ы ещё есть в документах About This Database и Using This Database

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

 

[Akupaka]

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

Какое такое наследование профайлов? Отколи это они наследуются из шаблона? Разве что в новой БД, создаваемой из шаблона... Не помню во всяком случае наследования профилей...
Если надо жестко завязаться, то почему не на картинку приложения или About This Database и Using This Database?

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

 

[nvyush]

Какое такое наследование профайлов? Отколи это они наследуются из шаблона?

(клиент 8.0.1)
Не проверял, влияет ли этот флажок на наследование профайлов, в любом случае мне это не подходит

Если надо жестко завязаться, то почему не на картинку приложения или About This Database и Using This Database?

Имеется главный шаблон с общим функционалом, от него наследуется дизайн шаблонами рабочих баз, от которых наследуется дизайн рабочими базами. Как рабочим базам унаследовать специфичные Using This Database от своих шаблонов и одновременно общий Using This Database от главного шаблона?

всегда можно создать документ и впихнуть ему требуемый унид!

Если речь об обычном документе, то они не наследуются. Если речь о документе дизайна, то

... Хотел было использовать аутлайны или подформы, но у них не оказалось свойства UniversalID.

Можно, конечно, жёстко прописать UNID в коде, но какова будет читабельность такого кода?

А вообще обсуждение пошло не в ту степь. Меня в данной теме интересовал лишь вопрос, не будет ли такая реализация (порядка 10-20 фиктивных папок) проблемой для индексера. Обсуждение собственно реализации прошу перенести сюда:
link removed

 

[Akupaka]

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

 

[VladSh]

> Фиксированные UNID'ы ещё есть в документах About This Database и Using This Database
Не UNID, а NoteID (проверено, юниды разные).

Спасибо что напомнили, перепроверил - действительно.
Ещё фиксированный ID у документа свойств БД.

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

Добавлено:

(клиент 8.0.1)
Не проверял, влияет ли этот флажок на наследование профайлов

В 8.0.x этот флажок точно не работал как "наследование профайлов как элемент дизайна", об этом много писали.. В последних версиях - не пробовал (не нужно было), - не знаю.

 

[nvyush]

Какая разница как будет читаться код, если это решение устраивает тебя и пользователей?

Меня не устраивает . Это же застрелиться можно, такое сопровождать.

Если надо записывать инфу отдельными нотами дизайна, то я обычно использовал для этого подформы, на них уж точно индексер не нападёт )).

Вот именно это и нужно. Жаль, но у (под)форм и аутлайнов нет свойства UniversalID. Сейчас по наводке Akupaka решил прописывать в псевдониме аутлайна его UNID (опасался, что при наследовании дизайна UNID не сохраняется, оказалось — зря), тогда ноту можно получать по имени вызовом

Set doc = db.GetDocumentByUNID(db.GetOutline("OutlineName").Alias).

Модераторы, перенесите, пожалуйста, посты, начиная с #17 по этот в тему link removed