So now we have the ability to add a new
person document to our database via XPages but you may have noticed that
there are some fields that are set as readonly when the document is in
edit mode because you wouldn’t want the end user changing them. The main
fields that have been turned off so far are the users name and location.
In this part we will turn them back into editable fields but only when
you are creating a new document.

In traditional Notes client development
there is a formula called @IsNewDoc that we can use to determine if a document
has just been created and has never been saved yet. In XPages we can make
use of our formula language knowledge and use @IsNewDoc() in our JavaScript
to do the exact same thing.

Open the content_Person custom control
and from the design view select the ‘firstname’ editbox control. If you
look at the properties for the control you’ll see that the ‘ReadOnly’ property
is currently ticked on. We need to compute this value instead so click
on the diamond and select the compute value option. Here’s the JavaScript
I have written :

I have added this code to all the fields
that that I had originally set as ReadOnly. Save and refresh your XPage
and try create a new person and you’ll see the fields are now editable.

While they are editable it doesn’t look
great, there are no lables for the data entry person to know what to type
in so lets add some labels and set them so they only appear when you are
creating a new document.

Drag in a label control from the controls
pane on the right of your screen. Set it’s value to whatever label you
are applying and then in the ‘visible’ property click the diamond and use
the same code as above except reverse the logic, this time you need to
return ‘true’ when it is a new document.

Here’s how my content_person design
view looks now :

You can see I also added a table to
help align the labels over the fields. Now when I save my XPage and preview
it in the browser it looks like this :

In the next part We’ll add a default
value for the location and also look at how we can change it into a dropdown
list of all the valid locations.

So far in our application we have shown
you how to display the current documents in the database and how to edit
existing person documents. Over the next few parts we are going to add
in some controls that will allow you to create new documents if you have
the [PhonebookEditor] role in the ACL of your application.

Creating a document is an action so
we need to add in an actionbar and action button to the design of our application.
I’m going to create my action button in the content_location custom control
just above the pager that I’m using for the list of people at a location.

Instead of building the action button
from scratch I’m going to reuse some code form the content_person custom
control. Start by pening that control and switching to the source view.
You’ll need to find the xp:panel tag that contains the styleClass of ‘lotusActionBar’
and copy everything between and including those xp:panel tags to the clipboard.

Then open your content_Location custom
control, switch to the source view and find the <xp:pager> tags,
add in a new line just above it and then paste in the contents of your
clipboard. If you switch back to design view you should see your new panel
in the design containing the buttons that we had created for the content_person
custom control.

Delete the last two buttons in the panel
we don;t need them here and then look at the properties for the ‘Edit Document’
link. The first thing we will change is the label so that it reads ‘Create
Person’.

Next we need to change when the button
is visible. Change the computed value for the visible property to

And the last thing we need to do is
change what happens when the user clicks on the action. Switch to the ‘Events’
tab for the link and in the ‘onClick’ event remove the current action and
then click on the ‘Add Action’ button to add a new action.

We are going to create a basic action
that will open the ‘Person’ Xpage and set the target document to ‘New Document’.

If you save and preview your XPage and
you have the correct role you should now see your ‘Create Person’ button.

Clicking the button will bring you to
the Person XPage that we designed earlier with a blank person document
loaded up and already in edit mode.

In the next part we’ll adjust the person
document so that the uneditable fields are editable when it detects your
creating a new document.

Over the course of the series we have been
using some small snippits of JavaScript to compute the values of properties
and labels on our XPage. A lot of our JavaScript so far has followed styles
that we are familiar with in LotusScript and Formula language but we have
had to make some subtle changes so that it would fit within the conventions
of the JavaScript language.

When developing your XPage application
you may have come across ‘Error 500’ in your web browser, how it appears
to you depends on the web browser you are using.

The normal cause of this error is a
problem with your JavaScript code that was executing on the server. The
error message above doesn’t really help you beyond knowing the fact that
there was an error.

If you look at the application properties
for your database there is a section for errors and timeouts in the xpages
tab.  Turn on the ‘Display default error page’ option.

Now if you save the application properties
and refresh your XPage that was giving you the error you should see a much
more helpful error page :

It’s still not perfect, the page name
above is not exactly where the error is. In this case I purposely caused
my error in the content_HomePage custom control but the rest of the error
message really does help me pinpoint exactly where the error occurred and
knowing what line of code caused the error can help you fix it quickly.
In this case I used GetColumnValue instead of getColumnValue.

Once your finished your XPages application
you may want to turn that application property back off incase a user causes
some sort of error. I don’t know about you but I’d rather my users didn’t
see such detailed error messages. I’d prefer to keep it nice and simple
for them and the XPages processor allows us to do that also.

Back in the application properties you
can select an XPage to be displayed if there is an error. This could be
a simple ‘An Error Has Occurred, Click here to return to the homepage’
type XPage or you could have a form asking the user to enter in what they
were doing and then you can email that to the application developer. The
options are limitless. here’s an option where I redirect to a debug xpage.

My debug page shows me the values of
all the session and application scope variables at the time of the error
and the page will be included in the next downloadable version of the database.