GateIn Documentation

The convenient Toolbar helps users and administrators to manipulate all actions quickly.

You can change language, change skin and sign out from GateIn Portal.

It shows all different sites available in GateIn Portal allows users to directly edit the navigation tree.

Users can easily see and access pages in GateIn Portal.

You easily edit a page or add a new page

With the Edit Inline Composer popup that consists of two tabs: Applications and Containers, it is convenient for a user to select the component that he wants and to drag and drop it to the page.

You also quickly edit, delete portlets in a page, change portal's properties or switch the view mode.

It is so difficult to manage and set permissions for a great number of registered users in a system. To solve this problem, GateIn Portal helps Administrators manage users, groups and memberships easily as well as effectively.

Go to Administration / Community Management (or Organization/Management). The Organization form appears:

Select the User Management tab in the Organization form. By default, it will show all existing registered users. With User Management , you can see all existing registered users, and also search, edit, delete them. For each user, you can see his groups and his memberships (roles) in these groups. You can not add users to a group but you can remove them from the group.

The Administrator can search users by user name, first name, last name or email address.

1. Type the search term related to the user that you want to search. You do not need to enter an exact term.

2. Select the field in which you would like to search

3. Click the magnifying glass icon!images/SearchIcon.png! to perform searching. It will return a searching result in form.

1. Click the edit icon!images/EditIcon.png! corresponding to the user that you want to edit.

2. Select the Account Info tab to view and change the essential user information .

3. Select the User Profile tab to view and change profile information. The Language field is used to set the display language of that user.

4. Select the User Membership tab to see user's information in groups.

5. Click the Save button to accept changes.

1. In the User Management form: Click the trash can icon !images/DeleteIcon.png! corresponding to the user that you want to delete.

2. Click the OK button in the confirmation message to confirm or the Cancel button to quit without deleting anything.

Select the Group Management tab in the Organization form.

By default, all existing groups will be displayed on the left pane. This tab is used to add new, edit or delete a group. The right pane shows information about the selected group including information about the members in the specific group and a small form to add a new user to a group.

1. Choose the path to create a new group by selecting the groups from list on the left pane or clicking the arrow icon !images/ArrowIcon.png! if you want to create a group in a higher level. The selected path is displayed in the path bar.

2. Click the Add New Group icon. The Add New Group form will be displayed on the right pane:

3. Fill in the required fields. Only alpha, digit and underscore characters are allowed for the Group Name field and it must be unique.

4. Click the Save button to accept entered values or the Cancel button to quit.

1. Select the path to the group you want to edit by selecting the groups from list on the left pane.

2. Click the edit icon!images/EditIcon1.png! to show the Edit Group form of the selected group. This form is identical with the New Group form.

3. You can not change the Group Name. Make changes for a Label or a Description field and then click the Save button to accept changes or the Cancel button to cancel changes and return to the Group Info form.

1. Select the path to the group you want to edit by selecting the groups from the list on the left pane. The Group's information is displayed including the user list and a form which allows to add a new user.

2. Enter the exact user name of the user that you want to add to the selected group or you can enter some characters if you are not sure about the exact spelling.

3. Select the membership for the user in a group from memberships list. The refresh icon!images/RefreshIcon.png! can be used to update the memberships list in case there are any changes.

4. Click the Save button to accept adding the selected user to a specific group with the selected membership type.

1. Click the edit icon!images/EditIcon.png! corresponding to a specific user with a membership in the Group Info table to open the Edit Membership form :

2. Change the membership of the selected user by selecting another value in the Membership field.

3. Complete editing the selected user by clicking the Save button.

1. Select the path to the group you want to delete by selecting the groups from list on the left pane.

2.Click the trash can !images/DeleteIcon.png! icon in order to delete.

3.Click the OK button on the confirmation message to accept or the Cancel button to quit without deleting.

The roles of an user in the specific group are managed in Membership Management form. Currently there are three membership types: Manager, Member and Validator. By default, Manager has the highest rights in a group. You can add new, edit or delete a membership type. Select the Membership Management tab in the Organization portlet. There will be a membership type list and a form to add new/edit:

1. In the Add/Edit Membership form at the bottom, the input value for the membership name field (required) and the description field (optional). Only letters, digits, dots, dashes and underscores are allowed for the membership name.

2.Click the Save button to accept adding the new membership or click Reset button to clear the entered values.

1. Click the edit icon!images/EditIcon.png! in the row of the membership type you want to edit. The selected Membership type information is displayed in the Add/Edit Membership form.

2. Make changes in this form.

3. Click Save to accept changes.

1. Click the trash can icon in the row of the membership type that you want to delete.

2. Click the OK button in the confirmation message to accept the deletion.

Permissions play an important part in accessing and performing actions in the Portal. Depending on permissions assigned by an administrator, users can either access or edit portals, pages and portlets. GateIn Portal have applied several permission levels:

The three above permission levels helps users assign access and edit permissions clearly and flexibly.

GateIn Portal skins are graphic styles that help users display an attractive user interface. Each skin has its own characteristics with different backgrounds, icons, etc. In order to be user-friendly and flexible in use, users are allowed to change their skins without having edit rights on the portal.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Current portal

2. Click the edit icon!images/EditIcon.png! to edit portal properties.

3. In the Portal Setting tab: select one skin type in the Skin list field to change and display a skin.

4. Click Save and Finish icon !images/Finish1.png! so that the modification can take effect.

1. Click Edit Inline on the Toolbar. The Edit Inline Composer will appear.

2. Click Portal Properties to edit portal's properties.

3. In the Portal Setting tab: select one skin type in the Skin list field to change and display a skin.

4. Click Save and the !images/DiskIcon.png! icon so that the modification can take effect.

1. Go to GateIn Start -> Administration -> Skin Settings.

1. Go to GateIn on the Toolbar --> click Change Skin.

The Skin Setting form is displayed with a list of all supported skins. The left pane contains the skin list and the right pane is used to display the template of the selected skin.

2. Select one by clicking on the skin's name.

3. Click the Apply button and wait for few seconds to take effect.

In order to understand clearly about what the navigation is and navigation types that GateIn Portal supports, please refer the Navigation concept page.

The page navigation of a portal is created automatically when a portal is created.

Only users who have the edit right on a portal can perform this action.

Follows these below guides to edit a portal 's navigation:

1. Go to GateIn Start-> Administration -> Advanced--> Edit Page and Navigation.

