How Does it Work
You're currently viewing XMPL V3
Attention: XMPL V5 beta is now available!
Let's go a little bit into how an XMPL page receives and updates its data and how do the HTML directives work.
The XMPL webpage shows data. If you are using one of the controllers of XMPL, and its directives, then the data is usually of the recipient who is viewing the page.
The data is stored together with other campaign materials on a uProduce server. A uProduce server is a source for campaign materials. It can be used to send emails, create PDF files, and provide ADOR data, where the ADORs are defined by the campaign plan.
The XMPL page access to the uProduce server is mediated by an XMPL server, which provides a simple REST-based access to the data. It mostly works through the Circle registration of this uProduce server, not directly, so make sure to register this server to Circle.
The REST services provide all functionality that is available to an XMPL site. In fact, you can access the REST layer directly, independently of XMPL, which simply provides Javascript and HTML add-ons on top of it.
Important: XMPL websites are hosted on the XMPL web server, a publicly accessible server via the internet. Therefore, any static files (HTML, PDF, images, etc.) which you upload as part of your website are also publicly accessible. It is highly recommended that you do not store confidential or sensitive files on the XMPL server.
The xmpResource object is an AngularJS service that implements multiple functions, matching the REST services.
The XMPL library controllers use it to access the remote XMPL server for all required data fetching and manipulation functionality.
If you are programming your own AngularJS application you can use it directly.
The XMPL controllers - XMPPersonalizedPage and XMPAnonymousPage - are controllers that are used with an ng-cotroller and implement generic page behaviors. The XMPPersonalizedPage defines a page that when loaded shows personalized information. XMPAnonymousPage is a page that is used to implement a registration form by which it is possible to create a new recipient. Initially it is not personalized, and later it becomes personalized to the newly-registered recipient.
To implement their functionality, the controllers use xmpResource for fetching and manipulating data.
The controllers make room for the usage of XMPL tags and attributes (directives).
These are attributes that you can add to HTML elements to make them personalized (such as adding xmp-image-asset to an img tag to have it show a personalized image), as well as elements that take care of other personalization scenarios.
The directives fetch their data from the controllers, thus sharing it. When the controllers are loaded they scan the page for XMPie attributes and know which data to fetch, so that the directives can provide the personalized functionality. The directives may also make calls to the controllers in order to implement some of the functionality (for example, an XMPL form attribute updating recipient data (xmp-update) uses the controller function to perform the actual update). In essence, the XMPL directives are simple helpers for accessing the controller data and functionality, in a declarative manner.
The page, which defines a reference to a controller and uses the directives to declare the personalized areas, thus becomes personalized.
New!! Take a look at XMPL V5 Beta