Learning XPages Part 36 : Saving The Document And Hiding The Actions

Posted on March 5, 2009 by qtzar

For either the client side or server side
validation that we covered in the last few section to do its job and check
the fields and return an error if invalid we need to save the document.
Let’s create the save button in the action bar. Open the content_Person
custom control again and drag a new link into the area beside the ‘Edit
Document’ button that we created earlier and change it’s label to ‘Save
Document’

A picture named M2

Now switch to the events tab and select
the ‘onClick’ event. Using the ‘Add Action button I have added in two actions.
The first action will save the document

A picture named M3

and the second action will switch the
document back into read mode.

A picture named M4

when your done your actions list will
look something similar to this :

A picture named M5

This is just like creating an action
in the traditional notes client form to do a @Command([FileSave]);@Command([FileCloseWindow]);

If you save the custom control and preview
your XPage you will now see your save button beside the ‘Edit Document’
button and you can test out any validation you did in the last few parts.

A picture named M6

Of course there is no point displaying
the ‘Save’ button when the document is not in edit mode and no point displaying
the ‘Edit’ button when the document is already in edit mode so lets fix
that up right now.

In your data source for the page we
have defined the document as an object called ‘personDoc’. Select the ‘Save
Document’ link again and look for the ‘Visible’ tickbox and click on the
diamond  and select ‘compute value’. In the JavaScript dialog box
enter in personDoc.isEditable(); and then OK the dialog box and
save and refresh your Xpage. The save button should now disappear when
you are in read mode and should only show when your in Edit Mode.

To make the ‘Edit Document’ button disappear
when the document is in edit mode you can use the NOT value of the same
JavaScript expression like this :  !(personDoc.isEditable());

A picture named M7

A picture named M8

In the next part of the series we’ll
add a ‘Rich Text’ control to the form for an ‘About Me’ style area.

Tagged with: , , ,
Posted in None

Learning XPages Part 35 : Advanced Validation Using RegEX

Posted on March 5, 2009 by qtzar

The validation for the JobTitle field was
fairly simple, we made sure it existed and that it was between 10 and 50
characters in length but what if you want to do some more advanced validation
like confirm that a phone number only contains numbers and the + and –
characters or that an email address contails the @ and . symbols? To do
this we need to create a ‘Constraints’ validation using RegEx. Regular
Expression is a method to identify patterns of characters in a string and
can range from simple to very complex. I won’t get into the entire RegEx
format here but I will provide a few commonly used RegEx Expressions.

Lets open the content_Person custom
Control again and select the ‘OfficePhoneNumber’ edit control. If you are
using server side validation then don;t forget to add in a ‘Display Error’
control and link it to the OfficePhoneNumber edit control and then in the
edit control’s properties disable the client side validation ( assuming
you didn’t set the entire app to Server Side Validation in the application
properties )

A picture named M2

I have also made the edit box control
a ‘Required Field’ by turning on the option in the validation tab or it’s
properties.

A picture named M3

Now go down to the ‘All Properties’
for the edit box control and look at the Data – Validators section. If
you click on it you’ll get a  small + and – button appearing in the
row and clicking on the + button will bring up the list of different validators
that you can add to the edit box

A picture named M4

We are going to use the xp:validateConstraint
validator and selecting it added the validator to the properties with fields
for the error message and the regex expression

A picture named M5

The RegEx that I am using I got from
a great resource called the RegExLibrary, This resource has lots of great
RegEx validations that you can use for your applications. Phone
Numbers ( Used Above ), Email
addresses, US Zip
Codes and many many more, just
be aware that there are multiple versions of the different expressions
and some may or may not do exactly what you need so always make sure you
test them out.

Save your Xpage and test editing the
persons phone number. Try adding a letter into the phone number and when
you save the page you should see your server side validation kick in and
receive an error message back.

A picture named M6

Now that we know how to validate the
data being entered we do need to be able to save it. In the next part we’ll
create our save button and also hide it when the document is not in edit
mode.

Tagged with: , , , ,
Posted in None

Learning XPages Part 34 : Server Side Validation