2. Select Portal navigation in list on the left pane (eg: portal: classic's Nav).

3. Right click the blank space on the left pane and select Edit Navigation in the menu:

The form for editing the portal navigation will be opened:

Notice: The number that users select in the Priority field is the priority of a page navigation on the Navigation bar.

4. Make changes to fields in this form: Description, Priority.

5. Click the Save button to accept changes.

6. Click the!images/OKIcon.png! to take effect of new changes.

Or click the Cancel button to quit without saving any change.

No one can create the portal's page navigation so no one can delete it. A navigation is deleted automatically after you delete its portal.

Each group has only one page navigation. Only users of that group have the "manager" membership can create/edit/delete navigation for that group

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation.

2. Select a Group navigation in the list on the left pane (eg: group:platform/administrator's Nav). All pages of this group will be listed underneath.

3. Right click the blank space on the left pane and select Edit Navigation in the context menu:

The form for editing the group navigation will be opened:

4. Make changes for two fields: Description and Priority.

Notice: The number that users select in the Priority field is the priority of a page navigation on the Navigation bar.

5. Click the Save button to accept any changes.

6. Click the!images/OKIcon.png! to take effect new changes on the Navigation bar.

Or click the Cancel button to quit without saving any change.

The page navigation of a user is created automatically when a user is created (registered). So an administrator don't have to create it.

Only the user who is the owner of the user page navigation can edit it.

No one can create user's page navigation so that no one can delete it. A user's navigation is deleted automatically when its user is deleted.

If you are allowed to access GateIn Start in the User Workspace, you can take all actions related to a node such as : add a new node, edit, copy, cut, delete and clone node.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Select a node from list (to create a new node like sub-node of the selected node) or click the icon!images/UpIcon.png! to create a new node on root

4. Right-click on the selected navigation or node and select Add new Node option. Add new node form appears:

The Page Node Setting tab includes:

In the Page Selector tab, you can select a page or not for this node.

You do not have to input values in these fields. It is automatically displayed after selecting an existing page by clicking the Search and Select Page button. The Select a page form appears like:

After configuring the page node settings, the page selector and the node's icon, click the Save button to accept or the Cancel button to quit without creating a new node.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Right-click on the selected node and select Edit this Node option.

It will displays a form to edit this node:

In the Page Node Setting tab: you can change the value of these fields: Label, Visible and Publication Date & time. After finish changing, click the Save button to accept changing or Cancel button to refuse it.

In the Page Selector tab : you also search and select another page for this node by clicking the Search and Select Page button. You can see more details on how to select a page for a node on the above Add a new node section. After finish changing another page for this node, click the Save button to accept changing or Cancel button to leave without saving any changes.

You also easily copy a node by following these steps:

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Right-click on the selected node and select Copy node option.

4. Select the position that you want to paste this node and select Paste Node option. Click the!images/MarkIcon.png! icon to Save.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Right-click on selected node and select Clone node option.

4. Select the position that you want to paste this node and select Paste Node option. Click the!images/MarkIcon.png! icon to Save.

In Manage Pages you will see:

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Right-click on the selected node and select Cut node option.

4. Select the position that you want to paste this node and select Paste Node option. Click the!images/MarkIcon.png! icon to Save.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation

2. Select a navigation from the navigation list.

3. Right-click on the selected node and select Delete node option.

It will display an alert message, click the OK button to accept deleting or Cancel button to quit without deleting a node.

You can easily change the position of node on the navigation bar on their own convenient order by following these steps:

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation.

2. Select a navigation from the navigation list.

3. Select the node that you want to move. Right click on the selected node and then click on Move up or Move down

The selected node will be moved up/down.

Only by using one page list can users add, edit, delete and view quickly and easily which pages you like to. Following these guides to manage pages:

You easily add a new page by following these simple steps:

1. Go to GateIn ->Administration -> Advanced --> Manage Pages

1. Go to Administrator on the Toolbar --> Manage Pages

Details

2. Click the Add New Page button.

3. Enter values for fields in the Page Setting tab

If the Owner type is "portal" or "group":

4. Click the Save button to accept creating a new page or the Cancel button to quit the form.

1. Go to GateIn Start -> Administration -> Advanced --> Manage Pages

2. In the existing pages list: click the edit icon on the row of page you want to edit.

In the Page Setting tab:

Click !images/ShowContainer.png! icon to show current container layout of selected page on your right and all the container layouts list on the left pane.

If you want to change current layout, select a layout type from the list on the left pane, then left click on the template you want and drag and drop it into the right pane. New container will be displayed on the right pane. You can change position of current container by left click and drag and drop it to another place on the right pane or remove current container by clicking delete icon on the right corner.

Click !images/ShowPortlet.png! icon to show current portlet layout of page.

If you want to change current layout, select layout type from the list on the left pane, then left click on the template you want and drag and drop it into the right pane. New portlet will be added and displayed in the right pane. You can change position of current portlet by left click and drag and drop it to the place you want on the right pane or remove current portlet by clicking delete icon.

You easily view a page by clicking on the!images/View.png! icon on the row of the page you want to view in the existing pages list.

1. Go to GateIn Admin -> Administration -> Advanced --> Manage Pages

2. There is a list of all existing pages, click the trash can icon !images/DeleteIcon.png! on row of the page you want to delete. It will display the confirmation message.

3. Click the OK button to accept deleting or Cancel button to quit without deleting this page.

Only by following there simple steps can you create a page quickly by using a wizard and publish this page on the Navigation bar:

1. Go to GateIn Start ->Administration -> Basic --> Create page wizard. Welcome to Page Creation Wizard appears:

1. Go to Editor --> Add New Page on the Toolbar. Create page wizard: Welcome to Page Creation Wizard appears:

2. Click the Next button or number '1' of the wizard steps in order to go to step 1. This step allows users to set up page setting such as :the navigation path, the node name, the display name, etc.

There are two parts: the left pane is used to show a small description that will guide you what to do in this step. And the main wizard includes two parts: the left pane contains a list of navigations and shows the page list of each selected navigation, the right pane displays main information of a page.

3. On the left of wizard: Click the combo box icon !images/ComboBox.png! to see the navigations list. Select a navigation from the list that you want to create page. The pages list of selected navigation are displayed.

4. Select a page from the above list or click on arrow up icon !images/ArrowIcon.png! to add a page at root.

+Note:+You can set date and time by clicking the Start Publication Date field and End Publication Date field and select a date in the calendar pop up

5. Click Next or number '2' of the wizard steps to go to step 2.

6. Select Empty Layout or click the icon to see more templates to select.

7. Click the Next button or number '3' of the wizard step to go to step 3. You can drag portlets on the left pane and drop it on the right pane to constitute the content of this page.

8. Click the Show Container icon !images/ShowContainer.png! if you want to see the existing containers and re-select the layout of the page. There will be a category list which contains specific containers when clicking the icon.

The step 2 of creating a page by wizard is the same as the above

In the step 3, you can drag portlets from the Edit Inline Composer popup and drag it to the constitute the content of this page

You can click on!images/Switch.png! to view the content of this page.

Click Save to accept creating a new page, the Back button to return the previous step or the Abort button to quit without creating a new page.

You can easily drag and drop page body to the specific place where you want to in the page by following guides:

1. Go to GateIn Start -> Administration -> Advanced --> Edit Current portal. It will display :

2. Click on the Portal Page, drag and drop to another reasonable places which you want to in this page.

Creating a new portal requires you to have a special permission that only an administrator can give you. You need follow these guides to create a new portal.

You also can edit or delete a portal, see more details on Manage Portals

You can easily manage a portal by editing or deleting it.

You can change information of the current using portal such as properties or layout. However, you must have the edit right given by an Admininstrator. When you have edit right, follow these steps to edit the current portal:

1. Go to GateIn Start -> Administration -> Advanced --> Edit Current Portal. A form to edit the current portal will appear:

2. Click!images/EditPage.png! icon to edit portal properties.

3. Click!images/ShowContainer.png! icon to edit portal container layout.

4. Click!images/ShowPortlet.png! icon to edit portal portlet layout.

5. Click!images/Savepage.png! icon to save changes.

You must have the edit right to change information of the current using portal:

1. Go to Editor on the Toolbar ->click Edit Site Layout.

2. Click the!images/PortalProperties.png! button in the Edit Inline Composer. The edit Form of the portal will be shown:

3. Change the properties of the current portal.

4. Click the Propertites tab. Select an option for Keep session alive that means keeping the working session for a long time to avoid the working time out. There are 3 options:

5. Set permissions for a portal:

To change any permission, click the Select Permission button and then select a group with the Membership type you want. Only one group can have the Edit Permission of the portal.

You can set the Edit Permission for the portal when you create or edit it.

6. Click the Save button to accept changes or the Cancel button to quit.

You can easily delete a portal by following these guides:

1. Go to GateIn Start -> Administration -> Advanced --> Manage Portals

+The 1^st^ way+:

1. Go to Administrator on the Toolbar --> Manage Portals. List of all portals will be shown.

2. Click the trash can !images/deleteIcon.png! icon in the row of the portal you want to delete in the portal list.

3. Click the OK button in the confirmation message to delete.

+The 2^nd^ way+:

1. Click on Site in the Toolbar --> click on!images/DeletePortal2.6.png! .The confirmation message will appear:

2. Click OK to accept deleting a portal or Cancel to quit without deleting it.

GateIn Portal allows users to switch between Portals simply and easily. You can use another portals such as gateway, starting site if you are given the appropriate permissions by the administrators.

Go to Site on the Toolbarm it will list all portals in which you have at least the access right

You easily switch between Portals by simply clicking on the portal that you want to choose and wait for few seconds to take effect.

GateIn Portal provides users with the most familiar interface language to work with and perform all actions efficiently. The priority of the interface language is 1. User's language 2. Browser's language 3. Portal 's language. Thus to display your prefer language, you should pay attention to this order to change the language type appropriately.

You can change the interface language permanently by three ways :

This way supports you to change the interface language of the current Portal.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Current portal.

2. Click !images/EditIcon.png! icon to edit portal's properties.

3. In the Portal Setting tab: You can change display language of Portal by selecting another language in the Locale field.

4. Click Save and Finish!images/FinishIcon.png! icon to take affect.

You easily change the interface language of the current Portal by following guides:

1. Go to Editor on the Toolbar --> click Edit Page. The Edit Inline Composer popup will appear:

2. Click on Portal Properties to edit portal's properties.

3. In the Portal Setting tab: You can change display language of Portal by selecting another language in the Locale field.

4. Click Save and Finish!images/DiskIcon.png! icon to take affect.

If you can access GateIn Start, you can do this way to set interface language for yourself, not for interface language of Portal by these following steps:

1. Go to GateIn Start -> Administration -> Language Settings

The Interface Language Setting form is displayed with a list of all supported languages. The current using language is marked by!images/MarkedIcon.png! icon.

2. Select another one by clicking on the name of language.

3. Click the Apply button and wait for few seconds to take affect.

You can set the interface language for yourself by following guides:

1. Go to GateIn on the Toolbar --> click Change Language

The Interface Language Setting form is displayed with a list of all supported languages. The current using language is marked by!images/MarkedIcon.png! icon.

2. Select another one by clicking on the name of language.

3. Click the Apply button and wait for few seconds to take affect.

You also set interface language for yourself, not for interface language of the Portal by this way.

1. Click Change Language on the right corner to show the Interface Language Setting form:

The Interface Language Setting form will appear:

2. Select another language in list. The selected language will be marked by !images/MarkedIcon.png! icon.

3. Click the Apply button to change the interface language and wait for few seconds to take affect or click the Cancel button to quit without changes.

There are two modes to set displaying language for a user.

GateIn Portal supports RTL (Right to Left) to meet the demand of Arabian customers who want to use the Portal by their own language for more convenient and easy to use. When you change from other languages to Arabic or set the displaying language as Arabic, the displaying on Portal will be changed to Right to Left (RTL) direction because Arabian usually read from Right to Left.

Some screen shots of Portal with RTL:

Exo Portal supports a multi-language environment for your portal. You can internationalize any menu entry on the navigation. As the navigation bar is composed by nodes so you have to modify the display names of the nodes. Instead of entering the display name in English you have to use a so called resource key. This resource key is used to define the label that is shown on the navigation bar, the menu, and the breadcrumb.

The resource key format is: #{key}

The resource key is the can contain any text that you consider to be fine. It should be human-readable and must not contain spaces.

There are three ways to create a key for a node: using the Create Page Wizard or using the Edit Page Wizard or the Edit Page and Navigation dialog.

You can follow these steps:

1. Go to GateIn Start -> Administration -> Basic --> Create Page Wizard

2. Click Next to move to step 1

3. At step 1, continue as usual, but enter a resource key in the Display Name field.

4. Click on the Next button and continue and click on the Save button. For example, create a key named "AAA".

1. Go to GateIn Start -> Administration -> Basic --> Edit Page Wizard

2. Click on the Next button to move to step 1

3. At step 1, continue as usual, but enter a resource key in the Display Name field.

1. Go to GateIn Start -> Administration -> Advanced --> Edit Page and Navigation.

2. There are two alternatives:

3. A Create/Edit node dialog appears, enter a resource key in the Label field

+Note:+ You can reuse the same resource key in several nodes.

Exo Portal organizes resource keys in resource files. Each file contains a list of keys and their meanings (translations) in one specific language. Normally one resource file has one language supported by Portal. This helps to structure the resource keys. Each resource file has a name and a language attribute. One resource file only can contain translations for one single language.

Do as follows: 1. Go to GateIn Start -> Page Navigation -> Administration --> Internationalization

2. Select a data resource that you want to internationalize. You also may search the desired resource name with a specific language:

+Example:+ if you want to define a key of a node of portal "classic" in language French, search resource: locale.navigation.portal.classic with value in the Language field is "fr"

+Example:+ if you want to define a key for a node on navigation of "administrators" group that is the sub one of the "platform" group in language French, search resource: locale.navigation.group.platform.administrators with the value in the Language field is "fr"

3. Click the magnifying glass!images/MagnifyIcon.png! icon corresponding to a data resource to see details of the resource file. Click the Edit button in order to modify the content.

4. Enter the resource key with the string that will be displayed as node name on the navigation bar .

5. Click on the Save button.

This portlet is used to define a word or a phrase of the current language to an expected language. The form of this portlet is like:

Each resource supports a language. So, you can define a word or a phrase according to the supported language.

1. Select the New Resource button in the Internationalization Portlet form. The Resource Data form will appear:

2. Enter values into required fields.

3. Click the Save button to accept adding a new resource or the Cancel button to quit.

Click the magnifying icon !images/GlassIcon.png! corresponding to resource which you want to view. On the view form, you also can edit information again by clicking the Edit button. You only can change Resource field, then click the Save button to accept changes or click the Cancel button to quit without saving any changes.

Click the trash can icon!images/DeleIcon.png! corresponding to the resource which you want to delete. There 'll be a confirmation message, click the OK button to confirm deleting and the Cancel button to quit.

The Search Resource form displays directly on the portlet:

Enter the name of the resource which you want to search and select the supported language. Click the Search button to perform searching and displaying a list of the expected Resource.

To add a gadget, you can follow these steps:

1. Open the User Workspace on your left pane.

2. Click the tool!images/Tool.png! icon to add a new category

The Gadget Containers Management dialog appears:

Click the add icon !images/AddIcon.png! to show the Gadget Container Form .

Enter values for fields in the Gadget Container Form .

Click on the Save button to accept adding a new category or click Cancel to quit. After you added the new category you will see it in the dialog :

Edit the information of an existing category by selecting it from the left pane, the selected category is marked by a symbol. Then click the edit icon to show the edit form. Change the current category information and click on the button to accept changes.

Delete an existing category by selecting it from the left pane. In the message box Click on the OK button to confirm the deletion or click the Cancel button.

3. Click on the Save button in the Gadget Containers Management dialog to accept or on the Cancel button to quit. Added categories will be displayed in list in the User Workspace.

4. Click the list icon!images/ListIcon.png! to see category list and select one in list.

5. Click the add icon!images/AddIcon1.png! at the bottom of the User Workspace to open the Add Application dialog:

6. Select a gadget by clicking the add icon !images/PlusIcon.png! that is located next to the the gadget. The selected gadget is displayed immediately in the user workspace. Normally, you can see only two gadgets in the User Workspace. When there are more gadgets, some gadgets are not visible.

7. Click the scroll down icon !images/DownIcon.png!images/ or the scroll up icon!images/ UpIcon.png! at the bottom of the User Workspace to see the other gadgets. If there are no more gadgets to scroll to, the color of the scroll down and scroll up icon switches to gray color.

To edit a gadget, click !images/EditIcon.png! icon.

Remove a gadget from the User Workspace by using the functional bar!images/FunctionBar.png! at the upper right corner of that gadget.

Click the remove icon !images/RemoveIcon.png! . When the confirmation message appears, click the OK button to accept or the Cancel to quit.

This convenient feature that helps you import default portlets/gadgets automatically in different categories and these portlets/gadgets will be listed on the left pane.

1. Go to Administration-> Application Registry page-> Organize item on the navigation bar. A form for organizing portlets/gadgets will be displayed:

2. Click the Auto Import button!images/Auto1.png! at upper right corner on the action bar. A pop up will be shown:

2. Click the OK button to accept importing gadgets automatically. All portlets/gadgets categories will be imported and listed on the left pane.

You easily add a new category by following these guides:

Go to Administration -> Application Registry page -> Organize item.

1. Open a form to add a new category on the right pane by clicking the Add Category button on the action bar:

The Category Setting tab: includes common information about a category.

The Permission Setting tab: used to set the access permission for a category.

Figure 7.1. {info} This access permission enters the game whenever a user creates or modifies a page. In that moment the user only can see and use portlets in those categories on which he or she has access permission (defined by groups and memberships). {info}

7.3.5. Add Portlets/Gadgets to the specific Category

You can follow these steps to add a portlet/gadget to your prefered category :

1. Click the "add" icon!images/AddIcon.png! on the title bar of a category to which you want to add portlets. An interface will appear in the right pane as you can see below:

Name	Description
Display name	The display name of a portlet/gadget that you want to add to a category.
Application Type	the type of selected object.

2. Enter the display name and select a type for the selected portlet/gadget.

3. Select a portlet/gadget by checking the radio button.

4. Click the Save button to accept adding a portlet/gadget to a category.

7.3.6. Set Access Permission on Portlets

You easily set an access permission on a portlet by following these guides:

1. Go to GateIn Start -> Page Navigations -> select Administration --> Application Registry

2. Select a category on the left pane that includes the portlet you want to set right. Then all portlets of the selected category are listed immediately and detail information of each portlet is displayed on the right pane.

3. To set permission for a portlet:

• Click the Add Permission button to add access permissions to more groups.
• Or check the Make it public check box to allow everyone to access.

Whenever the user creates or modifies a page he or she can only see and use portlets that fulfill two conditions: the portlet is in a category on which the user has access permission (see category section above) and the user has access permission on the portlet

7.3.7. View detail information of the specific Portlets

You easily view detail information of all specific portlets by following these guides:

1. On the navigation bar, go to the Administration-> Application Registry page-> Portlet item . A form to view all portlets will appear:

Name	Description
Left pane	lists all portlets in two parts: Local and Remote
Right pane	shows detail information about a portlet: Name, Display name, Description and Portlet preferences.

2. Select one portlet in the list on the left pane. The detail information of that portlet appears on the right pane.

7.3.8. Add a Gadget

You can follow these steps to add a gadget to the gadget list :

1. Go to the Administration --> Application Registry and click on Gadget :

There are two ways to add gadgets:

7.3.9. Add a remote Gadget

1. Open the form to add a remote gadget by clicking Add a remote gadget :

2. Enter a link to an .xml file in the URL field.

3. Click on the Add button to accept the entered URL or on the Cancel button to quit. The added gadget will be added into gadget list on left pane of the Dashboard portlet.

7.3.10. Create a new Gadget

1. Show the form to add a new gadget by clicking Create a new gadget :

Source: The source code to create a new gadget. This source will be a .xml file.

2. Enter a value for the Source field in this form.

3. Click the Save button to create a new gadget. The created gadget will be added to the gadget list on the left pane of the Dashboard Portlet.

You also edit, refresh and delete a local gadget as well as a remote gadget:

7.3.11. Add a new Gadget to the Dashboard Portlet

You can add a new gadget to the gadget list in the Dashboard portlet :

1. Go to the Dashboard on the navigation bar. Click on the Add Gadgets link :

1. dialog to add a new gadget will appear :

2. Enter a link (a .xml file or RSS) in the text box on the left pane.

3. Click on the icon!images/PlusIcon.png! to add a new gadget to the gadget list beneath.

7.3.12. Manage Gadgets

7.3.12.1. Edit a Gadget

1. Click the edit icon!images/EditGadget.png! . It will display a dialog:

2. After editing , click the Save button to accept changing or Cancel button to quit.

7.3.12.2. Refresh a Gadget

• Local gadget: After editing information about the gadget that you want to, click the icon!images/Refresh.png! to refresh all information of that gadget.
• Remote gadget: When information of a remote gadget has been changed by another server, click the icon!images/Refresh.png! means it will update information of a remote gadget from that server.

7.3.12.3. Delete a Gadget

1. Click the trash can icon!images/DeleteGadget.png! on the row of the gadget that you want to delete. It will display an alert message :

2. Click the OK button to accept deleting or Cancel button to quit without deleting.

Configuration file path : "portal/WEB-INF/conf/portal/portal-configuration.xml"

  <component>
    <key>org.exoplatform.portal.config.UserPortalConfigService</key>
    <type>org.exoplatform.portal.config.UserPortalConfigService</type>
    <component-plugins>           
	    <component-plugin>
	      <name>new.portal.config.user.listener</name>
	      <set-method>initListener</set-method>
	      <type>org.exoplatform.portal.config.NewPortalConfigListener</type>
	      <description>this listener init the portal configuration</description>
	      <init-params>
	        <value-param>
	          <name>default.portal</name>
	          <description>The default portal for checking db is empty or not</description>
	          <value>classic</value>
	        </value-param> 
	        ..........
	      </init-params>
	    </component-plugin>
    </component-plugins> 
  </component>

You can see in the configuration above, we defined the classic as a default portal. Notes that the definition should be as a initial parameter of the NewPortalConfigListener component-plugin

When a user logs in he sees three types of navigation tree:

they all are configured thanks to the usual XML configuration syntax in a file: "portal/WEB-INF/conf/portal/portal-configuration.xml"

  <component>
    <key>org.exoplatform.portal.config.UserPortalConfigService</key>
    <type>org.exoplatform.portal.config.UserPortalConfigService</type>
    <component-plugins>           
	    <component-plugin>
	      <name>new.portal.config.user.listener</name>
	      <set-method>initListener</set-method>
	      <type>org.exoplatform.portal.config.NewPortalConfigListener</type>
	      <description>this listener init the portal configuration</description>
	      <init-params>
	        <value-param>
	          <name>default.portal</name>
	          <description>The default portal for checking db is empty or not</description>
	          <value>classic</value>
	        </value-param> 
	        <object-param>
	          <name>portal.configuration</name>
	          <description>description</description>
	          <object type="org.exoplatform.portal.config.NewPortalConfig">
	            <field  name="predefinedOwner">
	              <collection type="java.util.HashSet">                
	                <value><string>classic</string></value>
	                <value><string>webos</string></value>
	              </collection>
	            </field>
	            <field  name="ownerType"><string>portal</string></field>
	            <field  name="templateLocation"><string>war:/conf/portal</string></field> 
	          </object>
	        </object-param> 
	        <object-param>
	          <name>group.configuration</name>
	          <description>description</description>
	          <object type="org.exoplatform.portal.config.NewPortalConfig">
	            <field  name="predefinedOwner">
	              <collection type="java.util.HashSet">            
	              	<value><string>platform/administrators</string></value>    
	              	<value><string>platform/users</string></value>
	              	<value><string>platform/guests</string></value>
	              	<value><string>organization/management/executive-board</string></value>	              
	              </collection>
	            </field>
	            <field  name="ownerType"><string>group</string></field>
	            <field  name="templateLocation"><string>war:/conf/portal</string></field> 
	          </object>
	        </object-param>       
	        <object-param>
	          <name>user.configuration</name>
	          <description>description</description>
	          <object type="org.exoplatform.portal.config.NewPortalConfig">
	            <field  name="predefinedOwner">
	              <collection type="java.util.HashSet">                
	                <value><string>root</string></value>
	                <value><string>john</string></value>
	                <value><string>marry</string></value>
	                <value><string>demo</string></value>
	              </collection>
	            </field>
	            <field  name="ownerType"><string>user</string></field>
	            <field  name="templateLocation"><string>war:/conf/portal</string></field> 
	          </object>
	        </object-param>
	      </init-params>
	    </component-plugin>
  </component-plugins>  

In the previous XML file we define, for the 3 navigation types, some sets of predefined portal, groups or users that will have some XML files inside the war. Those files will be used to create an initial navigation the first time the portal is launched. That information will then be stored in the JCR and hence only modifiable from the portal UI.

The portal navigation incorporates the pages that can be accessed even when the user is not logged in (if the permission allow a public access). Several portal navigations are used for example when a company has several trademarks and each trade would have its own website.

The configuration of a portal called "classic" is made by providing 4 XML files under the directory portal/WEBINF/conf/portal/portal/classic:

That file describes the layout and portlets that will be shown for all pages. Usually the layout contains the banner, footer, menu, breadcrumbs portlets. Indeed, in GateIn, every area is a portlet even the banner and footer which makes the platform extremely configurable.

<?xml version="1.0" encoding="ISO-8859-1"?>
<portal-config>
  <portal-name>classic</portal-name>
  <locale>en</locale>
  <factory-id>office</factory-id>
  <access-permissions>Everyone</access-permissions>
  <edit-permission>*:/platform/administrators</edit-permission>
  <creator>root</creator>    
    
 	<portal-layout> 		
		<application>
	    <instance-id>portal#classic:/web/BannerPortlet/banner</instance-id>
	    <show-info-bar>false</show-info-bar>
	  </application>
	  <application>
	  	<instance-id>portal#classic:/web/NavigationPortlet/toolbar</instance-id>
	    <show-info-bar>false</show-info-bar>
	  </application>
		
	  <application>
	    <instance-id>portal#classic:/web/BreadcumbsPortlet/breadcumbs</instance-id>
	    <show-info-bar>false</show-info-bar>
	  </application>
	  
	
	  <page-body> </page-body>
	  
	  <application>
	    <instance-id>portal#classic:/web/FooterPortlet/footer</instance-id>
	    <show-info-bar>false</show-info-bar>
	  </application>
  </portal-layout>
  
</portal-config>

Even if not shown in the previous XML file, it is also possible to apply a nested container that can also contain portlets. Containers are then responsible of the layout of their children (row, column or tabs containers exist).

Each application references a portlet using the id portal#{portalName}:/{portletWarName}/{portletName}/{uniqueId}

In order to define at which location GateIn Portal shall render the current page use the page-body tag.

The defined classic portal is accessible to "Everyone" (that means it can be accessed through the URL /portal/public/classic) but only members of the group /platform/administrators can edit it.

This file defines all the navigation nodes the portal will have. The syntax is simple as we get nested node tags. Each node references a page that is defined in the next XML file.

If the label #{} is used then it means the i18n mechanism is activated and that the real label to render is taken from an associated properties file for the current locale.

<?xml version="1.0" encoding="UTF-8"?>
<node-navigation>
  <owner-type>portal</owner-type>
  <owner-id>classic</owner-id>
  <priority>1</priority>
  <page-nodes>
	  <node>
	    <uri>home</uri>
	    <name>home</name>
	    <label>#{portal.classic.home}</label>
	    <page-reference>portal::classic::homepage</page-reference>	    
	  </node>    
	  <node>
	    <uri>webexplorer</uri>
	    <name>webexplorer</name>
	    <label>#{portal.classic.webexplorer}</label>
	    <page-reference>portal::classic::webexplorer</page-reference>	    
	  </node>
  </page-nodes>
</node-navigation>

This navigation tree can have multiple views inside portlets such as the breadcrumbs that render the current view node, the site map or the menu portlets.

+Warning+: For top nodes, the uri and the name of your navigation nodes must have the same value. For the other nodes the uri is composed like <uri>contentmanagement/fileexplorer</uri> where 'contentmanagement' is the name of the parent node and 'fileexplorer' the name of the node (<name>fileexplorer</name>).

This XML file structure is very similar to portal.xml and it can also contain container tags. Each application can decide if it wishes to render the portlet border, the window state icons or the mode.

<?xml version="1.0" encoding="ISO-8859-1"?>
<page-set>  
  <page>
    <page-id>portal::classic::homepage</page-id>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <name>homepage</name>
    <title>Home Page</title>
    <access-permissions>Everyone</access-permissions>
    <edit-permission>*:/platform/administrators</edit-permission>
    <application>
      <instance-id>portal#classic:/web/HomePagePortlet/homepageportlet</instance-id>
      <title>Home Page portlet</title>
      <show-info-bar>false</show-info-bar>
      <show-application-state>false</show-application-state>
      <show-application-mode>false</show-application-mode>
    </application>
  </page>    
    
  <page>
    <page-id>portal::classic::webexplorer</page-id>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <name>webexplorer</name>
    <title>Web Explorer</title>
    <access-permissions>*:/platform/users</access-permissions>
    <edit-permission>*:/platform/administrators</edit-permission>    
    <application>
      <instance-id>group#platform/users:/web/BrowserPortlet/WebExplorer</instance-id>
      <title>Web Explorer</title>
      <show-info-bar>false</show-info-bar>
    </application>  
  </page>  
</page-set>

Porlet instances can be associated with portlet-preferences that override the one defined in the usual portlet.xml file of the portlet application WAR.

<?xml version="1.0" encoding="ISO-8859-1"?>
<portlet-preferences-set>
  <portlet-preferences>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <window-id>portal#classic:/web/BannerPortlet/banner</window-id>
    <preference>
      <name>template</name>
      <value>par:/groovy/groovy/webui/component/UIBannerPortlet.gtmpl</value>
      <read-only>false</read-only>
    </preference>
  </portlet-preferences>
  <portlet-preferences>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <window-id>portal#classic:/web/NavigationPortlet/toolbar</window-id>
    <preference>
      <name>useAJAX</name>
      <value>true</value>
      <read-only>false</read-only>
    </preference>
  </portlet-preferences>
  <portlet-preferences>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <window-id>portal#classic:/web/FooterPortlet/footer</window-id>
    <preference>
      <name>template</name>
      <value>par:/groovy/groovy/webui/component/UIFooterPortlet.gtmpl</value>
      <read-only>false</read-only>
    </preference>
  </portlet-preferences>
  
  
  <portlet-preferences>
    <owner-type>portal</owner-type>
    <owner-id>classic</owner-id>
    <window-id>portal#classic:/web/GroovyPortlet/groovyportlet</window-id>
    <preference>
      <name>template</name>
      <value>par:/groovy/groovy/webui/component/UIGroovyPortlet.gtmpl</value>
      <read-only>false</read-only>
    </preference>
  </portlet-preferences>
</portlet-preferences-set>

Group navigations are dynamically added (mounted) to the user navigation when he logs in. This means that a user sees in his menu also all the pages that are assigned to the groups to which he belongs to.

Here only 3 XML files are necessary: navigation.xml, pages.xml and portlet-preferences.xml. The syntax is the same as for portal navigations.

The 3 files are located in the directory: "portal/WEB-INF/conf/portal/group/group-name-path/" like for example "portal/WEB-INF/conf/portal/group/platform/administrators/"

The user navigation is the set of nodes and pages that is owned by a user. You can see that part as the user dashboard. The files needed are navigation.xml, pages.xml, portlet-preferences.xml. You will also find gadgets.xml (formerly called widgets.xml) which defines the gadgets (widgets) that will be located in the user workspace. The user workspace is located at the left hand side, the access is restricted to some privileged users, see Portal:Predefined User Configuration.

Those files are located in the directory "portal/WEB-INF/conf/portal/users/{userName}"

<?xml version="1.0" encoding="ISO-8859-1"?>
<widgets>
  <owner-type>user</owner-type>
  <owner-id>root</owner-id>
	
  <container id="Information">
    <name>Information</name>
    <description>Information's Description</description>
    <application>
      <instance-id>user#root:/GateInWidgetWeb/WelcomeWidget/WelcomeWidget1</instance-id>
      <application-type>GateInWidget</application-type>
    </application>
      
    <application>
      <instance-id>user#root:/GateInWidgetWeb/StickerWidget/StickerWidget</instance-id>
      <application-type>GateInWidget</application-type> 
    </application>
    
    <application>
      <instance-id>user#root:/GateInWidgetWeb/InfoWidget/InfoWidget1</instance-id>
      <application-type>GateInWidget</application-type>
    </application>
  </container>
  
  <container id="Calendar">
    <name>Calendar</name>
    <description>Calendar's Description</description>
    <application>
      <instance-id>user#root:/GateInWidgetWeb/CalendarWidget/CalendarWidget</instance-id>
      <application-type>GateInWidget</application-type> 
    </application>
  </container>	
	
</widgets>

Note that when you develop a portal, we advise you to use the XML instead of the User Interface as XML will allow you to provide a preconfigured package to your customer. But as each time you start the server the first time, the XML files are stored in the JCR, it will be necessary to remove the database (the jcr leverages a database). During the development phase using tomcat it simply means to delete the directory: exo-tomcat/temp

If you wish to add a link to a URL outside the portal you you first have to define a "page" which will not be used. Then add the URL to the navigation.

<node>
<uri>http://wiki.exoplatform.com/xwiki/bin/view/Main/WebHome</uri>
<name>documentation</name>
<label>#{portal.classic.documentation}</label>
<page-reference>portal::website::documentation</page-reference>
</node>

To specify the initial Organization configuration, the content of portal.war:WEB-INF/conf/organization/organization-configuration.xml should be edited. This file complies with the XML GateIn configuration schema. It lists several configuration plugins.

The plugin of type org.exoplatform.services.organization.OrganizationDatabaseInitializer specifies the list of users, groups and membership types to be created. The initialization parameter named "checkDatabaseAlgorithm" determines how the creation is triggered. Thus, the value "entry" means that each user, group and membership listed in the configuration is checked each time GateIn is started. If not existing, it is created. The value "empty" means that the whole list of preconfigured users, groups and memberships is processed only if the database is empty.

The predefined membership types are specified in the "membershipType" field of the "OrganizationConfig" plugin parameter. {code} <field name="membershipType"> <collection type="java.util.ArrayList"> <value> <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType"> <field name="type"><string>member</string></field> <field name="description"><string>member membership type</string></field> </object> </value> <value> <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType"> <field name="type"><string>owner</string></field> <field name="description"><string>owner membership type</string></field> </object> </value> <value> <object type="org.exoplatform.services.organization.OrganizationConfig$MembershipType"> <field name="type"><string>validator</string></field> <field name="description"><string>validator membership type</string></field> </object> </value> </collection> </field> {code}

The predefined groups are specified in the "group" field of the "OrganizationConfig" plugin parameter. {code} <field name="group"> <collection type="java.util.ArrayList"> <value> <object type="org.exoplatform.services.organization.OrganizationConfig$Group"> <field name="name"><string>portal</string></field> <field name="parentId"><string></string></field> <field name="type"><string>hierachy</string></field> <field name="description"><string>the /portal group</string></field> </object> </value> <value> <object type="org.exoplatform.services.organization.OrganizationConfig$Group"> <field name="name"><string>community</string></field> <field name="parentId"><string>/portal</string></field> <field name="type"><string>hierachy</string></field> <field name="description"><string>the /portal/community group</string></field> </object> </value> ... </collection> </field> {code}

The predefined users are specified in the "membershipType" field of the "OrganizationConfig" plugin parameter.

  <field name="user">
    <collection type="java.util.ArrayList">
      <value>
        <object type="org.exoplatform.services.organization.OrganizationConfig$User">
          <field name="userName"><string>root</string></field>
          <field name="password"><string>exo</string></field>
          <field name="firstName"><string>root</string></field>
          <field name="lastName"><string>root</string></field>
          <field name="email"><string>exoadmin@localhost</string></field>
          <field name="groups"><string>member:/admin,member:/user,owner:/portal/admin</string></field>
        </object>
      </value>
      <value>
        <object type="org.exoplatform.services.organization.OrganizationConfig$User">
          <field name="userName"><string>exo</string></field>
          <field name="password"><string>exo</string></field>
          <field name="firstName"><string>site</string></field>
          <field name="lastName"><string>site</string></field>
          <field name="email"><string>exo@localhost</string></field>
          <field name="groups"><string>member:/user</string></field>
        </object>
      </value>
      ...
    </collection>
  </field> 

The plugin of type org.exoplatform.services.organization.impl.NewUserEventListener specifies which groups should join all newly created users. It notably specifies the groups and memberships to be used. It also specifies a list of users that should be excepted.

    <component-plugin>
      <name>new.user.event.listener</name>
      <set-method>addListenerPlugin</set-method>
      <type>org.exoplatform.services.organization.impl.NewUserEventListener</type>
      <description>this listener assign group and membership to a new created user</description>
      <init-params>
        <object-param>
          <name>configuration</name>
          <description>description</description>
          <object type="org.exoplatform.services.organization.impl.NewUserConfig">
            <field  name="group">
              <collection type="java.util.ArrayList">
                <value>
                  <object type="org.exoplatform.services.organization.impl.NewUserConfig$JoinGroup">
                    <field name="groupId"><string>/user</string></field>
                    <field name="membership"><string>member</string></field>
                  </object>
                </value>               
              </collection>
            </field>
            <field  name="ignoredUser">
              <collection type="java.util.HashSet">
                <value><string>exo</string></value>
                <value><string>root</string></value>
                <value><string>company</string></value>
                <value><string>community</string></value>
              </collection>
            </field>
          </object>
        </object-param>
      </init-params>
    </component-plugin>

The User Workspace is give privileged users access to administration actions. Please refer to the User Workspace Guide to know more details.

The default configuration defines two groups:

anyone in these groups can access and use the User Workspace. The asterisk symbol stands for "any membership type".

If an administrator wants to allow someone to access the User Workspace, the admin can add the user to one of these groups or he or she modifies the workspace access configuration. This permission is set in the portal-configuration.xml file.

  <component>
    <key>org.exoplatform.portal.config.UserACL</key>
    <type>org.exoplatform.portal.config.UserACL</type>
    <init-params>
...
<value-param>
        <name>access.control.workspace</name>
        <description>groups with memberships that have the right to access the User Control Workspace</description>
        <value>*:/platform/administrators,*:/organization/management/executive-board</value>	    
</value-param>         

Modify the content of the <code>value</code> tag depending on your needs. The configuration is taken into account after you restarted the application server.

Please refer to User Workspace Guide to see the user workspace.

The permission configuration for the portal is defined in the file portal/WEB-INF/conf/portal/portal-configuration.xml. The component UserACL is described there along with other portal component configurations.

It defines 5 permissions types:

 <component>
    <key>org.exoplatform.portal.config.UserACL</key>
    <type>org.exoplatform.portal.config.UserACL</type>   
    <init-params>	     
      <value-param>
        <name>super.user</name>
        <description>administrator</description>
        <value>root</value>	    
      </value-param>
      
      <value-param>
        <name>portal.creator.groups</name>
        <description>groups with membership type have permission to manage portal</description>
        <value>*:/platform/administrators,*:/organization/management/executive-board</value>	    
      </value-param>
      
      <value-param>
        <name>navigation.creator.membership.type</name>
        <description>specific membership type have full permission with group navigation</description>
        <value>manager</value>	    
      </value-param>
      <value-param>
        <name>guests.group</name>
        <description>guests group</description>
        <value>/platform/guests</value>	    
      </value-param>     
      <value-param>
        <name>access.control.workspace</name>
        <description>groups with memberships that have the right to access the User Control Workspace</description>
        <value>*:/platform/administrators,*:/organization/management/executive-board</value>	    
      </value-param>           
    </init-params>   
  </component>

1 Overwrite Portal Default Permissions In GateIn Portal 2.5 and later the UserACL component supports adding a PortalACLPlugin plugin that allows to overwrite portal default permissions.

  <external-component-plugins>
    <target-component>org.exoplatform.portal.config.UserACL</target-component>
    <component-plugin>
      <name>addPortalACLPlugin</name>
      <set-method>addPortalACLPlugin</set-method>
      <type>org.exoplatform.portal.config.PortalACLPlugin</type>
      <description>setting some permission for portal</description>
      <init-params>	    
        <values-param>
          <name>access.control.workspace.roles</name>
          <value>*:/platform/administrators</value>
          <value>*:/organization/management/executive-board</value>	    		
        </values-param>
        <values-param>
          <name>portal.creation.roles</name>
          <value>*:/platform/administrators</value>
          <value>*:/organization/management/executive-board</value>	    	
        </values-param>
      </init-params>
    </component-plugin>
  </external-component-plugins>

GateIn Portal has two different database dependencies. One is the Hibernate service configuration, which depends on the the Hibernate and c3p0 projects. The other database dependency is Java content repository (JCR) service, which depends on the native JDBC API and it can integrate with any existing datasource implementation.

When you change the database configuration for the first time, GateIn will automatically generate the proper schema (assuming that the database user has the appropriate permissions).

You can find the database configuration in the portal/WEB-INF/conf/database/database-configuration.xml file (located in your application server's web application directory).

<?xml version="1.0" encoding="ISO-8859-1"?>
<configuration>
  [...]
  <component>
    <key>org.exoplatform.services.database.HibernateService</key>
    <jmx-name>database:type=HibernateService</jmx-name>
    <type>org.exoplatform.services.database.impl.HibernateServiceImpl</type>
    <init-params>
      <properties-param>
        <name>hibernate.properties</name>
        <description>Default Hibernate Service</description>
        <property name="hibernate.show_sql" value="false"/>
        <property name="hibernate.cglib.use_reflection_optimizer" value="true"/>
        <property name="hibernate.connection.url" value="jdbc:hsqldb:file:../temp/data/exodb"/>
        <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
        <property name="hibernate.connection.autocommit" value="true"/>
        <property name="hibernate.connection.username" value="sa"/>
        <property name="hibernate.connection.password" value=""/>
        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
        <property name="hibernate.c3p0.min_size" value="5"/>
        <property name="hibernate.c3p0.max_size" value="20"/>
        <property name="hibernate.c3p0.timeout" value="1800"/>
        <property name="hibernate.c3p0.max_statements" value="50"/>
      </properties-param>
    </init-params>
  </component>
  <external-component-plugins>
    <target-component>org.exoplatform.services.naming.InitialContextInitializer</target-component>
    <component-plugin>
      <name>bind.datasource</name>
      <set-method>addPlugin</set-method>
      <type>org.exoplatform.services.naming.BindReferencePlugin</type>
      <init-params>
        <value-param>
          <name>bind-name</name>
          <value>jdbcexo</value>
        </value-param>
        <value-param>
          <name>class-name</name>
          <value>javax.sql.DataSource</value>
        </value-param>
        <value-param>
          <name>factory</name>
          <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
        </value-param>
        <properties-param>
          <name>ref-addresses</name>
          <description>ref-addresses</description>
          <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
          <property name="url" value="jdbc:hsqldb:file:../temp/data/exodb"/>
          <property name="username" value="sa"/>
          <property name="password" value=""/>
        </properties-param>
      </init-params>
    </component-plugin>
  </external-component-plugins>
  [...]
</configuration>

The first component configuration is for the Hibernate service. You can enter any additional properties in a hibernate.properties file, but GateIn will override hibernate.properties with values read in from this configuration file.

The second component configuration is for the JCR datasource. The InitialContextInitializer component will load the factory class, use the factory object to create a datasource, and bind that datasource in the JNDI tree with the value of the "bind-name" parameter. If you want to change the bind-name, for example "jdbcexo" to "myjdbc", you also need to change JCR repository configuration in order that the service picks up the right datasource.

There are two JCR configuration files that must be changed to support a different database. In both files, edit the dialect (and the data source name if necessary).

The first file is portal/WEB-INF/conf/jcr/jcr-configuration.xml:

[...]
 <component>
   <key>org.exoplatform.services.jcr.config.RepositoryServiceConfiguration</key>
   <type>org.exoplatform.services.jcr.impl.config.RepositoryServiceConfigurationImpl</type>
   <init-params>
     <value-param>
       <name>conf-path</name>
       <description>JCR configuration file</description>
       <value>war:/conf/jcr/repository-configuration.xml</value>
     </value-param>
     <properties-param>
       <name>working-conf</name>
       <description>working-conf</description>
       <property name="persisterClassName" value="org.exoplatform.services.jcr.impl.config.JDBCConfigurationPersister"/>
       <property name="sourceName" value="jdbcexo"/>
       <property name="dialect" value="hsqldb"/>
     </properties-param>
   </init-params>
 </component>
[...]

The second file is portal/WEB-INF/conf/jcr/repository-configuration.xml:

[...]     
     <workspaces>
       <workspace name="system" auto-init-root-nodetype="nt:unstructured" 
                  auto-init-permissions="*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >
          <!-- for system storage -->
          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
            <properties>
              <property name="sourceName" value="jdbcexo"/>
              <property name="dialect" value="hsql"/>
              <!-- property name="db-type" value="mysql"/ -->
              <property name="multi-db" value="false"/>
              <property name="update-storage" value="true"/>
              <property name="max-buffer-size" value="204800"/>
              <property name="swap-directory" value="../temp/swap/system"/>
            </properties>
[...]
       </workspace>
       <workspace name="collaboration" auto-init-root-nodetype="nt:unstructured" 
                  auto-init-permissions="any read;*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >
          <!-- for system storage -->
          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
            <properties>
              <property name="sourceName" value="jdbcexo"/>
              <property name="dialect" value="hsqldb"/>
              <property name="multi-db" value="false"/>
              <property name="update-storage" value="true"/>
              <property name="max-buffer-size" value="204800"/>
              <property name="swap-directory" value="../temp/swap/collaboration"/>
            </properties>
[...]
       </workspace>
       <workspace name="backup" auto-init-root-nodetype="nt:unstructured" 
                  auto-init-permissions="any read;*:/platform/administrators read;*:/platform/administrators add_node;*:/platform/administrators set_property;*:/platform/administrators remove" >
          <!-- for system storage -->
          <container class="org.exoplatform.services.jcr.impl.storage.jdbc.JDBCWorkspaceDataContainer">
            <properties>
              <property name="sourceName" value="jdbcexo"/>
              <property name="dialect" value="mysql"/>
              <!-- property name="db-type" value="mysql"/ -->
              <property name="multi-db" value="false"/>
              <property name="update-storage" value="true"/>
              <property name="max-buffer-size" value="204800"/>
              <property name="swap-directory" value="../temp/swap/backup"/>
            </properties>
       </workspace>
[...]
      </workspaces>
[...]

Data-injector is an utility to initialize enterprise data for Portal. It is packed in a .jar and deployed under $TOMCATHOME/lib. It is started automatically when Tomcat starts.

OrganizationInitializer is the service that allows creating a large organization with many groups and users. It also creates portal navigation and page(s) for each group, each user.

<configuration>
  <component>
	<key>org.exoplatform.portal.initializer.organization.OrganizationInitializer</key>
	<type>org.exoplatform.portal.initializer.organization.OrganizationInitializer</type>
     <init-params>
      	<value-param>
      		<name>auto.create.group.page.navigation</name>
      		<description>true or false</description>
      		<value>true</value>
      	</value-param>
      	
      	<value-param>
      		<name>auto.create.user.page.navigation</name>
      		<description>number of pages per user</description>
      		<value>10</value>
      	</value-param>
      	<object-param>
      		<name>organization</name>
      		<description>description</description>
      		<object type="org.exoplatform.portal.initializer.organization.OrganizationConfig"> <field name="groups">
	      	<collection type="java.util.ArrayList">
              	 <value>
		  <object type="org.exoplatform.portal.initializer.organization.OrganizationConfig$GroupsConfig"> <field name="group">
		   <object type="org.exoplatform.services.organization.OrganizationConfig$Group">
			 <field  name="name"><string>province</string></field>
			 <field  name="parentId"><string>/africa/tanzania</string></field>
			 <field  name="description"><string>Tanzania's province</string></field>
			 <field  name="label"><string>Province</string></field>
		    </object>				          		
			 </field>	
		    	<field name="from"><string>1</string></field>
		       	<field name="to"><string>10</string></field>
	           </object>
              	  </value>
                </collection>
	      		</field>
      			<field name="users">
      			       <collection type="java.util.ArrayList"> 
 
      				<value>
      		                 <object type="org.exoplatform.portal.initializer.organization.OrganizationConfig$UsersConfig">
      				    <field name="user">
		                  <object type="org.exoplatform.services.organization.OrganizationConfig$User">
		                      <field  name="userName"><string>user</string></field>
		                      <field  name="password"><string>GateInPlatform</string></field>
		                      <field  name="firstName"><string>First-Name</string></field>
		                      <field  name="lastName"><string>Last-Name</string></field>
		                      <field  name="email"><string>exo@localhost</string></field>
		                      <field  name="groups"><string>member:/africa</string></field>
		                  </object>
      				    </field>
      				      <field name="from"><string>0</string></field>
      				      <field name="to"><string>9</string></field>
      				 </object>
      				 </value>
      				</collection>
      			 </field>
      		</object>
      	    </object-param>
          </init-params>
	</component>  
   
</configuration>

The "auto.create.group.page.navigation" Parameter Value is true or false. If TRUE it automatically create portal navigation and page for each group. If FALSE it does not create portal navigation and page for each group.

The "auto.create.user.page.navigation" Parameter Value is number of pages that automatically created for each user.

GateIn provides support for skinning the entire portal User Interface (UI) including your own portlets. Skins are designed to help you pack and reuse common graphic resources.

Skins can be switched dynamically at runtime by the Skin Settings action in User Workspace .

When you switch, the whole portal will be repainted and new styles will be applied to the UI.

An GateIn skin contains css styles for GateIn portal's components but also shares components that may be reused in portlets. When GateIn generates a portal page markup, it inserts stylesheet links in the page's head tag.

<head>
...   
<link id="CoreSkin" rel="stylesheet" type="text/css" href="/GateInResources/skin/Stylesheet.css" />
<link id="web_FooterPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UIFooterPortlet/DefaultStylesheet.css" />
<link id="web_NavigationPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UINavigationPortlet/DefaultStylesheet.css" />
<link id="web_HomePagePortlet" rel="stylesheet" type="text/css" href= "/portal/templates/skin/webui/component/UIHomePagePortlet/DefaultStylesheet.css" />
<link id="web_BannerPortlet" rel="stylesheet" type="text/css" href= "/web/skin/portal/webui/component/UIBannerPortlet/DefaultStylesheet.css" />
...
</head>

In the snipped code above, you can see two types of links :

This is revealed easily by the main portal skin stylesheets. For example /GateInVistaSkin/skin/Stylesheet.css {code} @import url(/GateInResources/skin/PortletThemes/Stylesheet.css) ; @import url(VistaSkin/portal/webui/component/UIPortalApplicationSkin.css) ; @import url(VistaSkin/webui/component/Stylesheet.css) ; {code}

Portlets often require additionnal styles that may not be defined by the portal skin. GateIn allows portlets to define additional stylesheets for each portlet and will append the corresponding link tags to the head.

The link ID will be of the form {portletAppName}{}$$PortletName. For example: ContentPortlet in content.war, will give id="contentContentPortlet"

The SkinService is an GateIn service that manages portal skin, portlet styles and portlet themes (windows borders). The code snippet below is an excerpt of the API offered by this service.

  /**
   * Register the stylesheet for a portal Skin.
   * @param module skin module identifier
   * @param skinName skin name
   * @param cssPath path uri to the css file. This is relative to the root context, use leading '/'
   * @param scontext the webapp's {@link ServletContext}
   */
  public void addPortalSkin(String module, String skinName, String cssPath, ServletContext scontext) {
    [...]
  }
  /**
   * Register a portlet stylesheet for a Skin.
   * @param module skin module. Typically of the form 'portletAppName/portletName' .
   * @param skinName Name of the skin
   * @param cssPath path uri to the css file. This is relative to the root context, use leading '/'
   * @param scontext the webapp's {@link ServletContext}
   */
  public void addSkin(String module, String skinName, String cssPath, ServletContext scontext) {
    [...]
  }
  /**
   * Get a skin configuration for a given Skin
   * @param module skin module such as registered in {@link #addSkin(String, String, String, ServletContext)}
   * @param skinName skin name
   * @return the skin configuration or, if not found try to find the default skin
   */
  public SkinConfig getSkin(String module, String skinName) {
    [...]
  }
  /**
   * Register multiple portlet themes
   * @param categoryName portlet theme category
   * @param themesName names of the themes
   */
  public void addTheme(String categoryName, List<String> themesName) {
    [...]
  }

Use the skin service to register your own portal skins, portlet styles and portlet themes.

GateIn provides a servlet listener that allows you to register your own skins and styles when your webapp starts up. Your first step is to add the listener to your portlet app web.xml.

  <web-app>
    [::]
    <listener>
      <listener-class>org.exoplatform.portal.webui.skin.SkinConfigListener</listener-class>
    </listener>
    [::]
  </web-app>

1.1 SkinConfigScript.groovy

The <tt>SkinListener</tt> looks for the groovy script file located in your war under :

In this script, you have full access to the <tt>SkinService</tt> and <tt>ServletContext</tt> which are bound as scripting variables under the same name. As an example, take a look at the following script. It can be found in the <tt>GateInResources.war</tt> and is used by GateIn to register the <tt>Default</tt> portal skin and some portlet themes.

SkinService.addPortalSkin("CoreSkin","Default", "/GateInResources/skin/Stylesheet.css", ServletContext);
SkinService.addTheme("Simple", ["SimpleBlue","SimpleViolet","SimpleOrange","SimplePink","SimpleGreen"]);
SkinService.addTheme("RoundConer", ["RoundConerBlue","RoundConerViolet","RoundConerOrange","RoundConerPink","RoundConerGreen"]);
SkinService.addTheme("Shadow", ["ShadowBlue","ShadowViolet","ShadowOrange","ShadowPink","ShadowGreen"]);
SkinService.addTheme("MacStyle", ["MacTheme","MacGray","MacGreenSteel","MacBlack"]);
SkinService.addTheme("VistaStyle", ["VistaTheme","VistaBlue"]);

The syntax of addTheme() is: <tt>addTheme(String categoryName, List<String> themesName)</tt>

So, to provide your own skin you could use the following: {code} SkinService.addSkin("mywebapp/MyPortlet", "MyPortalSkin", "/mywebapp/skin/Stylesheet.css", ServletContext); {code}

This simple line would register a styleesheet for a portlet named <tt>MyPortlet</tt> in a portlet app named <tt>mywebapp</tt>. The stylesheet would be used when a skin named <tt>MyPortalSkin</tt> is selected in portal.

The syntax of addSkin() is: <tt>addSkin(String module, String skinName, String cssPath, ServletContext scontext, boolean overwrite)</tt>

Similarly, to configure a particular portal you can use the following : {code} SkinService.addSkin("myportalname", "skin", "/path/to/skin/Stylesheet.css", ServletContext); {code}

The syntax of addPortalSkin() is: <tt>addPortalSkin(String module, String skinName, String cssPath, ServletContext scontext, boolean overwrite)</tt>

1 Tips and Tricks

1.1 Easier css debugging

By default, CSS files are cached and their imports are merged, at the server side, into a single CSS file to reduce the number of HTTP requests from the browser to the server.

The <tt>ServletContext</tt> parameter is there to allow the direct access to the CSS files from the <tt>SkinService</tt>. The optimization code is quite simple as all the CSS files are parsed at the server startup time and all the @import and url(...) references are rewritten to support a single flat file. The result is stored in a cache directly used from the <tt>ResourceRequestFilter</tt>.

Although the optimization is useful for a production environments, you may find it easier to deactivate this optimization while debugging your stylesheets. For that, you simply need to set the java system property <tt>exo.product.developing</tt> to <tt>true</tt>.

For example, you can pass the property as a JVM parameter with the <tt>-D</tt> option in your <tt>GateIn.sh</tt> startup script: {code} EXO{code}

1.1 Change portlet icons

Each portlet is represented by an icon that you can see in the portlet registry, or the webos dock. You can change this icon by adding an image in the directory :

For example, in portal we have an account portlet named AccountPortlet, the icon is located in :

1.1 Set the default skin for Portal

When not configured, the default skin of portal is Default. If you want to change this value (to Mac skin, Vista skin, or your own), add a skin tag in the <tt>portal.xml</tt> that defines your portal:

<portal-config>
  <portal-name>classic</portal-name>
  <locale>en</locale>
  <factory-id>office</factory-id>
  <access-permissions>Everyone</access-permissions>
  <edit-permission>*:/platform/administrators</edit-permission>
  <skin>Mac</skin>
  <creator>root</creator>
...

GateIn relies heavily on CSS to create the layout and special effects for the UI. Below we explain some common techniques you may find often inside GateIn's markup. We explain them here to help you better understand GateIn generated markup, ease css issues fixing or get inspration for styling your own apps.

The decorator is a pattern to create a contour or a curve around an area. In order to achieve this effect you need to create 9 cells. The BODY is the central area that you want to decorate. The other 8 cells are distributed around the BODY cell. You can use the width, height and background image properties to achieve any decoration effect that you want.

~UWC_TOKEN_START~1255420331338~UWC_TOKEN_END~
|            |                                          |             |
| TopLeft    |               TopCenter                  |    TopRight |
|            |                                          |             |
----
|            |                                          |             |
|            |                                          |             |
| CenterLeft |                 BODY                     | CenterRight |
|            |                                          |             |
|            |                                          |             |
~UWC_TOKEN_START~1255420331340~UWC_TOKEN_END~
|            |                                          |             |
| BottomLeft |              BottomCenter                | BottomRight |
|            |                                          |             |
~UWC_TOKEN_START~1255420331341~UWC_TOKEN_END~
<div class="Parent">
  <div class="TopLeft">
    <div class="TopRight">
      <div class="TopCenter"><span></span></div>
    </div>
  </div>
  <div class="CenterLeft">
    <div class="CenterRight">
      <div class="CenterCenter">BODY</div>
    </div>
  </div>
  <div class="BottomLeft">
    <div class="BottomRight">
      <div class="BottomCenter"><span></span></div>
    </div>
  <div>
</div>

Left margin left pattern is a technique to create 2 blocks side by side. The left block will have a fixed size and the right block will take the rest of the available space. When the user resizes the browser the added or removed space will be taken from the right block.

~UWC_TOKEN_START~1255420331342~UWC_TOKEN_END~
|                         |                                                |      
|                         |                                                |      
| |<--- fixed width --->| |                   will expand to right ----> |      
|                         |                                                |      
|                         |                                                |      
|                         |                                                |      
----
<div class="Parent">
  <div style="float: left; width: 100px">
  </div>
  <div style="margin-left: 105px;">
  <div>
  <div style="clear: left"><span></span></div>
</div>

SkinService.addPortalSkin("MyPortalSkin","MyPortal","/GateInResourcesMyPortal/skin/Stylesheet.css",ServletContext);

Secondly, you put all your new skin into folder skinyourSkin and create new file Stylesheet.css here. In this file, you will import all links to your CSS. For example in MyPortal project.

@import url(MyPortalSkin/portal/webui/component/UIPortalApplicationSkin.css) ;
@import url(MyPortalSkin/webui/component/Stylesheet.css) ;

Finally, you have to definy the name of new skin and the image preview for the Skin Settings action in User Workspace.

By default, if you don not set new name for skin, its name is <t>label></tt>. Looking in the file and add yout new name here.

#############################################################################
#                              Change Skin                                  #
#############################################################################
  
UIChangeSkin.action.save=Appliquer
UIChangeSkin.action.close=Fermer
UIChangeSkin.title.SkinSetting=Configuration des styles
UIChangeSkin.MyPortal.label=Style MyPortal
UIChangeSkin.Default.label=Style par d?faut
UIChangeSkin.Mac.label=Style Mac
UIChangeSkin.Vista.label=Style Vista
Skin.title=Liste des styles
Skin.left.title=Voir et s?lectionner un style

The image peeview can be set in file ressource/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/Stylesheet.css of Portal.

.UIChangeSkinForm .UIItemSelector .TemplateContainer .MyPortalImage {
	margin: auto;
	width: 329px; height:204px;
	background: url('background/MyPortal.jpg') no-repeat top;
	cursor: pointer ;
}

And now, you copy your image MyPortal.jpg (that you definy above) to the folder ressource/skin/DefaultSkin/portal/webui/component/customization/UIChangeSkinForm/background and test your new skin.

Firstly, you have to definy the new theme in WEB-INF/conf/script/groovy/SkinConfigScript.groovy in your Ressource (for example, in the project MyPortal, you can put it in GateInResourcesCp060508).

SkinService.addTheme("MyPortal-MacTheme", ["MacGray","MacBlue","MacBlack"]);

Secondly, you put all your new theme into folder skinyourSkin and create new file Stylesheet.css here. In this file, you will import all links to your CSS. For example in MyPortal project.

@import url(MyPortalSkin/PortletThemes/Stylesheet.css) ;

You can see here, in the GateInResourcesCp060508/skin/MyPortalSkin/PortletThemes/Stylesheet.css, you put all your CSS of new theme.

/*---- MyPortalTheme ----*/
.MyPortalTheme .WindowBarCenter .WindowPortletInfo {
	margin-right: 80px; /* orientation=lt */
	margin-left: 80px; /* orientation=rt */
}
.MyPortalTheme .WindowBarCenter .ControlIcon {
	float: right;/* orientation=lt */
	float: left;/* orientation=rt */
	width: 24px; 
	height: 17px;
	cursor: pointer;
	background-image: url('background/MyPortalTheme.png');
}
.MyPortalTheme .ArrowDownIcon {
	background-position: center 20px;
}
.MyPortalTheme .OverArrowDownIcon {
	background-position: center 116px;
}
.MyPortalTheme .MinimizedIcon {
	background-position: center 44px;
}
.MyPortalTheme .OverMinimizedIcon {
	background-position: center 140px;
}
.MyPortalTheme .MaximizedIcon {
	background-position: center 68px;
}
.MyPortalTheme .OverMaximizedIcon {
	background-position: center 164px;
}
.MyPortalTheme .RestoreIcon {
	background-position: center 92px;
}
.MyPortalTheme .OverRestoreIcon {
	background-position: center 188px;
}
.MyPortalTheme .NormalIcon {
	background-position: center 92px;
}
.MyPortalTheme .OverNormalIcon {
	background-position: center 188px;
}
.UIPageDesktop .MyPortalTheme .ResizeArea {
	float: right;/* orientation=lt */
	float: left;/* orientation=rt */
	width: 18px; height: 18px;
	cursor: nw-resize;
	background: url('background/ResizeArea18x18.gif') no-repeat left top; /* orientation=lt */
	background: url('background/ResizeArea18x18-rt.gif') no-repeat right top; /* orientation=rt */
}
.MyPortalTheme .Information {
	height: 18px; line-height: 18px;
	vertical-align: middle; font-size: 10px;
	padding-left: 5px;/* orientation=lt */
	padding-right: 5px;/* orientation=rt */
	margin-right: 18px;/* orientation=lt */
	margin-left: 18px;/* orientation=rt */
}
.MyPortalTheme .WindowBarCenter .WindowPortletIcon {
  background-position: left top; /* orientation=lt */
  background-position: right top; /* orientation=rt */
	padding-left: 20px; /* orientation=lt */
	padding-right: 20px; /* orientation=rt */
	height: 16px;
	line-height: 16px;
}
.MyPortalTheme .WindowBarCenter .PortletName {
	font-weight: bold;
	color: #333333;
	overflow: hidden;
	white-space: nowrap;
	width: 100%;
}
.MyPortalTheme .WindowBarLeft {
	padding-left: 12px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: left -148px;
}
.MyPortalTheme .WindowBarRight {
	padding-right: 11px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: right -119px;
}
.MyPortalTheme .WindowBarCenter {
	background-image: url('background/MyPortalTheme.png');
	background-repeat: repeat-x;
	background-position: left -90px;
}
.MyPortalTheme .WindowBarCenter .FixHeight {
	height: 21px;
	padding-top: 8px;
}
.MyPortalTheme .MiddleDecoratorLeft {
	padding-left: 12px;
	background: url('background/MMyPortalTheme.png') repeat-y left;
}
.MyPortalTheme .MiddleDecoratorRight {
	padding-right: 11px;
	background: url('background/MMyPortalTheme.png') repeat-y right;
}
.MyPortalTheme .MiddleDecoratorCenter {
	background: #ffffff;
}
.MyPortalTheme .BottomDecoratorLeft {
	padding-left: 12px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: left -60px;
}
.MyPortalTheme .BottomDecoratorRight {
	padding-right: 11px;
	background-image: url('background/MyPortalTheme.png');
	background-repeat: no-repeat;
	background-position: right -30px;
}
.MyPortalTheme .BottomDecoratorCenter {
	background-image: url('background/MyPortalTheme.png');
	background-repeat: repeat-x;
	background-position: left top;
}
.MyPortalTheme .BottomDecoratorCenter .FixHeight {
	height: 30px;
}

Manaing Javascript scripts in an application like GateIn Platform is a critical part of the configuration work if you want to get good response time.

Every portlet can have its own javscript code but in many cases it is more convenient to reuse some existing shared libraries. For that reason, GateIn has a mechanism to easily register the libraries that will be loaded when the first page will be rendered. To do so, every WAR deployed in GateIn can register the js files thanks to a groovy script "WEB-INF/conf/script/groovy/JavascriptScript.groovy". The next file is the one you can find in the GateInResources.war

JavascriptService.addJavascript("GateIn", "/javascript/GateIn.js", ServletContext);
/* Animation Javascripts */
JavascriptService.addJavascript("GateIn.animation.ImplodeExplode", "/javascript/GateIn/animation/ImplodeExplode.js", ServletContext);
/* Application descriptor */
JavascriptService.addJavascript("GateIn.application.ApplicationDescriptor", "/javascript/GateIn/application/ApplicationDescriptor.js", ServletContext);
/* CORE Javascripts */
JavascriptService.addJavascript("GateIn.core.Utils", "/javascript/GateIn/core/Util.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.DOMUtil", "/javascript/GateIn/core/DOMUtil.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.Browser", "/javascript/GateIn/core/Browser.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.MouseEventManager", "/javascript/GateIn/core/MouseEventManager.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.UIMaskLayer", "/javascript/GateIn/core/UIMaskLayer.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.Skin", "/javascript/GateIn/core/Skin.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.DragDrop", "/javascript/GateIn/core/DragDrop.js", ServletContext);
JavascriptService.addJavascript("GateIn.core.TemplateEngine", "/javascript/GateIn/core/TemplateEngine.js", ServletContext);
/* Widget Javascripts */
JavascriptService.addJavascript("GateIn.widget.UIWidget", "/javascript/GateIn/widget/UIWidget.js", ServletContext);
JavascriptService.addJavascript("GateIn.widget.UIAddWidget", "/javascript/GateIn/widget/UIAddWidget.js", ServletContext);
JavascriptService.addJavascript("GateIn.widget.UIExoWidget", "/javascript/GateIn/widget/UIExoWidget.js", ServletContext);
/* Desktop Javascripts */
JavascriptService.addJavascript("GateIn.desktop.UIDockbar", "/javascript/GateIn/desktop/UIDockbar.js", ServletContext);
JavascriptService.addJavascript("GateIn.desktop.UIDesktop", "/javascript/GateIn/desktop/UIDesktop.js", ServletContext);
/* WebUI Javascripts */ 
JavascriptService.addJavascript("GateIn.webui.UIItemSelector", "/javascript/GateIn/webui/UIItemSelector.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIForm", "/javascript/GateIn/webui/UIForm.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIPopup", "/javascript/GateIn/webui/UIPopup.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIPopupSelectCategory", "/javascript/GateIn/webui/UIPopupSelectCategory.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIPopupWindow", "/javascript/GateIn/webui/UIPopupWindow.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIVerticalScroller", "/javascript/GateIn/webui/UIVerticalScroller.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIHorizontalTabs", "/javascript/GateIn/webui/UIHorizontalTabs.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIPopupMenu", "/javascript/GateIn/webui/UIPopupMenu.js", ServletContext);
JavascriptService.addJavascript("GateIn.webui.UIDropDownControl", "/javascript/GateIn/webui/UIDropDownControl.js", ServletContext);
/* Portal Javascripts */ 
JavascriptService.addJavascript("GateIn.portal.PortalHttpRequest", "/javascript/GateIn/portal/PortalHttpRequest.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIPortal", "/javascript/GateIn/portal/UIPortal.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIWorkspace", "/javascript/GateIn/portal/UIWorkspace.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIPortalControl", "/javascript/GateIn/portal/UIPortalControl.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.PortalDragDrop", "/javascript/GateIn/portal/PortalDragDrop.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIPortalNavigation", "/javascript/GateIn/portal/UIPortalNavigation.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIMaskWorkspace", "/javascript/GateIn/portal/UIMaskWorkspace.js", ServletContext);
JavascriptService.addJavascript("GateIn.portal.UIExoStartMenu", "/javascript/GateIn/portal/UIExoStartMenu.js", ServletContext);
/* Desktop Javascripts 2 */
JavascriptService.addJavascript("GateIn.desktop.UIWindow", "/javascript/GateIn/desktop/UIWindow.js", ServletContext);

Note that even if the you register dedicated javascripts, they will be merged into a single merged.js file when the server will load in order to reduce the number of HTTP calls as seen in the home page source code:

    <script type="text/javascript" src="/portal/javascript/merged.js"></script>

Although this optimization is useful for a production environment, you may find it easier to deactivate this optimization while debugging your javascript. For that, you simply need to set the java system property exo.product.developing to true. But if you want to see or use the merged file you have to set this property to false. You can pass the property as a JVM parameter with the -D option in your GateIn.sh or GateIn.bat startup script: {code} EXO{code}

Every javascript file is referenced with a module name of type "GateIn.core.DragDrop" which acts like a namespace. Inside the associated files, global javascript functions are used following the same namespace convention:

GateIn.core.DragDrop = new DragDrop() ;

It is also possible to use the GateIn.require() javascript method to lazy load and evaluate some javascript code. This is quite useful from the portlet or widget applications that will use this javascript only once. Otherwise, if the library is reusable in several places it is better to reference it in the groovy file.

In this article, you will learn:

Token service is used in authentication.

Using token helps preventing information such as user name, password into user request so the system will become more secure.

Token service provides the way to manipulate tokens such as create, delete, retrieve, clean ... Token service also defines the life-time of token. After the life-time, token has no more effect. The life-time definition must be configured.

All token services used in GateIn portal's authentication must be a subclass of an abstract class AbstractTokenService . So they must have these following methods:

		public Token getToken(String id) throws PathNotFoundException,
		RepositoryException;
		public Token deleteToken(String id) throws PathNotFoundException,
		RepositoryException;
		public String[] getAllTokens();
		public long getNumberTokens() throws Exception;
		public String createToken(Credentials credentials) throws
		IllegalArgumentException,NullPointerException;
		public Credentials validateToken(String tokenKey, boolean remove) throws
		NullPointerException;

These methods show how the token-service manipulates its tokens.

Token services configuration is also known as specifying the life-time of token in the configuration file. The token service is configured as a portal component.

Examples:

<component>
    <key>org.exoplatform.web.security.security.CookieTokenService</key>
    <type>org.exoplatform.web.security.security.CookieTokenService</type>
    <init-params>
    	<values-param>
          <name>tokenTimeout</name>          
          <value>jcr-token</value>
          <value>7</value>
          <value>DAY</value>
        </values-param>    	
    </init-params>
</component>

In this example, CookieTokenService is a subclass of AbstractTokenService so it has a property which specifies how long token can live.

Service will initiate this property by looking for an init-param named as "service.configuration". This property must have 3 values (service's name, amount of time, unit of time). In this case, we can see the service's name is "jcr-token", the token's expiration time is a week.

At this time, GateIn Portal supports four timing units: SECOND, MINUTE, HOUR and DAY.

This document is an overview of Varnish configuration for GateIn SEA Portal. It is organized as follows:

Varnish is a HTTP/web accelerator, it was written from the beginning to be a high-performance open source reverse proxy caching implementation. Varnish, like other caching reverse HTTP proxy implementations, is most frequently used to alleviate/reduce origin web servers of undue load, giving you the ability to handle a higher number of concurrent hits.

Nowadays, more and more web sites present dynamic web pages consisting of a number of different elements. Combining these elements is both time consuming and CPU intensive. The bad news is that the same process is repeated for every individual user, even when the content is identical. Fortunately in such a case a solution like Varnish can help to improve web server performance. How can Varnish accomplish this? Varnish temporarily stores the most frequently requested pages in its cache. It is more effective to present these pages from the Varnish cache. Therefore, users are offered an improved service, and Content/Document Management System server requirements are reduced.

Before building Varnish, make sure that the following tools are installed :

If you are using a system with a graphical user interface, installation of Varnish 1.1.2 is quite easy via synaptic package manager. If not, you can run in a terminal by the following command to install Varnish on your computer:

You can also install Varnish from source, see the following web site for more information:

http://varnish.projects.linpro.no.

Varnish uses Varnish Configuration Language (VCL). The VCL language is a small domain-specific language designed to be used to define request handling and document caching policies for the Varnish HTTP accelerator. When a new configuration is loaded, the varnished management process translates the VCL code to C and compiles it to a shared object which is then dynamically linked into the server process.

Installation of Varnish automatically create two files named default.vcl and varnish in the repositories /etc/varnish/ and /etc/default respectively. One is VCL and another one contains values that will be passed as parameters to varnished . We will not make use of the first one, that is default.vcl. Create a new file named vcl.conf in /etc/varnish with the following contents:

Backend declaration, here we need to specify the web server host name and the listening http port.

backend default {
		set backend.host = "127.0.0.1";
        set backend.port = "8080";
}
#
## Called when a client request is received
#
sub vcl_recv {
        if (req.url ~ "^/$") {
        set req.url = regsub(req.url,"^/$","/portal");
        set req.http.Accept-Language = "vi";
        }
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        if (req.request!images/= "GET" && req.request!images/ = "HEAD") {
                pipe;
        }
        if (req.http.Expect) {
                pipe;
        }
        if (req.request == "GET" && req.url ~ "\.(jpg|jpeg|gif|ico|tiff|tif|svg|css|js|html)$") {
            set req.url = regsub(req.url, "\?.*", "");
             remove req.http.cookie;
	  remove req.http.authenticate;
             lookup;
        }
       if (req.http.Authenticate || req.http.Authorization) {
             pass;
        }
        if (req.http.Cache-Control ~ "no-cache") {
               set req.http.Cache-Control = regsub(req.http.Cache-Control, "no-cache", "set-cookie2");
        }
        # force lookup even when cookies are present
        if (req.request == "GET" && req.http.cookie) {
                lookup;
        }
        lookup;
}

In order to specify the default language for each web site, that is Vietnamese (vi) for vnwebsite and English (en) for enwebsite; the following statement set req.http.Accept-Language = "language code" is useful.

#
## Called when entering pipe mode
#
sub vcl_pipe {
        pipe;
}
#
## Called when entering pass mode
#
sub vcl_pass {
        pass;
}
#
## Called when the requested object was found in the cache
#
sub vcl_hit {
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        deliver;
}
## Called when the requested object has been retrieved from the
## backend, or the request to the backend has failed
sub vcl_fetch {
        if (!obj.valid) {
                error;
        }
        if (req.url ~ ".*vnwebsite.*"){
                set req.http.Accept-Language = "vi";
        } else {
                set req.http.Accept-Language = "en";
        }
        if (req.http.Cache-Control ~ "no-cache") {
               set req.http.Cache-Control = regsub(req.http.Cache-Control, "no-cache", "set-cookie2");
        }
        if(obj.cacheable){
                remove req.http.Set-Cookie;
	     set obj.http.Cache-Control = "no-cache";
                remove obj.http.Etag;
                if(obj.ttl < 7d){
                        set obj.ttl = 7d;
                }
                insert;
        }
        insert;
}

If the cookie is intended for use by a single user, the Set-Cookie2 header should not be cached. A Set-Cookie2 header that is intended to be shared by multiple users may be cached.

## Called before a cached object is delivered to the client
sub vcl_deliver {
        deliver;
}
## Called when an object nears its expiry time
sub vcl_timeout {
        discard;
}
## Called when an object is about to be discarded
sub vcl_discard {
    discard;
}

This configuration tells Varnish to always cache all cacheable objects and don't invalidate them for at least one week.

Then modify the file /etc/default/varnish and make yourself sure that its content is not too different to this one, particularly the DAEMONOPTS part. Note that we are using the advanced configuration, that is alternative 3.

# Configuration file for varnish
#
# /etc/init.d/varnish expects the variable $DAEMON_OPTS to be set from this
# shell script fragment.
#
# Maximum number of open files (for ulimit -n)
NFILES=131072
# Default varnish instance name is the local nodename.  Can be overridden with
# the -n switch, to have more instances on a single server.
INSTANCE=$(uname -n)
## Alternative 3, Advanced configuration
## We choose advance configuration
#
# See varnishd(1) for more information.
#
# # Main configuration file. You probably want to change it :)
VARNISH_VCL_CONF=/etc/varnish/default.vcl
#
# # Default address and port to bind to
# # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
# # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
VARNISH_LISTEN_ADDRESS=0.0.0.0
VARNISH_LISTEN_PORT=80
#
# # Telnet admin interface listen address and port
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
#
# # The minimum number of worker threads to start
VARNISH_MIN_THREADS=1
#
# # The Maximum number of worker threads to start
VARNISH_MAX_THREADS=2048
#
# # Idle timeout for worker threads
VARNISH_THREAD_TIMEOUT=120
#
# # Cache file location
VARNISH_STORAGE_FILE=/var/lib/varnish/$INSTANCE/varnish_storage.bin
#
# # Cache file size: in bytes, optionally using k / M / G / T suffix,
# # or in percentage of available disk space using the % suffix.
VARNISH_STORAGE_SIZE=5G
#
# # Backend storage specification
VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
#
# # Default TTL used when the backend does not specify one
VARNISH_TTL=7d
#
# # DAEMON_OPTS is used by the init script.  If you add or remove options, make
# # sure you update this section, too.
DAEMON_OPTS="-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
              -f ${VARNISH_VCL_CONF} \
              -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
              -t ${VARNISH_TTL} \
	-w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
              -s ${VARNISH_STORAGE}"

When using an HTTP accelerator, it is important to know whether our web server performance has improved or not. Thus, this section shows the performance gained by the use of Varnish.

Our Varnish testbed consists of a desktop PC acting as a web server (WS), and 10 PC-based Linux acting as clients stations. The system hardware configuration is summarized in the following table. All machines except the WS use a Linux 2.6.27 kernel. The user-agent used on client stations is wget

The following table is the testbed summary:

It is well known that performance of a software like varnish depends on part on the communication link between server host and client stations. So, without loss of generality, we assume that our wireless connection is fair.

In other to evaluate Vanish performance, we first access all pages of our web site through Varnish to ensure that all cacheable objects can be found in Varnish cache. It takes in average 6.9s. Then we simultaneously send 100 download requests from each of our 2 client stations to the web server using wget user-agent through Varnish. After this operation, we evaluate the average time required by each client station to perform a download request. The same process is done without using Varnish. We then compare the obtained results.

This part discuss about Varnish performance in term of time of response. That is the time that a given client should wait to get the requested object (or the server response). In this case the requested object is our entire web site. The collected measurements are summarized in the below table:

Measurements listed above obviously shows that our web server performance are considerably improved by the use of Varnish software. In average per user request, we gain from Varnish 24 (twenty-four) seconds. That is using Varnish, user requests are at least 10 times faster than previously (without Varnish).

This chapter describes the portal lifecycle from the application server start to its stop as well as how requests are handled.

An GateIn Portal instance is simply a web application deployed as a WAR in an application server. Each portlet is also part of an enhanced WAR that we call a portlet application. Hence, the portal web.xml file is the main entry point to grab information about how does the portal start.

The web.xml file contains several information such as a listener, a servlet as well as some security information.

In the web.xml we can find servlet listener:

  <!- ================================================================== ->
  <!-           LISTENER                                                 ->
  <!- ================================================================== ->
  <listener>
    <listener-class>org.exoplatform.portal.application.PortalSessionListener</listener-class>
  </listener>

That listener implements the HttpSessionListener which means it is called each time a session is created or destroyed; in other words, a session is created each time a user send a first request to the portal. That session is destroyed when he has not sent request to the portal for a long time or when he closes his browser.

public class PortalSessionListener implements HttpSessionListener

Only the destroy method of the Listener object is implemented and it is used to flush resources when a user portal session expires. Here is the code:

  /**
   * This method is called when a HTTP session of a Portal instance is destroyed. 
   * By default the session time is 30 minutes.
   * 
   * In this method, we:
   * 1) first get the portal instance name from where the session is removed.
   * 2) Get the correct instance object from the Root container
   * 3) Put the portal instance in the Portal ThreadLocal
   * 4) Get the main entry point (WebAppController) from the current portal container 
   * 5) Extract from the WebAppController the PortalApplication object which is the entry point to
   *    the StateManager object
   * 6) Expire the portal session stored in the StateManager
   * 7) Finally, removes the WindowInfos object from the WindowInfosContainer container
   * 8) Flush the threadlocal for the PortalContainer
   * 
   */
  public void sessionDestroyed(HttpSessionEvent event) {
    try {
      String portalContainerName = event.getSession().getServletContext().getServletContextName() ;
      log.warn("Destroy session from " + portalContainerName + " portal");
      RootContainer rootContainer = RootContainer.getInstance() ;
      PortalContainer portalContainer = rootContainer.getPortalContainer(portalContainerName) ;
      PortalContainer.setInstance(portalContainer); 
      WebAppController controller = 
        (WebAppController)portalContainer.getComponentInstanceOfType(WebAppController.class) ;
      PortalApplication portalApp =  controller.getApplication(PortalApplication.PORTAL_APPLICATION_ID) ;
      portalApp.getStateManager().expire(event.getSession().getId(), portalApp) ;
      
      WindowInfosContainer.removeInstance(portalContainer, event.getSession().getId());
    } catch(Exception ex) {
      log.error("Error while destroying a portal session",ex);
    } finally {
      PortalContainer.setInstance(null) ;
    }
  }

1.1 The Servlet

The servlet is the main entry point for incoming requests, it also includes some interesting init code when the portal is launched.

Here is its definition in the web.xml file:

  <!-- ================================================================== -->
  <!--           SERVLET                                                  -->
  <!-- ================================================================== -->
  <servlet>
    <servlet-name>portal</servlet-name>
    <servlet-class>org.exoplatform.portal.application.PortalController</servlet-class>
    <init-param>
      <param-name>webui.configuration</param-name>
      <param-value>app:/WEB-INF/webui-configuration.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>

The load-on-startup tag tells that the init method of the servlet is called when the application server starts. We also define some configuration for the portal at the path WEB-INF/webui-configuration.xml inside the portal WAR.

/**
 * The PortalContainer servlet is the main entry point for the GateIn Portal product.
 * 
 * Both the init() and service() methods are implemented. The first one is used to configure all the
 * portal resources to prepare the platform to receive requests. The second one is used to handle them.
 * 
 * Basically, this class is just dispatcher as the real business logic is implemented inside 
 * the WebAppController class.
 */
@SuppressWarnings("serial")
public class PortalController  extends HttpServlet {
  
  protected static Log log = ExoLogger.getLogger("portal:PortalController");  
  
  /**
   * The init() method is used to prepare the portal to receive requests. 
   * 
   *  1) Create the PortalContainer and store it inside the ThreadLocal object. The PortalContainer is
   *     a child of the RootContainer
   *  2) Get the WebAppController component from the container
   *  3) Create a new PortalApplication, init it with the ServletConfig object (which contains init params)
   *  4) Register that PortalApplication inside WebAppController
   *  5) Create a new PortalRequestHandler object and register it in the WebAppController
   *  6) Release the PortalContainer ThreadLocal 
   */
  @SuppressWarnings("unchecked")
  public void init(ServletConfig config) throws ServletException {
    super.init(config) ;
    try {
      RootContainer rootContainer = RootContainer.getInstance() ;
      PortalContainer portalContainer = 
        rootContainer.getPortalContainer(config.getServletContext().getServletContextName()) ;
      portalContainer = rootContainer.createPortalContainer(config.getServletContext()) ;
      PortalContainer.setInstance(portalContainer) ;
      WebAppController controller = 
        (WebAppController)portalContainer.getComponentInstanceOfType(WebAppController.class) ;
      PortalApplication application = new PortalApplication(config);
      application.onInit() ;
      controller.addApplication(application) ;
      controller.register(new PortalRequestHandler()) ;
    } catch (Throwable t){
      throw new ServletException(t) ;
    } finally {
      try {
        PortalContainer.setInstance(null) ;
      } catch (Exception e) {
        log.warn("An error occured while cleaning the ThreadLocal", e);
      }      
    }
    log.info("Init of PortalController Servlet successful");
  }
...

We see that a PortalApplication class is instantiated, initialized and then referenced inside the WebAppController. Note that the WebAppController is a component located inside GateIn IoC service container (and hence registered in one of our service configuration XML file).

The <code><strong>PortalApplication</strong></code> extends the <code><strong>WebuiApplication</strong></code> which itself extends the <code><strong>Application</strong></code> abstract class.

public class PortalApplication extends WebuiApplication {
  
  protected static Log log = ExoLogger.getLogger("portal:PortalApplication");  
  
  final static public String PORTAL_APPLICATION_ID = "PortalApplication" ;
  
  private ServletConfig sconfig_ ;
  private String[] applicationResourceBundleNames_ ;
  
  /**
   * The constructor references resource resolvers that allows the ApplicationResourceResolver to
   * extract files from different locations such as the current war or external one such as the resource 
   * one where several static files are shared among all portal instances.
   * 
   * 
   * @param config, the servlet config that contains init params such as the path location of
   * the XML configuration file for the WebUI framework
   */
  public PortalApplication(ServletConfig config) throws Exception {
    sconfig_ = config ;
    ApplicationResourceResolver resolver = new ApplicationResourceResolver() ;
    resolver.addResourceResolver(new ServletResourceResolver(config.getServletContext(), "war:")) ;
    resolver.addResourceResolver(new ServletResourceResolver(config.getServletContext(), "app:")) ;
    resolver.addResourceResolver(new ServletResourceResolver(config.getServletContext(), "system:")) ;
    resolver.addResourceResolver(new ServletResourceResolver(config.getServletContext().getContext("/GateInResources"), "resources:")) ;
    setResourceResolver(resolver) ;
  }
...

The main goal of this constructor is to fill an <code><strong>ApplicationResourceResolver</strong></code> with several <code><strong>ResourceResolver</strong></code> object that will allow the application to check for files such as groovy templates into different locations. Here the goal of the <code><strong>ResourceResolver</strong></code> is to abstract the different mechanisms to extract files from different location. In the previous code sample the <code><strong>ServletResourceResolver</strong></code> is used and hence methods based on the servlet context object are defined. Note that the <code><strong>ApplicationResourceResolver</strong></code> is also a class of type <code><strong>ResourceResolver</strong></code> but a special one as it can also contains several <code><strong>ResourceResolver</strong></code> itself.

Then the <code><strong>onInit()</strong></code> method of the <code><strong>PortalApplication</strong></code> is called.

/**
   * This method first calls the super.onInit() of the WebuiApplication. That super method parse the XML
   * file and stores its content in the ConfigurationManager object. It also set up he StateManager and 
   * init the application lifecycle phases.
   * 
   * Then we get all the properties file that will be used to create ResourceBundles
   */
  public void onInit() throws Exception {
    super.onInit() ;
    applicationResourceBundleNames_ =
      getConfigurationManager().getApplication().getInitParams().
      getParam("application.resource.bundle").getValue().split(",");
    for(int i = 0; i < applicationResourceBundleNames_.length; i++)  {
      applicationResourceBundleNames_[i] = applicationResourceBundleNames_[i].trim() ;
    }
  }

The <code><strong>ConfigurationManager</strong></code> object parses the XML configuration file. The idea of the framework, once again, is to abstract the type of <code><strong>webapplication</strong></code> in used. Hence the <code><strong>webui-configuration.xml</strong></code> file is used by both the portal and portlet applications.

Here is the <code><strong>webui-configuration</strong></code>:

<webui-configuration>  
  <application>     
    <init-params>
      <param>
        <name>application.resource.bundle</name>
        <value>locale.portal.expression, locale.portal.services, locale.portal.webui</value>
      </param>
    </init-params>
    <ui-component-root>org.exoplatform.portal.webui.workspace.UIPortalApplication</ui-component-root>    
    <state-manager>org.exoplatform.portal.application.PortalStateManager</state-manager>
    
    <application-lifecycle-listeners>       
      <listener>org.exoplatform.portal.application.PortalStatisticLifecycle</listener>       
      <listener>org.exoplatform.portal.application.PortalApplicationLifecycle</listener>
      <listener>org.exoplatform.webui.application.MonitorApplicationLifecycle</listener>       
    </application-lifecycle-listeners>     
    <events>
      <event>
        <event-name>portal.application.lifecycle.event</event-name>
        <listener>org.exoplatform.webui.event.ConsoleEventMonitorListener</listener>
      </event>
      <event>
        <event-name>portal.execution.lifecycle.event</event-name>
        <listener>org.exoplatform.webui.event.ConsoleEventMonitorListener</listener>
      </event>
    </events>
  </application>
</webui-configuration>

In the previous XML file we see that we define several tags such as:

1.1.1 The ui-component-root

Here it is the class <code><strong>org.exoplatform.portal.webui.workspace.UIPortalApplication</strong></code> which is a class that extends the <code><strong>UIApplication</strong></code> and hence is a sibling of <code><strong>UIPortletApplication</strong></code> (used by any GateIn Portlets as the Parent class to build the portlet component tree).

The <code><strong>UIPortalApplication</strong></code> is responsible for building its subtrees - at request time according to some configuration parameters. If all components are displayed it is composed of 3 UI components:

The <code><strong>UIPortalApplication</strong><code> constructor is shown next and is the starting point to build the UI Component tree to which Pages and Portlets will also be mounted. We will not describe that behavior here.

/**
   * The constructor of this class is used to build the tree of UI components that will be aggregated
   * in the portal page. 
   * 
   * 1) The component is stored in the current PortalRequestContext ThreadLocal 
   * 2) The configuration for the portal associated with the current user request is extracted from the 
   *    PortalRequestContext
   * 3) Then according to the context path, either a public or private portal is initiated. Usually a public
   *    portal does not contain the left column and only the private one has it.
   * 4) The skin to use is setup
   * 5) Finally, the current component is associated with the current portal owner      
   * 
   * @throws Exception
   */
  public UIPortalApplication() throws Exception {
    log = ExoLogger.getLogger("portal:UIPortalApplication"); 
    PortalRequestContext  context = PortalRequestContext.getCurrentInstance() ;
    userPortalConfig_ = (UserPortalConfig)context.getAttribute(UserPortalConfig.class);
    if(userPortalConfig_ == null) throw new Exception("Can't load user portal config");
    
    //  dang.tung - set portal language by user preference -> browser -> default
    //----
    String portalLanguage = null ;
    LocaleConfigService localeConfigService  = getApplicationComponent(LocaleConfigService.class) ;
    OrganizationService orgService = getApplicationComponent(OrganizationService.class) ;
    LocaleConfig localeConfig = localeConfigService.getLocaleConfig(userPortalConfig_.getPortalConfig().getLocale());
    String user = context.getRemoteUser();
    if(user!images/= null) {
      UserProfile userProfile = orgService.getUserProfileHandler().findUserProfileByName(user) ;
      if(userProfile!images/= null) {
        portalLanguage = userProfile.getUserInfoMap().get("user.language") ;
       } else {
         if (log.isWarnEnabled()) log.warn("Could not load user profile for " + user + ". Using default portal locale.");
       }
    }
    localeConfig = localeConfigService.getLocaleConfig(portalLanguage) ;
    if(portalLanguage == null ||!images/portalLanguage.equals(localeConfig.getLanguage())) {
      // if user language no support by portal -> get browser language if no -> get portal
      portalLanguage = context.getRequest().getLocale().getLanguage() ;
      localeConfig = localeConfigService.getLocaleConfig(portalLanguage) ;
      if(!portalLanguage.equals(localeConfig.getLanguage())) {
        localeConfig = localeConfigService.getLocaleConfig(userPortalConfig_.getPortalConfig().getLocale()) ;
      }
    }
    setLocale(localeConfig.getLocale()) ;
    setOrientation(localeConfig.getOrientation());
    //----
    context.setUIApplication(this);
    UserACL acl = getApplicationComponent(UserACL.class);
    if(acl.hasAccessControlWorkspacePermission(context.getRemoteUser()))
      addChild(UIControlWorkspace.class, UIPortalApplication.UI_CONTROL_WS_ID, null) ;
    addWorkingWorkspace() ;
    String currentSkin = userPortalConfig_.getPortalConfig().getSkin();
    if(currentSkin!images/= null && currentSkin.trim().length() > 0) skin_ = currentSkin;
    setOwner(context.getPortalOwner());
  }
...

1.1.1 The StateManager

The <code><strong>StateManager</strong></code> here is in the <code><strong>org.exoplatform.portal.application</strong></code> package which is an abstract class.

abstract public class StateManager {
  abstract public UIApplication restoreUIRootComponent(WebuiRequestContext context) throws Exception ;
  abstract public void storeUIRootComponent(WebuiRequestContext context) throws Exception ;
  abstract public void expire(String sessionId, WebuiApplication app) throws Exception ;
}