Repositories

One of the most central concepts of InfoGlue is “Repositories”. It is most often similar with a website but it can be other things as well. The term repository was picked to illustrate that it is a collection of information. It can be a website and its information but it can for example also be an image bank or an internal place to store document. In this chapter we will however discuss it in the terms of website repositories.

If you click on the menu option “Repositories” you will get a list with the repositories you have registered in your system so far. It may look something like this:


 

The list will show the existing repositories and a description for each including which URL it shall respond on when using NiceURI:s.
Importing a repository

A very handy feature introduced in 1.3 is the ability to import an entire repository from another infoglue installation. This means you can transfer all content, structure and relations on a site by importing a simple xml-file previously exported from an infoglue system.

NOTE: This feature is not to be regarded as a backup feature as it’s only suitable to use for transferring development, non published versions of sites.

To begin importing a repository just press the “Import repository”-button on top of the repository listing. The dialog will ask for a file to import:

 

 

Browse your hard drive and point out the xml-file that contains the repository you want to import and press “Save”. The resulting dialog just informs you about the success:

 

 

Now press the repository-menu item again and verify that the imported repository is listed among them.
Repository details

A repository is mainly a definition that has to exist before you can build anything. All content and other things that are interesting for a site must be located inside a repository. A repository also has a detail view. Click on the repository name and you will see the following:

 

 

In this view you can edit a few things as well as delete or export the repository. Below is a chart of the fields and their use.

 

Field name

Typical values

Comment

Repository name

Any name you want but short. A site name is most often used. intranet.mycompany.com could be an example.

This value is used mainly for administrative and visual guidance now.

Description

State what the repository is for. Can be any describing text.

 

DNS Name

working=http://localhost:8080,preview=http://localhost:8080,live=http://www.infoglue.nu:8080,workingPath=igc

Whatever domain you want the repository to answer to when using NiceURI. Use the form that is shown when you click on the field.

 

More information on NiceURI and configuration can be found in the “InfoGlue Administrative Manual”.

 

Below these fields in the repository detail view you can also state which languages you wish to exist on the repository. We will discuss languages later but for now it’s important to understand that a repository can contain one or many languages. The languages chosen here will affect the content tool and the dialogs in it for example.

 

You can add languages or subtract to a site at any time so a repository can for example start off with just supporting an English version and then after a while add support for German or French if needed without having to develop anything new.

Exporting a repository

A very handy feature introduced in 1.3 is the ability to export an entire repository. This means you can export all content, structure and relations on a site to a simple xml-file. This file can then either be used as backup or for transferring repositories between infoglue installations.

The only step needed when exporting a repository is to click on the “Export repository”-button (set optional parameters if you want) and press the “Save”-button when the following dialog shows:

 

The result will be the following:

You can now right-click on the link and “Save link as” or whatever your browser let’s you do thereby saving it locally on your hard drive or other media.

Warning:Users should know that there are restrictions to this feature which means extensive testing always should be done after a transfer or the repository to verify that the site works as before:

  • It will not follow references outside the repository in question which means reused content from other repositories will not get exported.
  • System settings are sometimes tricky to export and users and roles including access rights are not included.
  • Languages and content types etc are remapped to the new system if the names are identical – otherwise the originals are recreated on the new system.
  • This feature is not to be regarded as a backup feature as it’s only suitable to use for transferring development, non published versions of sites.

Repository properties

A new feature introduced since 1.3 is the ability to have properties on almost anything through the integration of OS PropertySet. This feature is used under the button “Edit Properties” to allow users to customize the WYSIWYG on site-level as well as to set up other aspect of how the repository relate to other repositories.

 

 

 

 

 

When editing the Repository properties you get the following interface:

 

 

The fields in this view are:

  1. WYSIWYG Configuration and Styles Configuration: You just paste the settings for the WYSIWYG right in. Read the chapter about WYSIWYG-configuration for more information on this topic. The same settings can be done on role and user props.
  2. Default folder content type: this of course sets what content type should be pre selected when creating a folder. Folders are also normal contents but it’s usual to have a special content type or none at all for them as they are seldom used in the presentation.
  3. Default repository for component dialog: Set the repository you wish the component dialog should default to when binding in a new component. If not set the repository the user is working in is shown but often one stores the components in a separate repository for reuse and management sake and then it’s nice to avoid switching to it all the time.
  4. Parent repository (if any): This property lets the user set which repository is the parent to this repository. Can be used in situations where you have local divisions etc which all are sub sites to the global site. If a site has a parent repository this means that properties etc can be inherited from that site.
    Access rights on a repository

In Infoglue 2.0 we have restructured the interfaces a bit. Gone is the old drop in management where you choose site and then access rights or permissions on it. Now you instead click on the “Access Rights”-button on the repository detail screen.

 

 

The screen will the show the common access rights view:

 

 

The new thing in Infoglue 2.0 is that now there is not only a Read-right which controls what roles are allowed to access this repository in the tools but also a ReadForBinding-right which lets you decide what roles are allowed to reuse content and pages through bindings from your site in other sites. This is convenient when you do not want users to see and be able to modify for example a “General Image”-repository but you still want them to be able to use the images in it from their pages.

Another new feature in InfoGlue 2.0 is that you can mix roles and groups in the access rights. To allow access to something you must always still use role but now you can also state that the users not only has to be part of that role but also part of a special group. This is done by clicking the icon. This will be colored if groups have been selected before and it will only show if a role in that column have been selected and saved.
Languages on a repository

In Infoglue 2.0 we have restructured the interfaces a bit. Gone is the old drop in management where you choose site and then languages on it. Now you instead click on the “Repository Languages”-button on the repository detail screen.

 

 

The screen will look like this:

 

 

The new thing in Infoglue 2.0 is that now you can order languages within a site so not the first system language has to be the master language. The important thing to understand is that the first language in the list here is the language that the site will fallback to if the asked for language does not exist. This is of course if you use language fallback in your templates.

The languages listed are those defined in the management àlanguages area and you tick the ones you want on your site (can be done in the repository detail screen already). To change order you just use the up / down arrows. The other options on this page is not yet used.

Warning: Remember to not change master language after you have started building you pages as the page-definitions are always stored in the master language version on a site. That will render you pages empty.