АРМ Комплектатор

Появится т.н. "Мастер списания". Возможность выбора одного из вариантов списания: списание по инвентарям(штрих-кодам), для группового учета, книги целиком, журналы целиком, журналы по годам, местам хранения, отдельным номерам. В каждом случае списание может сопровождаться передачей в другое место хранения.
Для каждого варианта будет предложена последовательность действий, состоящая в выборе/задании необходимых данных, т.е. замена ранее выполняемых отдельных режимов. При выполнении Формируется протокол списания-передачи.



Редактировано 1 раз. Последний раз 31.03.2008 16:23 пользователем Alio.

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

Выполняемая последовательность операций отменяет выполнение необходимых ранее операций: занесение номера КСУ списания в настройку, задание в номере КСУ данных о видах, количествах, мест хранения, установку БД каталога, выполнение пакетных заданий на списание и завершение выбытия.

АРМ Книговыдача (ИРБИС64)

Создана подсистема ведения ПЛАТНЫХ УСЛУГ.
Предполагается, что получателями платных услуг являются читатели (или вернее, те, кто включен в БД RDR)
Режим ведения платных услуг вызывается соответствующими пунктом меню (ЧИТАТЕЛИ - ПЛАТНЫЕ УСЛУГИ) и инструментальной кнопкой в окне ЧИТАТЕЛЬ
(общий вид интерфейса представлен на прикрпленном рисунке 1)

Прежде всего (режим СЕРВИС-ПЕРЕЧЕНЬ УСЛУГ) предлагается ввести единый перечень услуг (см. рис.2)

Для каждого читателя ведется список УСЛУГ (выполненных и зказанных) и список ВЗНОСОВ (это могут быть непосредственные оплаты услуг или собственно взносы на личный счет) - две соотвествующие закладки на основном интерфейсе (рис.1)

Для выполнения/заказа услуги служит режим УСЛУГИ/ВЗНОСЫ - НОВАЯ (см.Рис. 3)
Для занесения взноса - тот же режим при соответствующем положении закладки.

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

Для каждого взноса конкретного читателя фиксируются:
- сумма взноса;
- дата/время взноса;
- место обслуживания (выдачи);
- ответственное лицо;
- комментарий

Автоматически (в режиме реального времени) фиксируются (вычисляются на лету):
- объем выполненных услуг для текущего читателя (на соответствующей закладке);
- объем взносов текущего читателя (на соответствующей закладке);
- остаток на счете текущего читателя (на панели инструментов);
- общий объем выполненных услуг по установленному месту обслуживания (выдачи) на текущий день - общее кол-во выполненных услуг, кол-во обслуженных читателей, общая сумма выполненных услуг (на панели инструментов)

В качестве сервиса (меню СЕРВИС) предлагаются:
- получение стат.отчета (распределние выполненных услуг - по их видам - по дням заданного месяца с подсчетом итоговых значений: кол-во услуг, кол-во обслуженных людей, сумма);
- "чистка" и реорганизация БД ПЛАТНЫХ УСЛУГ.

Вся подсистема платных услуг ведется на основе специальной БД - PAY, которая НЕ НУЖДАЕТСЯ ни в каком "ручном" ведении через АРМы Каталогизатор и Администратор.

Желающие тестировать новую подсистему обращайтесь на alio@gpntb.ru

Язык форматирования.
Новый форматный выход: Вернуть символ с заданным кодом

&uf('+9FNNN')

Где NNN - код символа

Такой форматный выход может пригодиться, например, когда надо вывести в литерале символ, совпадающий с ограничителями литерала.

'11111',&Uf('+9F39'),'22222'

результат расформатирования:

11111'22222



Редактировано 1 раз. Последний раз 13.05.2008 12:22 пользователем Alio.

ИРБИС64 АРМ Каталогизатор.
Предлагается новая форма представления СЛОВАРЯ на основном интерфейсе, а именно - на основе технологии ИРБИС-Навигатора.
Т.е. словарь можно представлять на основе произвольного формата c HTML-тэгами. Примеры см. в прикрепленных файлах.
Такая форма основного словаря определяется в сценарии для соответствующего вида поиска путем указания в качестве параметра ТИП СЛОВАРЯ значения 3

