WYSIWYG редактор в FileMaker

Автор: Перла Аркадий (компания «ТриАПринт»)

WYSIWYG-редактор — это то, что пожалуй, сильно не хватает FileMaker. В принципе в FileMaker есть возможности форматирования текста внутри поля, для этого достаточно сделать видимой Formating Bar либо воспользоваться командами из меню Format. Но у этих способов есть ряд существенных недостатков, как с точки зрения разработчика, так и пользователя.

Во-первых, панель Formating Bar отображается по всей длине окна что создает впечатление у пользователя, что он может применить форматирование в любом из полей на экране, тогда как разработчику это может быть вовсе не нужно. Поэтому чтобы не возникало соблазна разработчик вынужден контролировать какое поле в данный момент активно, и в зависимости от этого, показывать или скрывать панель форматирования командой Allow Formating Bar. Это создает эффект «мельтешения» на экране. Было бы более наглядно, если бы панель форматирования появлялась бы над самим полем.

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

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

В нашем примере мы воспользуемся редактора Quill, который обладает следующими приятными свойствами:

  • Сравнительно простой редактор, не перегруженный множеством функций. В конце концов у нас нет задачи превратить поле в MS Word.
  • Приятный и стильный интерфейс панели форматирования идущий «в комплекте» с редактором.
  • Небольшой размер (около 200кб)
  • Понятное и документированное API с примерами на сайте разработчика
  • Бесплатный и Open Source проект

На демонстрации ниже видно работу редактора в FileMaker. В качестве примера был разработан файл wwg_editor.fmp12 который можно скачать по ссылке в конце страницы.

Как это работает?

Подготовка к работе.

Для того чтобы webviwer отобразил наш редактор, нам нужно сформировать соответствующую html-страницу с встроенным javascript-кодом редактора и стилями CSS. Сам редактор Quill состоит по сути из двух файлов: quill.min.js и quill.snow.css (еще есть quill.js — это тот же quill.min.js, но с комментариями и разметкой разработчиков). Оба эти файла должны подгружаться в нашу html-страницу в момент ее отображения webviwer-ом. Мы можем указать глобальную ссылку на эти файлы, но по-скольку мы не хотим чтобы наш FileMaker-проект зависел от наличия интернета, то разместим эти файлы локально.

В специальной таблице wwg_edior, которая содержит только одну запись созданы поля-контейнеры для хранения файлов редактора: js и css файлов, а также третий контейнер для хранения шаблона html страницы.

В момент открытия fmp12-файла запускается специальный скрипт wwg_editor_init, который делает следующее:

  • экспортирует все три файла из контейнеров во временную папку FileMaker при этом запоминая пути к файлам
  • читает в глобальное поле wwg_editor_html_global содержание файла экспортируемого из поля wwg_editor.html
  • заменяет с помощью команды Substitute ключевые слова html-тексте на пути к файлам js и css

В результате у нас в глобальном поле оказывается шаблон html-страницы редактора с уже прописанными корректными путями к js и css.

Обратим внимание, что формат локальных ссылок к файлам компьютерах с OS X и Windows традиционно отличается. Поэтому, в скрипте предварительно мы определяем платформу и формируем ссылку с учетом этого. Кроме того тип платформы (Mac или Win) мы также прописываем в html в виде переменной в javascript-коде (конечно мы могли бы воспользоваться функциями самого javascript, но такой способ мне представляется проще)

wwgeditor_1

Организация данных для редактора

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

В своем примере я решил использовать чудесную возможность FileMaker полей — Repetitions. Поле format_text из файла примера содержит два repetitions. Первое — для хранения текста, второй — для хранения html. По сути, второй repetition выступает как дополнительное свойство поля.

wwgeditor_2

Встраиваем редактор в лайоут FileMaker

Реализовать работу WYSIWYG-редактора в лайоуте можно по разному. Мне показалась правильной идея, что пользователь не может редактировать текст в поле сразу, форматированный текст отображается в режиме просмотра и только нажав Edit, он переходит в режим редактирования. Завершив редактирование пользователь нажимает Save и поле возвращается в режим просмотра.

Для реализации этой идеи я использовал слайдер. На первом слайде размещается  webviwer и кнопка Edit. Этот webviwer должен только отображать форматированный текст, js-редактор нам отображать здесь не нужно. wwgeditor_3

Кнопка Edit вызывает скрипт с одной только командой Go to Object для переключения на второй слайд, где также расположен webviwer.

wwgeditor_4

На этот раз для формирования кода для webviwer я использую custom-функцию wwg_editor_create ( html ; script_name ; text_init ). Эта простая функция имеет три параметра:

  • html  — текст шаблона будующей страницы webviwer. Сюда мы передаем значения нашего глобального поля wwg_editor_html_global, которое мы создали в начале статьи.
  • script_name — имя скрипта, который будет вызываться по нажатию кнопки Save для сохранения результатов работы пользователя в редакторе в поля нашей базы.
  • text_init — текущее значение поля для инициализации работы редактора (иначе у нас каждый раз будет открываться пустой редактор)

Код функции wwg_editor_create очень простой — функция заменяет в переданном html ключевые слова на необходимые данные:

