Создание страниц чтения / записи в APEX - PullRequest
Новая
       4

Создание страниц чтения / записи в APEX

1 голос
/ 04 декабря 2011

Я пытаюсь найти чистый способ структурировать свои страницы так, чтобы одна и та же страница могла использоваться для чтения содержимого записи и для ее редактирования.Например:

  1. Вы просматриваете страницу записи.Его содержимое отображается как текст / что угодно.
  2. Вы нажимаете кнопку редактирования, и значения представляются в текстовых областях, текстовых полях, LOV и т. Д.

Я хотел бы сделать этобез создания отдельной страницы редактирования и просмотра страницы для каждой записи.У меня была идея создать две области - ViewRecord и EditRecord - и отобразить одну или другую в зависимости от того, был ли передан параметр URL (однако я не уверен, что это просто / возможно - я предполагаю, что это можно сделатьоднако в условиях региона я не уверен, как получить доступ к параметрам запроса).

Существует ли распространенная / лучшая практика для этого вида деятельности?Как люди обычно справляются с этим?

1 Ответ

1 голос
/ 04 декабря 2011

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

treeview

Кнопка редактирования режима: обратите внимание на условие: я не хочу видеть эту кнопку, когда включен «режим редактирования» -> «показывать мне, когда»запрос отличается от записи '.Также при первом входе на страницу запрос будет НЕДЕЙСТВИТЕЛЕН.Кнопка редактирования будет показана, потому что NULL отличается от WRITE.

Edit button code

Кнопка режима чтения: во многом то же самое.В условии специально проверяется запрос на запись: кнопка не отображается, когда запрос нулевой.

Read button code

Условие в табличной форме:

tabular form condition

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

report condition

Как вы можете решить эту проблему другим способом?Если вы хотите более динамичные действия, вы можете использовать JavaScript.То, что я иногда делаю, это установка атрибута ввода только для чтения и изменение фона на серыйЭто позволит пользователю перемещаться по элементам, но не позволит им редактировать его.Я выделяю их серым цветом, чтобы показать, что поле недоступно для редактирования.Не устанавливайте disable в true: это нарушит функциональность apex, поскольку отключенные поля не публикуют свои значения, в то время как apex ожидает их.Пример: 

$("input").attr("readonly", "true");
$("input[readonly='true']").css("background-color":"grey");

Это установит для каждого поля ввода на вашей странице только чтение и выделит их серым цветом.Вы можете использовать кнопку, ссылку, динамическое действие, ... для вызова этого кода.Ваша страница не должна быть отправлена ​​или перезагружена даже.

Я часто даже использую это, потому что я специально не хочу использовать «отображаемый элемент» или даже «условие только для чтения»: они отображаютполя как плоский текст и затрудняют различие между меткой и значением.Даже в форме (не табличной) мне нравится использовать этот трюк, я нахожу его более удобным для использования.

И лучшая практика: я не знаю :) Я сам обычно использую способ «форма с отчетом», но в основном потому, что клиент тоже этого хочет.Для них это способ облегчения понимания и обслуживания после.Я полагаю, что вы и ваш клиент должны решить, что оба метода не так уж сложны и верны!

...