Posted on March 5, 2009 by qtzar

In the last part we created some very simple
client side validation of the data for the Job Title field, In this part
I’ll switch it over to a server based validation to show you the difference
between the two.

When you first install your Domino 8.5
server, client side validation is set as the server wide default validation
method. You can if you want setup the server so the server default for
validation is server side by editing a file on the notesdirxspnfs folder
called xsp.properties and changing the xsp.client.validation line to false
but this will effect ALL Xpages applications on the server and if the application
has not been written with this in mind you may run into some issues so
my personal recommendation is to leave this at the default and enable server
side validation either at the application level or even at the XPage control
level.

To set up server side validation at
the application level you will need to open the ‘Application Properties’
in the main domino designer outline for your application and then switch
to the XPages tab and turn off the client side validation option :

A picture named M2

The last level at which you can turn
off the client side validation is at the edit controls level. Select the
JobTitle editbox we were working with in the last part and goto the ‘All
Properties’ section. Under ‘Data’ you’ll see the disableClientSideValidation
option that can be set to true or false ( or even computed ).

A picture named M3

When we had client side validation enabled
the error message was presented to us in a standard web browser dialog
box. With server side validation we need to create a place on the XPage
where the error will be displayed. if you look at the controls section
in the domino designer you’ll see two controls at the end of the ‘core
controls’ section for error display.

A picture named M4

‘Display Error’ will display a single
error message and is linked to a single editable control on your XPage
and ‘Display Errors’ will display all the errors on the XPage. To demonstrate
both types I have added a ‘Display Errors’ section above my tabbed panel
and a ‘Display Error’ control beside the JobTitle editbox.

A picture named M5

The properties for both controls are
very similar with the main difference being that the ‘Display Error’ control
must be associated with an edit control

A picture named M6

Now if we save and preview our XPage
the error messages that we created in the last section will appear where
and the document won’t be saved.

A picture named M7

A picture named M8

They look pretty plain right now. So
why not add a styleClass of ‘lotusMessage’. I’m going to add the single
‘Display Error’ to each of the fields that I want to validate and remove
the ‘Display Errors’ control from my final version of the application.

In the next part I’ll add some advanced
validation to show you how to use RegEx to make sure the phone number does
not contain invalid characters.

Tagged with: , , ,
Posted in None

Learning XPages Part 32 : Using Roles To Make Fields Editable

Posted on March 4, 2009 by qtzar

Now that we can switch our page into Edit
Mode you’ll see that all of the fields are editable. In most applications
you may not want this so we can disable the ability to edit certain fields.
Start by opening the content_Person custom control again.

Lets disable a couple of the fields
that we don’t want the end user changing. Select the ‘FirstName’ field
and look at the properties. In the ‘Edit Box’ properties you will see a
‘Read Only’ tickbox. Turning this on will make the field uneditable. Nice
and simple for this particular field.

A picture named M2

You may also notice that the ‘Read-Only’
tickbox has a diamond beside it. You can use this to create a computed
result to determine if the field should be read only or not.

Lets say that we don’t want the end
user editing their Job Title but we do want somebody with the ‘PhonebookEditor’
role in the ACL to be able to update peoples job titles. First of all click
on the ‘JobTitle’ field in the design and then in the properties click
the diamond for the ‘Read-Only’ flag and select compute value.  In
the script editor that appears we need to enter in the code to see if the
currently logged in person has the role or not.  Here’s the code I’m
using :



var
s1 = context.getUser().getRoles();

var
s2 = "{PhonebookEditor}";

if(@Contains(s1,
s2) == @True())

        return
false;

else

        return
true;



NOTE : Replace curly brackets with square
brackets in the above code.

This very simple code could be reduced
in size but I’ve left it expanded so you can see how it is working, I am
setting up two variables and then doing an @contains to see if the role
exists inside the current users .getRoles value. This would be very similar
to how you would do it on a form in traditional notes client development.

In the next part I’ll add some validation
to the fields that can be edited so make sure the person enters in valid
data.

Tagged with: , , ,
Posted in None
Archives