"data:text/html, " & 
Substitute ( html ;
["@@@URL@@@"; "fmp://$/" & Get ( FileName )];
["@@@SCRIPT@@@" ; script_name ];
["@@@INIT@@@" ; Substitute( text_init ; "\""; "\\\"" ) ]
)

Редактор уже готов к работе.

Сохранение данных

Для того чтобы вызвать скрипт сохранения (в нашем случае скрипт с говорящим названием SaveText) мы используем функцию javascript, которая «висит» на нашей кнопке Save. Эта функция получает текущее содержание редактора quill с помощью методов API getHTML() (форматированный текст) и getText() (очищенный от html кода текст) и вызывает наш скрипт.

Для того чтобы вызвать filemaker-скрипт изнутри webviwer мы используем свойство window.location, присваивая ему ссылку на наш filemaker-файл. Именно для этого мы при формировании кода webviwer передавали ранее в функцию wwg_editor_create строку «fmp://$/» & Get ( FileName ).  Префикс «fmp://$/» сообщит webviwer, что при открытии ссылки нужно использовать протокол fmp (его поддержка устанавливается в систему при инсталляции FileMaker), а знак $ сообщит, что  Get ( FileName ) нужно искать среди уже открытых файлов.

Шаблон ссылки выглядит так (аналогично при использовании xml-вызова FileMaker Server):

fmp://$/filename.fmp12?script=scriptname&param=parameter

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

С передачей параметров, однако, имеется некоторая сложность. Дело в том, что под Windows (так как webviwer использует движок IE) существует ограничение на количество символов в строке ссылки, оно не должно превышать 2083 знака. Этого может оказаться недостаточно для передачи текста из редактора. Поэтому под Windows для передачи содержания редактора мы используем буфер обмена, копируя текст в нашей javascript-функции и извлекая его в скрипте Filemaker-а. В OS X, webviwer основан на движке Safari и там такого ограничения нет. Есть соблазн для упрощения кода использовать буфер обмена на обоих платформах, однако,  javascript-функции для работы с буфером обмена в разных браузерах разительно отличаются (как ни странно, работа с буфером обмена в веб до сих пор не пришла к единому стандарту), так что использовать один и тот же код не получится. В нашем случае, функция сохранения в коде javascript выглядит так:

function save_fm() {
 var fmParam;
 if (fmPlatform == "Mac") {
 fmParam = encodeURIComponent (editor.getHTML() ) + "@@@fm-parameter-devider@@@" + encodeURIComponent ( editor.getText())
 window.location = fmUrl + fmParam;
 }
 else {
 if (window.clipboardData) {
 fmParam = editor.getHTML() + "@@@fm-parameter-devider@@@" + editor.getText(); 
 window.clipboardData.setData( 'Text' , fmParam );
 window.location = fmUrl;
 } else {
 alert ('window.clipboardData - Не поддерживается! :((')
 }
 }
 
};

Как видно в обоих случаях, передаваемый параметр (содержание редактора) мы делим ключевым словом @@@fm-parameter-devider@@@, отделяя html-часть содержание от очищенного текста. Такой длинный разделитель используется чтобы предотвратить случайное его использование в содержании текста.

Вызываемый скрипт SaveText анализирует переданный параметр, сохраняет значения в оба repetitions и возвращает пользователя на первый слайд — режим просмотра.

wwgeditor_5

Скачать файл wwg_editor.fmp12 можно здесь. Очевидно, что показанная реализация WYSIWYG-редактора далеко не единственная, любой желающий может применить эту технологию в своих проектах, при необходимости усовершенствовав или доработав.

    • в серверной реализации ничего особенного нет. Даже php не нужен, достаточно обратится к FM-серверу по xml запросу и вызвать тем самым соотвествующий скрипт, передав ему параметры. Скрипт может быть точно таким же, фактически.

    • такой вариант должен и в webdirect и FM GO на iOS работать.

    • ну, там была бы принципиально другая реализация.
      Данные получаются и возвращаются по ODBC.
      Параметры (имена): файл-источник, таблица, поле_текст, поле_хтмл, where condition (кстати, интересно, распознает ли ODBC репетиции).
      Универсальный запрос, универсальное добавление.
      Ну и внешне: просмотр и редактирование на разных вкладках. на вкладке «редактирование» кнопка «Сохранить» сохраняет изменения в фм, но не переводит на первую вкладку
      то есть не используются ни буфер обмена, ни вызов скрипта фм из веба.

      ЗЫ. Получить внутри хмл некую хтмл разметку чрезычайно проблематично (по моему опыту). Мне не удалось решить эту задачу.

    • нет-нет — вы усложняете.
      сохранение данных можно делать просто вызвав fm-скрипт на сервере xml-запросом, с передачей параметров прямо из javascript. Пробовал — работает.
      но сам редактор, придется несколько переделать. Делать не два вебьювера, а один и кнопки edit/save реализовать целиком на javascript, чтобы редактор сам переключался в режим просмотра/редактирования (вернее активизировался). Переписать html шаблон не очень сложно, для такой задачи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

32 + = 37