I have been asked by a couple of people
to create a table of contents to all the parts of the Learning XPages series
so here you go…
http://blog.dnaware.net/blogs/qtzar.nsf/htdocs/LearningXPages.htm
I will update the table of contents
at the end of each day depending on how many parts I manage to get written.
Now that we have a our OneUI styled Action
bar and a button/link on it we now need to give that button some purpose.
In this case we are going to put the document into Edit Mode so that our
end user can edit their own document or a person with the ‘PhonebookEditor’
role can edit the document.
Open your content_Person custom control
again and select the ‘Edit Document’ link that we created in the last part.
Change to the events tab for the link and in the onClick event we will
create a server side action using the ‘Simple Actions button. Set the action
category to ‘Document’ and set the action to ‘Change Document Mode’. We
need to tell the action what mode we want so we’ll select the ‘Edit Mode’
option.
OK the dialog box and then save the
custom control and switch to your XPage. If you have not logged in on the
XPage yet then make sure you do it now. Anonymous should only have reader
access to the application. Once you have logged in navigate to a person
details page and click the button, the page will refresh and all the fields
will become editable.
In the next part we will add some validation
to some of the fields and also disable the ability to edit certain fields.
If we are designing a read-only phonebook
application then we are effectively finished and all that remains is a
bit of tidyup and adjustments to the look and feel to make everything perfect
however I’m going to extend the functionality to allow people be able to
edit their own record in the phonebook or to allow somebody with a special
role edit any document in the phonebook. Over the next few parts we will
look at how to enabled editing of documents in XPages, designing a oneUI
based ‘action bar’ and how to check a persons rights and roles to display
and allow the actions.
To begin the process I have created
a new field in the application configuration form that can turn on or off
this feature. The reason for doing this is because the final version of
the application will be available on OpenNTF and not everybody who uses
it might want to grant their users this ability. By using a setting in
the configuration document you’ll be able to control the feature. I have
created a ‘radio button’ on the notes form with a value of Yes|1 and No|0
and I have defaulted the value to "0" so it is turned off by
default.
Lets start work on the action bar, We’ll
just create the action bar and the buttons and style them to the OneUI
look and feel for the moment. Start by opening your content_Person custom
control and drag a new panel into the design at the top of the page. Once
it’s dragged into place switch to the source view and make sure that it
is inside the ‘lotusContent’ DIV. We will give the panel a styleClass of
‘lotusActionBar’ and ‘lotusBtnContainer’. To give an item two styleclasses
just separate them with a space.
Once this is done let’s drag over a
‘Link’ control. You may be tempted to drag over a button control because
we are creating action buttons but with the OneUI CSS we are actually going
to style a link with the correct look and feel instead. With the link control
in place have a look at it’s All Properties and find the property for OuterStyleClass.
Fill it in with the following 3 classes seperated by spaces ‘lotusBtn lotusBtnAction
lotusLeft’. The OUTER style class creates a SPAN tag around the link with
the CSS class set to the values you specify.
When your finished your source should
look like this :
‘
If you now refresh and preview your
XPage you will see your new action button appear at the top of the person
details page, I’ve changed the label in mice to read ‘Edit Document’ :
In the next part we’ll add the actual
action to our new button.
Our application is really starting to come
together but there are a couple of areas I’d like to clean up to make the
application more usable by the end users. Currently when the list of names
or locations are rendered to the web browser there is no easy way for the
end user to know that they can click on a name to bring you to the person
details page. It just looks like a plain table.
The quick way to resolve this is to
add some CSS to our custom.css file that looks like this :
#phonebook tr:hover, .phonebook tr:hover
{
background-color:orange;
color:#FFFFFF;
cursor:pointer;
}
This CSS will turn the entire row to
an orange background color, change the text color to white and change the
mouse pointer into a hand, just as if you were pointing at a link. The
user now has a visual clue that they can click on a name in the table and
that something will happen.
If your users are using FireFox, or
Chrome, or Opera or even Internet Explorer 8 as their web browser then
this works perfectly and you can stop reading.
If your users are using Internet Explorer
6 or Internet Explorer 7 then it does not work as those browsers don’t
recognize the CSS Selector of :hover on anything but a link. There is,
however a way around it by using JavaScript and DoJo to replace the table
rows style class as you move the mouse in and out of the row.
Lets start by adding the CSS above to
our custom.css file but change the :hover to .over.
Open your content_location custom control
again and switch to the source view and find your table row that appears
inside the repeat control and click on it. We then need to switch to the
events tab in the section below and lets start with the onMouseOver event.
Make sure you switch to the ‘client’ tab and enter in the following code
:
Lets explain this code. The first part
of dojo.addClass is the dojo function that we are calling, it takes two
parameters, the node ID of the element it is going to change and the CSS
class name that it will add to the class= line for that node, in our case
we are adding the ‘over’ class name to the node as that is what we have
in our CSS.
the other part of the code is an XPages
feature and this is where the power really comes into play. anything wrapped
in the #{} is interperated by the XPages runtime before being sent to the
browser, even, as it is in this case, if it’s inside a bit of javascript
code. the id:trow is converted by XPages into the current element ID. In
this case ‘trow’ is the ID that we assigned to our table row so that we
could attach the onClick event ( and now this event ) to. but if you look
at the source of a rendered XPage you’ll see the name it is using is along
the lines of this :
We don’t know what all that extra prefixes
to the ID are set to until the page is rendered to the web browser but
the #{id:trow} will be replaced during runtime with the correct ID.
For the onMouseOut event we will remove
the ‘over’ class using this code :
Now save and preview your webpage and
as you pass your mouse up and down the table the row background color will
change and the mouse will turn into a pointer.
You can go ahead and apply the exact
same code to the homepage table if you want.
Dec's Dom Blog 
You must be logged in to post a comment.