ItemDictionTypeNN=3

При этом возможно два способа указания параметра ПРЕФИКС ИНВЕРСИИ (ItemPrefNN)
1.Указывается собственно префикс терминов словаря - в этом случае для представления словаря используются параметры умолчания и в частности - формат. Имя умалчиваемого формата определяется параметром DCWB_PFT в секции [MAIN] ini-файла (IRBISC.INI). По умолчанию - имя умалчиваемого (:)) формата - dcwb_trm0. Параметром DCWB_PORTION определяется умалчиваемый размер порции словаря (по умолчанию - 20)
2. Указывается полная ИРБИС-ссылка (которая может содержать любые необходимые параметры, в т.ч. произвольный формат представления словаря. Опытные пользователи, наверное, догадаются, что в этом случае технология ОСНОВНОГО СЛОВАРЯ полностью совпадает с технологией ПОИСК ДЛЯ УМНИКОВ, т.е. в качестве значения параметра ItemPrefNN можно задавать значения параметра WNLinkNN).



Редактировано 2 раз. Последний раз 23.05.2008 10:21 пользователем Alio.

По последнему предложению: идея хорошая, только нужно предусмотреть:
1. В параметрах показа словаря ограничение в пикселах по высоте строки (возможно значение "автоматически").
2. Возможность переключения вида словаря "на лету" (если это возможно), без изменения ini-файла

PS. Как я понимаю, скоро все окна в интерфейсе ИРБИСа будут переписаны под "Навигатор"?

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

1) Предполагается ли то же и для стандарнтного поиска по словарю?
2) Наличие чеков говорит ли о том что для оперативного поиска теперь возможно объединнение нескольких терминов? Какая логика их объединения?
3) Механизм автоматической установки фокуса ввода на поле в котором содержится термин запроса работать не будет? Подсветка термина в области полного просмотра?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> 1) Предполагается ли то же и для стандарнтного
> поиска по словарю?
Нет.
> 2) Наличие чеков говорит ли о том что для
> оперативного поиска теперь возможно объединнение
> нескольких терминов? Какая логика их объединения?
По умолчанию ИЛИ. Но может быть любая - если задается полная ИРБИС-ссылка, включающая параметр CHECKPFT

> 3) Механизм автоматической установки фокуса ввода
> на поле в котором содержится термин запроса
> работать не будет?
Пока вопрос...

Подсветка термина в области
> полного просмотра?
Да - если используется умолчание (т.е. если в качестве ItemPref задается префикс, а не ИРБИС-ссылка)

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

Проблема в следующем. Для использования в Ирбис национального языка в качестве языка каталогизации требуется локализовать форматы показа и печати, а именно перевести литералы, такие как «Текст», «Электронный ресурс», «и др.», «Б. м.», «б. и.», «Б. ц.» и так далее, а также некоторые меню. Кроме того, если язык каталогизации выбирается в зависимости от языка документа, каждое вхождение литерала или раскодировки через меню нужно заменить на два в ветвях команды IF с выбором по коду языка.

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

Предлагаю вынести локализуемые строки из форматов во внешние текстовые ресурсы (наподобие GNU gettext), это значительно облегчило бы локализацию форматов.
Это можно было бы сделать с помощью форматного выхода, возвращающего строку из внешнего текстового ресурса и принимающего два обязательных параметра: идентификатор ресурса и идентификатор строки, и необязательные параметры, подставляемые в строку на место управляющих последовательностей %s (как в функциях семейства printf). Собственно, предлагаемый форматный выход будет отличаться от &unifor("K…") только поддержкой параметризованных строк. Для чего они нужны? В форматах часто используются конструкции, выводящие число и относящийся к нему литерал, например, “С. “463^s. Где именно располагается литерал – до или после числа – зависит от языка (в общем случае, это порядок определения и определяемого). Параметризованные строки упростят форматы и сделают их менее языкозависимыми.

