Friendly URI

One of the most important features in InfoGlue is Nice-URI or friendly URL’s. What it’s all about is that instead of referencing a page with a cryptic parameter string like in /ViewPage.action?siteNodeId=22&languageId=11&contentId=-1 your users can find the page by using /Products/Boats or some other understandable URL.

How does it work

Nice URI can work as InfoGlue tries to match all incoming URI:s to a particular site node/page. All URL:s created on pages are also translated to a readable URL in the reverse way. This is not that easy and there are two tricks to this:

The first trick is for InfoGlue to find out which repository the page the user tries to look at is located in (since there may be many repositories and potentially those could all have a similar structure). In theory several sites can have the same page structure and therefore InfoGlue would not know where to go to find /contact/about_us for example if both repository1 and repository2 has the same structure. This is solved by using different dns-names for all repositories or by using a path for each repository. So if you have two repositories, Infoglue will first match the name of the dns coming in from the users browser request (http://www.infoglue.org for example) against the dnsNames registered on each repository and pick the repository which matches. If several repositories matches and the first part in the friendly URL contains a path which one of the repositories have defined that one is choosen. So if the repository “InfoGlue” should be picked it has to have www.infoglue.org in the dnsNames-attribute while you use other names for other repositories.

The second trick is for InfoGlue to find the pages. The /products/boats path given in the browser is matched against the site structure (defined in the structure tool) for that repository. It is possible to set which attribute on each page to match against.

Limitations and pitfalls

 

Encoding

As urls are not supporting anything else than ASCII in them any pages with international characters in them needs to be encoded/decoded. This works if you set up InfoGlue NiceURI encoding correctly to fit your platform but the url:s are far from readable as the Uri’s will contain a lot of special characters etc.

Setup Instructions

This part assumes that Nice URI is turned on – look at the settings section for info.

For each repository create a dnsName for each state (working/preview/live). This may require you to register quite some dns-entries if you want all sites to have a unique dns name and have nice uri enabled in both working and live. It may be a better idea to use paths for the different repositories in working-mode or in all modes but that may be a non technical decision. Whatever way is supported.

As an example we would have the following dns-names for www.infoglue.org pointing to the same machine:

The main site

  • www.infoglue.org
  • preview.infoglue.org
  • working.infoglue.org

A marketplace site

  • market.infoglue.org
  • preview.market.infoglue.org
  • working.market.infoglue.org

Enter the dnsNames for each repository. Use paths to separate them if you cannot have unique domains for them.

Luckily you can use the form with assistance so you don’t have to remember the cryptic format. Also – there is a great “Explain”-link next to the DNSName-field which explains your current settings and their effect. The working=, preview= and live= - arguments are just for the tools to know what URL to use when launching the site from different places in the administrative interfaces. For example – the preview button on a site node in the www.infoglue.org-repository will check out the working=-keyword and launch working.infoglue.org thereby letting InfoGlue find the right repository in NiceURI-mode. You can also add more entries but without any keyword before. If you for example add ,www.infoglue.com last to the ww.infoglue.org-repository people coming in with that domain will come to the right site so you can have many aliases for the same site but only one “working=”, “preview=” and “live=” keyword.

Since InfoGlue 2.4 we have added a feature which allows a simple way to map several repositories to a single domain. So www.infoglue.org could serve X number of repositories where each repository would have to have a subdir like www.infoglue.org/market or www.infoglue.org/plugins.

Now the users calling http://www.infoglue.org/marketplace/Components will come to the component-page directly under the marketplace repository.

NiceURI are pretty flexible. It allows you to influence the algorithm for creating the Uri’s pretty much. By default the name used in the Uri’s are the NavigationTitle for the sitenodes involved but you can easily set it to use for example the site node name(the non-localized one in structure tree) or a node properties attribute of your choice. You can also set up character-replacement-mapping etc. You set this up in application settings.