OberonCore

Встала надобность читать SQL-запросы из ODC-файла, разделённые маркером (точка с запятой). Запрос может быть длинным, длиной больше 256 символов.
Соответственно, стандартный TextMappers.Scanner не подходит. Задача простейшая, но хочется её решить "методологически правильно", по-блэкбоксовски.
Унаследовать TextMappers.Scanner нельзя, как и перекрыть нужные методы. Копипастить TextMappers и править не хочется
А правка-то нужна минимальная - заменить "скан в строку" на "скан в динамический массив".

Не надо забывать , что кроме TextMappers.Scanner есть TextModels.Reader, который лучше подходит для работы с отдельными символами. ИМХО, сделать можно так:
- запомнили позицию pos
- дочитали до ; или до конца
- создали массив длины r.Pos() - pos + 1
- зачитали в него запрос
...

Спасиб, конечно, за алгоритм. Вопрос же стоит не в том, как работать с отдельными символами. А именно в том, как правильно использовать конструкции BlackBox. Вот хочу я, чтобы у меня был собственный Scanner форматированного текста, на основе стандартного с минимальными изменениями. Но не хочу копипастить стандартный сканер.

Учитывая, как сделан модуль TextMappers, Ваше желание не выполнимо. Выхода только два: либо копировать и править, либо править прямо в TextMappers.

Другими словами, фреймворк BlackBox для обработки текстов реализует шаблон проектирования Carrier-Rider-Mapper, но конкретная реализация Mapper, для чтения текста, в модуле TextMappers, не соответствует моим запросам. Поэтому нужно реализовать Mapper самостоятельно. Исходный текст TextMappers сильно облегчает задачу, да.

Даже позволю себе процитировать документацию:

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

Можно попробовать агрегировать стандартный Mapper, перекрывая его в нужной функциональности и делегируя к нему остальную.

А можно сделать спец. процедуру ScanLongString, которая параметром получает стандартный маппер и оперирует с ним. Как в компиляторе и др. подобных местах - пишется внешняя к Mapper процедура Scan, которая возвращает дополнительные коды лексем.
Вроде так. Если не ошибаюсь... Если ошибаюсь - пардон, уже засыпаю носом в окошко форум

В компиляторе свой сканер.

Так, свой вариант сканера я реализовал. Теперь хочу его использовать.
Насколько я понимаю, стандартная схема такова: определить TextModels.Model, затем подключить мой сканнер к этой модели с помощью ConnectTo. Ну а дальше всё ясно.
Пока в голове не укладывается такой нюанс, как получение модели (в схеме Carrier-Rider-Mapper это есть Carrier. В схеме Model-View-Controller это есть Model, которая, кстати, привязана к View).
То есть, чтобы получить модель через view.ThisModel, мне сперва надо заиметь её отображение (view)? По крайней мере, в исходниках Ящика так и делается. Мне кажется, что это не совсем логично.

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

Назначение View - показать (пользователю) содержимое модели.

Как Вы собираетесь состыковать пользователя и модель без View?

Пользователь видит и работает с Model через View. Мы получаем окно-View с которым работает пользователь, получаем модель, которую пользователь видит через это окно и ... работаем с этой же моделью.

view.ThisModel() - это получение модели, отображаемой в view. То есть, это уже существующая модель.
Чтобы создать новую модель, нужно вызвать TextModels.dir.New()
К схемам C-R-M и M-V-C вам надо ещё добавить деление на абстрактный тип - конкретный тип - директория (Directory, она же "фабрика классов", "class factory"). Тогда ваше представление об архитектурных схемах в BlackBox будет почти полным. (Ещё есть "хуки" - hooks и, возможно, я что-то забыл.)
Надеюсь, я правильно понял ваше затруднение.

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

Шаблон C-R-M, к примеру, имеет райдера. Райдер, требует для себя модель. А модель без отображения загрузиться не может. Такая вот архитектурная связка выходит.


Да, новую модель создать можно. А файл-то уже существует, мне нужно прочесть из него данные. Значит, свежесозданную фабрикой модель нужно сперва как-то соединить с данными из файла. А кроме как через Views.Old это никак не сделать. Это и заставляет призадуматься.

Возможно, эта Ваша формулировка и есть ответ на мой вопрос. Содержимое модели без отображения недоступно извне.

Понимаете, какая штука. Модель может храниться и сама по себе, без отображения - она является Store. Т.е. при сохранении каких-то своих объектов Вы можете вызывать WriteStore для модели напрямую, и никакого отображения не будет...
Но когда Вы загружаете документ ODC - то он является отображением (поскольку на то он и документ, чтобы отображаться пользователю). В кго корне лежит Documents.View, хранящий информацию о размере страницы и проч. (видите, потому и отображение - что глобальные свойства документа являются "отображательскими"). А уже Documents.Model содержит в себе конкретное отображение, например, текстовое или форменное (оно и возвращается Views.Old, а с Document Вы при обычном раскладе отношений не имеете).

И впрямь... Я в начале ветки написал, что использую ODC-файл, хотя это неверно! Я использую документ, а это уже совсем другая абстракция. Да, теперь всё встало на свои места. Коллеги, спасибо большое за отклики!

Почему это недоступно? Модель предоставляет интерфейс для управления своим содержимым.

То, что у Вас хранится в файле, это, скорее всего, должно быть Stores.Store (если не просто данные).
Тогда нужен просто Stores...ReadStore

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