Согласен.
Предлагаю не создавать новый форматный выход, а расширить уже существующий, из группы &uf('+9...

Это форматный выход &uf('+9C<path>,<dbname>,<filename>') - дающий возможность вставлять целиком заданный текстовый ресурс из окружения ИРБИС
<path> - условный путь окружения ИРБИС (0 - основная директория сервера; 1 - директория DATAI; 10 - Директория БД)
<dbname> - имя БД, задается при path=10
<filename> - имя текстового файла (с расширением)

Предлагается расширить этот форматный выход НЕОБЯЗАТЕЛЬНЫМИ параметрами
&uf('+9C<path>,<dbname>,<filename>,<numb>,<par>')
<numb> - номер строки текстового ресурса
<par> - данные для замены конструкции %s

Жду комментариев от заинтересованных лиц...

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

Может, сделать такой ресурс ini-файлом со структурой вида:

[Название секции_1]
ИМЯ_ПАРАМЕТРА_1=Значение параметра_1 #Комментарий_1
ИМЯ_ПАРАМЕТРА_2=Значение параметра_2 #Комментарий_2
...

Да и имена параметров вместо номеров строк в форматах будут нагляднее.

Еще есть такой вопрос, можно добавить поддержку кодировки UTF-8 в текстовых ресурсах?

>
> Может, сделать такой ресурс ini-файлом со
> структурой вида:
>
> [Название секции_1]
> ИМЯ_ПАРАМЕТРА_1=Значение параметра_1
> #Комментарий_1
> ИМЯ_ПАРАМЕТРА_2=Значение параметра_2
> #Комментарий_2
> ...
>
> Да и имена параметров вместо номеров строк в
> форматах будут нагляднее.
Для реализации этой идеи ничего делать не надо. Такая возможность уже реализована. Есть форматный выход

&unifor('I<SECTION>,<PAR_NAME>,<DEFAULT_VALUE>')

возвращающий значение параметра PAR_NAME из секции SECTION текущего INI-файла (профиля пользователя).

Конечно, включать файл текстов (сообщений) в каждый пользовательский файл нелепо - сейчас это легко может быть решено за счет вложенных INI-файлов.


> Еще есть такой вопрос, можно добавить поддержку
> кодировки UTF-8 в текстовых ресурсах?
А вот такую возможность можно было бы добавить. Например, если значение параметра начинается с символа !, считается, что он задан в UTF8-кодировке.

> Для реализации этой идеи ничего делать не надо.
> Такая возможность уже реализована. Есть форматный
> выход
>
> &unifor('I,,')
>
> возвращающий значение параметра PAR_NAME из секции
> SECTION текущего INI-файла (профиля
> пользователя).

Примерно так: &unifor('IRUSSIAN,STR_1,Нет STR1,Значение-для-подстановки-в-STR_1')?
Я хотел применить секции не для языка, а для разделения общих и специфичных для форматов строк, но можно сделать 'IRUSSIAN_COMMON', 'IRUSSIAN_ASP', 'IRUSSIAN_KN'.

> Конечно, включать файл текстов (сообщений) в
> каждый пользовательский файл нелепо - сейчас это
> легко может быть решено за счет вложенных
> INI-файлов.

Попробовал, не получилось. &unifor('I,,') читает только текущий INI-файл и игнорирует вложенные файлы. Версия 7.1, все пользовательские INI-файлы используют механизм вложения.
Если файл сообщений вложить в серверный INI-файл, он вместе с ним будет передаваться на клиентскую машину? Он там будет использоваться?

> Например, если значение параметра начинается с
> символа !, считается, что он задан в
> UTF8-кодировке.

А зачем задавать кодировку каждого параметра? Файл же будет целиком или в ANSI, или в UTF-8. Может, использовать Byte Order Mark в начале файла?

Еще несколько предложений по АРМу "Администратор". Сейчас для добавления пользователя нужно выполнить целый ряд действий:
1. Создать персональные серверные INI-файлы, скопировав их из чьих-либо других и исправив инициалы (параметр FIO секции Private).
2. Создать учетную запись ("Добавить клиента").
3. Добавить ФИО в справочники FIO.MNU и FIO_SF.MNU тех БД, с которыми будет работать пользователь.
4. Добавить ФИО в шаблон стат. формы, аналогично.

Как эту работу можно упростить? Может, сделать персональные файлы обязательными (раз уж существует секция Private. Кстати, у нас в персональных файлах кроме этой секции и команды [@<имя INI-файла группы>] ничего нет) и создавать их автоматически во время добавления клиента? Также ФИО можно добавлять в справочники на основе чеков, расставленных в матрице доступа.

Kairat написал(а):
-------------------------------------------------------
> Попробовал, не получилось. &unifor('I,,') читает
> только текущий INI-файл и игнорирует вложенные
> файлы. Версия 7.1, все пользовательские INI-файлы
> используют механизм вложения.
> Если файл сообщений вложить в серверный INI-файл,
> он вместе с ним будет передаваться на клиентскую
> машину? Он там будет использоваться?

&unifor('I... работает ТОЛЬКО с серверным INI-файлом. И идея вложенных INI-файлов применима ТОЛЬКО для серверных INI


>
> > Например, если значение параметра начинается с
> > символа !, считается, что он задан в
> > UTF8-кодировке.
>
> А зачем задавать кодировку каждого параметра? Файл
> же будет целиком или в ANSI, или в UTF-8. Может,
> использовать Byte Order Mark в начале файла?

INI-Файлы (по умолчанию) имеют только ANSI-кодировку...

>
> Еще несколько предложений по АРМу "Администратор".
> Сейчас для добавления пользователя нужно выполнить
> целый ряд действий:
> 1. Создать персональные серверные INI-файлы,
> скопировав их из чьих-либо других и исправив
> инициалы (параметр FIO секции Private).
Зачем самому копировать - при добавлении нового клиента, если задается новый INI, он автоматически создается (с использованием идеи вложения)

> > Попробовал, не получилось. &unifor('I,,')
> читает
> > только текущий INI-файл и игнорирует вложенные
> > файлы. Версия 7.1, все пользовательские
> INI-файлы
> > используют механизм вложения.
>
> &unifor('I... работает ТОЛЬКО с серверным
> INI-файлом. И идея вложенных INI-файлов применима
> ТОЛЬКО для серверных INI

Так речь идет именно о личных серверных файлах, не клиентских. Я же написал, что вложенность успешно используется. Но &unifor('I,,') не работает с вложенными файлами. Допустим, в ИИванов.ini вложен _абон.ini, а в него irbisc.ini. &unifor('I,,') видит только параметры, объявленные в самом ИИванов.ini.

> > Если файл сообщений вложить в серверный
> INI-файл,
> > он вместе с ним будет передаваться на
> клиентскую
> > машину? Он там будет использоваться?

Я имел в виду вот что. В пункте 1.5 Общего описания системы сказано, что серверный INI-файл передается клиенту при авторизации. Будут ли вместе с ним передаваться строки из файла сообщений, ведь подстановка вложенного файла происходит до пересылки?

> > > Например, если значение параметра начинается
> с
> > > символа !, считается, что он задан в
> > > UTF8-кодировке.
> >
> > А зачем задавать кодировку каждого параметра?
> Файл
> > же будет целиком или в ANSI, или в UTF-8.
> Может,
> > использовать Byte Order Mark в начале файла?
>
> INI-Файлы (по умолчанию) имеют только
> ANSI-кодировку...

Знаю. Я предлагаю использовать общепринятый способ указания кодировки UTF-8, сигнатурой Byte Order Mark. Созданные в Блокноте или MS Word файлы в UTF-8 будут иметь эту сигнатуру, то есть при чтении файла ее придется обрабатывать.

> > Еще несколько предложений по АРМу
> "Администратор".
> > Сейчас для добавления пользователя нужно
> выполнить
> > целый ряд действий:
> > 1. Создать персональные серверные INI-файлы,
> > скопировав их из чьих-либо других и исправив
> > инициалы (параметр FIO секции Private).
> Зачем самому копировать - при добавлении нового
> клиента, если задается новый INI, он автоматически
> создается (с использованием идеи вложения)

Это идея или существующая реализация? В АРМ "Администратор-Клиент" из версии 2007.1D6 не только новый INI не создается - если INI-файла с таким именем не существует, введенное имя INI-файла стирается и не попадает в CLIENT_M.MNU.

Kairat написал(а):
> Так речь идет именно о личных серверных файлах, не
> клиентских. Я же написал, что вложенность успешно
> используется. Но &unifor('I,,') не работает с
> вложенными файлами. Допустим, в ИИванов.ini вложен
> _абон.ini, а в него irbisc.ini. &unifor('I,,')
> видит только параметры, объявленные в самом
> ИИванов.ini.
Вы очевидно тестируете в GenPFT64 - он не поддерживает вложенные INI. Смотрите непосредственно в АРМах.


>
> Я имел в виду вот что. В пункте 1.5 Общего
> описания системы сказано, что серверный INI-файл
> передается клиенту при авторизации. Будут ли
> вместе с ним передаваться строки из файла
> сообщений, ведь подстановка вложенного файла
> происходит до пересылки?
ВСе будет передаваться.

>


> Это идея или существующая реализация? В АРМ
> "Администратор-Клиент" из версии 2007.1D6 не
> только новый INI не создается - если INI-файла с
> таким именем не существует, введенное имя
> INI-файла стирается и не попадает в CLIENT_M.MNU.
Это реализовано. Если у Вас этого нет - обновитесь...

> Вы очевидно тестируете в GenPFT64 - он не
> поддерживает вложенные INI. Смотрите
> непосредственно в АРМах.

Очевидно, что GenPFT64 работает только с GenPFT64.ini - я же проверял в АРМ "Каталогизатор" на рабочей системе с серверными INI-файлами реальных пользователей. Затем установил в Virtual PC версию 2007.2, перебрал все апдейты с D1 по D4 - все-таки &unifor('I,,') не работает с вложенными файлами. Прилагаю скриншот.


> > серверный INI-файл
> > передается клиенту при авторизации. Будут ли
> > вместе с ним передаваться строки из файла
> > сообщений, ведь подстановка вложенного файла
> > происходит до пересылки?
> ВСе будет передаваться.
>

Я написал скрипт, который извлек из всех форматов PFT, GBL, FST из папки IBIS все уникальные литералы, содержащие хотя бы один символ кириллицы. Получилось 55 Кб, 1630 литералов. Перекодировка в UTF-8 удвоит объем. Переведенный ресурс составит примерно столько же. Имена параметров займут минимум 15 Кб для одного языка.
Таким образом, клиенту будут передаваться 200-250 Кб не используемых им данных, в то время как серверный INI-файл занимает максимум 40 Кб. При таком побочном эффекте стоит ли использовать для локализации существующий &unifor('I,,')?


> > Это идея или существующая реализация? В АРМ
> > "Администратор-Клиент" из версии 2007.1D6 не
> > только новый INI не создается - если INI-файла
> с
> > таким именем не существует, введенное имя
> > INI-файла стирается и не попадает в
> CLIENT_M.MNU.
> Это реализовано. Если у Вас этого нет -
> обновитесь...

Эта функция появилась в АРМ "Администратор-Клиент" только в версии 2007.2. К сожалению, она не документирована. IRBIS_SERVER.EXE создает INI-файлы и в версии 2007.1, но, во-первых, без использования вложения (копированием), во-вторых, его интерфейс недоступен, если работает сервис...

Хорошо, одной проблемой меньше. А можно ли сделать автоматическое ведение справочников FIO.MNU и FIO_SF.MNU?
Сейчас они по-каталожные, то есть для добавления ФИО нужно перебирать папки БД ЭК, к которым имеет доступ конкретный пользователь. Как минимум, можно сделать FIO.MNU общесистемным (кажется, так: FIO.MNU\SYS,0? Или в Депозитарий ресурсов можно поместить MNU, используемые в рабочих листах?). В идеале, ФИО пользователя можно рассматривать как атрибут его учетной записи и хранить в CLIENT_M.MNU, а FIO.MNU формировать автоматически.
Сложность возникает с FIO_SF.MNU, который задействован в генерации отчетов. Он обязан быть именно справочником пользователей конкретной БД. Легко определить, к каким БД имеет доступ пользователь (по DBNNAMECAT). Но трудно определить, какие пользователи имеют доступ к данной БД (только перебором пользователей). Возможно, стоит создать словарь ПОЛЬЗОВАТЕЛЬ-КАТАЛОГ в служебной БД.

Kairat написал(а):
-------------------------------------------------------
> Очевидно, что GenPFT64 работает только с
> GenPFT64.ini - я же проверял в АРМ "Каталогизатор"
> на рабочей системе с серверными INI-файлами
> реальных пользователей. Затем установил в Virtual
> PC версию 2007.2, перебрал все апдейты с D1 по D4
> - все-таки &unifor('I,,') не работает с вложенными
> файлами. Прилагаю скриншот.
Вы правы. Была ошибка. Исправлено (irbis64.dll). Появится в ближайшем апгрейде.


>
>
> Я написал скрипт, который извлек из всех форматов
> PFT, GBL, FST из папки IBIS все уникальные
> литералы, содержащие хотя бы один символ
> кириллицы. Получилось 55 Кб, 1630 литералов.
> Перекодировка в UTF-8 удвоит объем. Переведенный
> ресурс составит примерно столько же. Имена
> параметров займут минимум 15 Кб для одного языка.
> Таким образом, клиенту будут передаваться 200-250
> Кб не используемых им данных, в то время как
> серверный INI-файл занимает максимум 40 Кб. При
> таком побочном эффекте стоит ли использовать для
> локализации существующий &unifor('I,,')?
Это несущественные объемы - тем более что это происходит один раз при старте клиента...

АРМ Книговыдача ИРБИС64

Обеспечена связь между АРмом Книговыдача и ИРБИС-Навигатором для проведения поиска и выдачи без заказа из ИМИДЖ-Каталога.

Стандартный режим ВЫДАЧА БЕЗ ЗАКАЗА позволяет искать (или вернее, идентифицировать) выдаваемое издание по каким либо структурированным (поисковым) элементам: инвентарь, штрих-код, шифр, автор, заглавие и т.п. В случае ИМИДЖ-Каталога этого сделать нельзя, поскольку документы ИМИДЖ-Каталога не имеют (в исходном состоянии) никаких структурированных элементов описания. В связи с этим и предлагается новая возможность в АРМе Книговыдача - переход (с помощью соответствующего режима) в ИРБИС-Навигатор для работы с ИМИДЖ-Каталогом. При этом для работы с ИМИДЖ-Каталогом в ИРБИС-Навигаторе предлагается тот же интерфейс, что и читательский поиск - с одним отличием: вместо ссылки ЗАКАЗАТЬ появляется ссылка ОФОРМИТЬ ВЫДАЧУ.

Web-ИРБИС
Обеспечена возможность создания распределенных баз данных ИРБИС на основе Web-технологии.
Суть возможности - виртуальное объединение автономных электронных каталогов системы ИРБИС в единый поисковый ресурс с точки зрения конечного Интернет-пользователя, т.е. обеспечение возможности сквозного поиска (по одному запросу) в электронных каталогах РАЗНЫХ библиотек, доступ к которым осуществляется на основе Web-ИРБИС.

Список участников такой распределенной системы определяется в соотвествующем справочнике.

В частном случае, в такой список можно включать разные БД одной библиотеки (тем самым может быть реализован единый поиск по нескольким БД в рамках одной библиотеки)

Эта возможность найдет применение и в
АРМе Каталогизатор -
в режиме заимствования из ресурсов Web-ИРБИС. А именно: появится возможность проводить поиск (с целью заимствования) по одному запросу сразу в нескольких (или всех) электронных каталогах других библиотек.



Редактировано 2 раз. Последний раз 05.08.2008 11:15 пользователем Alio.

Хочется обсудить с заинтересованными пользователями одну идею для ИРБИС64:

СЕРВЕРНЫЕ ФУНКЦИИ ПОЛЬЗОВАТЕЛЯ.
(не путать с функциями пользователя для АРМа Каталогизатор и &uf('+8...)

Идея состоит в том, чтобы дать возможность пользователю осуществлять собственный контроль и перестроение КАЖДОЙ корректируемой/создаваемой записи в БД.
Сейчас каждая запись, передаваемая серверу для корректировки/создания, в обязательном порядке проходит следующие этапы:
1. Автоввод
2. Сохранение в БД
3. Актуализация

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

В серверной функции пользователя могут выполняться любые действия, в т.ч. корректировка записи, при соблюдении следующих условий:
- функция должна быть пакетной (т.е. без пользовательского интерфейса)
- функция не должна быть продолжительной (время ее выполнения будет включаться в длительность операции СОХРАНЕНИЯ в АРМе Каталогизатор)

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

Предполагается, что интерфейс передачи данных для серверной функции пользователя будет такой же, как для клиентских функций пользователя (в АРМе Каталогизатор) и &uf('+8...), т.е. серверная функция пользователя должна создаваться как функция DLL с тремя входными параметрами (входной буфер с исходными данными, выходной буфер и размер выходного буфера)

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

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

ЭВРИКА!!! такую функцию можно использовать для ведения статистики. Это как раз то, чего очень не хватало :).



Редактировано 1 раз. Последний раз 05.08.2008 18:05 пользователем Панев Максим.

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

Не надо СЕРВЕРНУЮ ФУНКЦИЮ ПОЛЬЗОВАТЕЛЯ понимать так узко - только лишь как средство корректировки записи. Прежде всего - это "зацепка", "перехват", который позволяет пользователю производить какие-либо действия всякий раз, когда запись обновляется.
В частном случае функция пользователя никакой корректировки может не производить (в каком виде запись приняла, в таком и отдала), а выполнять совсем другие действия...

Новые решения для версии 2008.1

АРМ Полнотекстовый Читатель
1.Возможность поиска по точным терминам без отсечения окончаний. Для этого ставится отметка в окошке «Точный термин», либо термины заключают в кавычки.
2.Наряду с полнотекстовым поиском обеспечивается возможность поиска по элементами описания (биб.элементам): автору, заглавию, УДК, издателю и т.п.
3.Возможность сочетания полнотекстового поиска и поиска по элементам описания.

АРМ Полнотекстовый Администратор
1. Стало возможным индексирование файлов формата DJVU (файлы должны иметь текстовый слой!).
2. Автоматическое разбиение на страницы файлов DJVU и PDF - страницы формируются динамически при индексировании базы данных и при их показе – позволяет более точно организовать поиск внутри текстов значительного объема. Страницы связываются между собой, так что возможно постраничное листание при показе найденных текстов.
3. Разработан режим кэширования терминов для ускорения поиска, в том числе поиска по сходству. Этот режим особенно эфективен при работе с базами данных большого объема.



Редактировано 2 раз. Последний раз 07.08.2008 18:01 пользователем Alio.

АРМы Каталогизатор и Читатель (ИРБИС64).

Введен Новый параметр в сценариях поиска:
ItemPftNN - определяет имя формата, который используется для показа документов, найденных по данному виду поиска. Указанный формат должен обязательно находиться в списке доступных форматов показа (см. параметр PFTMNU в Приложении 1 Общего описания). Если данный параметр не задан, для показа результатов поиска используется текущий формат.

Готовится новая редакция документации (в электронном виде), учитывающая все релизы до 2008.1

Маленькое рацпредложение для формы списка клиентов для доступа к серверу (прежде всего локальной конечно - на головной машине):

Добавить кнопку "редактировать INI-файл" инициирующую запуск "psetini.exe <файл.ini>".

Просто замечательно было бы добавить такой же функционал к клиентскому администратору. Тут конечно необходима доработка самого psetini - чтобы он знал что его запустили в режиме клиента и "скормили" ему не реальный файл с диска, а просто набор строк. И что при сохранении ему надо вернуть этот набор строк Администратору, а также что при вызове вложенного ини-файла надо не искать его в системе, а направить запрос тому же Администратору.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Маленькое рацпредложение для формы списка клиентов
> для доступа к серверу (прежде всего локальной
> конечно - на головной машине):
>
> Добавить кнопку "редактировать INI-файл"
> инициирующую запуск "psetini.exe <файл.ini>".
Это можно принять

>
> Просто замечательно было бы добавить такой же
> функционал к клиентскому администратору. Тут
> конечно необходима доработка самого psetini -
> чтобы он знал что его запустили в режиме клиента и
> "скормили" ему не реальный файл с диска, а просто
> набор строк. И что при сохранении ему надо вернуть
> этот набор строк Администратору, а также что при
> вызове вложенного ини-файла надо не искать его в
> системе, а направить запрос тому же
> Администратору.
А вот это - нет.