CODEWITHSUNDEEP
oracle-databaseoracle-apex
Ross
Ross

Reputation: 47007

Creating read/write pages in APEX

I'm trying to find a clean way to structure my pages so that the same page can be used for reading a record's contents and for editing it. For example:

  1. You view a record's page. It's contents are displayed as text/whatever.
  2. You click an edit button and the values are presented in textareas, text boxes, LOVs etc.

I'd like to do this without creating a separate edit page and view page for each record. An idea I had was to create two regions - ViewRecord and EditRecord - and display one or the other based on whether a URL parameter was passed (however I'm not sure if this is simple/possible - I'm guessing it can be done in region conditions, however I'm not sure how to access request parameters).

Is there a common/best practice for this kind of activity? How do people usually cope with this?

Upvotes: 1

Views: 1288

Answers (1)

Tom
Tom

Reputation: 7028

I've created a small example, done with request values and conditional display, try it here. The setup is like this:

treeview

Editmode button: Note the condition: i don't want to see this button when 'edit mode' is enabled -> 'show me when request differs from write'. Also, when you first enter the page, the request will be NULL. The edit button will be shown because NULL differs from WRITE.

Edit button code

Readmode button: much the same. In the condition is specifically test the request for write: the button is not shown when request is null.

Read button code

The condition on the tabular form:

tabular form condition

For the read form, the condition is as follows. Again, request differing from WRITE, so the report will show when request is NULL!

report condition

How can you solve this in another way? If you want more dynamic actions, you could use javascript. What i sometimes do, is setting the input attribute readonly to true, and changing the background colour to grey. This will allow the user to tab through the items, but won't let them edit it. I grey them out to show the field is not editable. Don't set disable to true: it'll break the apex functionality since disabled fields don't post their values, while apex expects them. Ex:

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

This would set each input field on your page to readonly, and grey them out. You could use a button, a link, a dynamic action, ... to call this code. Your page won't have to be submitted or reloaded even.

I often even use this, because i specifically don't want to use a 'display item', or even the 'readonly condition': they render the fields as flat text and make it hard to differentiate between label and value. Even in a form (not tabular) i like to use this trick, i find it friendlier to use.

And best practice: i don't know :) I myself usually go the 'form with report' way, but mainly because the customer wants it too. To them, this is the way of easier understanding and maintenance afterwards. It's up to you and your customer to decide i suppose: both methods aren't exactly hard and are pure apex!

Upvotes: 1

Related Questions