Registreren

Pages
- Building your application
- Advanced functions
  - Deployment
  - Branches
  - Security
  - Mail & spam
  - Standard urls
  - REST API
  - SSO
  - Social media
  - HTML Editor
- Hosting
- Miscellaneous

General url conventions

A url sent to a server is basically a command (or request) to do something and return a response. Url's are often created automatically to control the page flow, but may also be defined explicitly in the blueprint for example to define a home page, set succeeded or failed pages or in html templates.

1. Determining the application

The application name is always inferred from the domain name part of the url. There are two variants, one for crossmarx.nl or crossmarx.com domain names and one for all other domain names.

In the first case the application's technical name should be incorporated as a (3rd or fourth level) subdomain name. For example a application with technical name "garden" could be addressed with garden.crossmarx.com or on our testserver with garden.test.crossmarx.com. So the basic format is:

applicationname.servername.crossmarx.com

* The abbreviated version that leaves out the servername may require a specific request to us, so that we can relay this domainname to the right server

In the second case the crossmarx.nl domain is not used. Therefore, the domainname, for example www.olivegarden.com must be mapped to the application and the server in the studio.

For compatibility reasons, other methods are still supported. These include starting the application with the "app" request parameter (for example test.crossmarx.com/engine?app=garden) or using the servlet path, for example test.crossmarx.nl/garden. They will be deprecated in the near future.

Specific installations

There are alternatives available for this scheme, mostly used for users that run a single application on their own server or virtual server. In this case the name of the application may be set in the environment properties.

2. Url request types

After the application is known, next the actual request is analyzed. The request is the part of the url without the domain name. The request tells the application engine what to do. A common request form starts with /engine followed by a series of request parameters, for example:

/engine?service=selector:4390&cmd=search

This request tells the application engine to present the search screen for the class with identifier 4390 in the blueprint. Request of this form are usually created by the application engine itself.

Other requests look more like traditional url's retreiving a file:

/home.vm
/images/logo.jpg

The first example reads the file home.vm from the application's document root. Since the extension indicates the file to be a velocity template, the content of the file is evaluated first before the final response is returned. The second example returns an image file.

A third type of request look like traditional url's but do not correspond directly to a file resource of the application. Instead they are interpreted as special commands fot the application engine, for example:

/engine/download/blob/...
/blobs/garden/...

The first request downloads a blob from the file system but the application engine first checks if the user is allowed to do so. Notice that since this type of request starts with /engine/, you cannot use a directory called "engine" in your application files. The second request also uses a reserved word "blobs". This request retreives a public database blob from the file system. There are a few other reserverd words but these are not likely to be used as directory name.

Finally, there are special types of request that are used for Search Engine Optimalization. For example:

/get/5432/40/alexander-the-Great
/biography/alexander-the-Great

Both requests retreives the details of object 40 of class 5432, a biography of Alexander the Great. Both requests are rewritten internally as a request type already mentioned above like so: /engine?service=classmanager:5432&cmd=open&id=40. The first request may be generated automatically by the application engine, the second is mapped from an specific url entry in the application database. More about this in the documentation on Search Engine Optimalization.

Although there are more request types, you know now the most common and important types.

Url's in the blueprint

Url's entered in the blueprint as a field value, action parameter value etc... are always relative to the application's document root (with the exception of url's starting with the "http://" protocol). So, wether or not the url starts with a forward slash "/", both behave exactly the same way. For example "myfile.vm" or "/myfile.vm" both refer to the file myfile.vm in the application root. This may be different than what your are used to when using url's in a html file. However this is completely logical when you realize the blueprint has no real location in the document root so there is no actual directory to refer to.

Note that even if a html (or velocity) file is located in the application document root, it is best to always use url's preceded with a forward slash like "/home.vm". The reason for this is that the file is not always returned directly by the web server, but may have been parsed, modified or otherwise handled by the application engine. In those cases the directory the file is located is irrelevant and the base url is considered to be the domain name.