Zimbra Social has support for defining urls by using the plugin infrastructure. This change allows developers to create general site pages, handlers and application-based pages using a simple plugin pattern.
Urls are created using a facade over the standard ASP.NET routing architecture. It is important to note, however, that generating urls as you would in ASP.NET MVC or ASP.NET Web Forms will not work, To ensure proper handling of urls, you must use the interface/controller patterns defined by the API. Fortunately, the API is very similar to that used in these other technologies.
First, it's important to understand there are 3 types of Urls that the Zimbra Social Platform can create:
- REST Endpoints: These are not new and have not changed, but they're noted here as a reminder. REST endpoints follow a different plugin pattern and should not use the new APIs.
- Generic Urls: Another way to think of these is site-level urls. They do not rely on an application or container and will utilize the Site theme when rendered.
- Application Urls: These urls are dependent on the content core service, meaning they relate to an application specifically. Examples include Blogs, Forum and Group urls.
This illustration loosely represents how each of these url types are processed in the pipeline.
Generally, with the exception of REST, the different types go through a similar process. The single difference is that Application Urls will parse their own application and container types before the other stages.
- The first step involves matching a url. First, it attempts to match a non-application url. This includes generic urls and REST endpoints. If one of those is not matched, it will attempt to match an application url.
- Parse Context: This method is used to obtain information from the route and provide it to the underlying system. For example, the url may contain an Id for your content. Using that, you can obtain the content from the underlying platform and add all the relevant information to the page context. Page context is what drives "Current" in terms of content.
- Validate: This method can be used to check security or redirect to another location. At this time, the context should already be populated.
- Set Theme: This is where the theme is applied.
- Handle Response: This is the last step. For standard Urls, a page object is created and sent to the browser. For RAW urls, whatever is written to the response is processed.
This is a general description of the pipeline, the details mentioned above will be explained in greater detail later.
No more SiteUrl overrides or SiteUrl redirect files
In previous versions, urls were defined in an override file and relied on complex xml syntax to work. This file is no longer used. If you are currently using it to define new urls, you will need to convert them to use this new pattern. In the same respect, the platform no longer supports overriding existing site urls. The SiteUrls_Redirects file is also gone. This process still works, but no longer uses the file.
No more ASPX pages
Creating urls does not also include creating an aspx page. The url infrastructure uses virtual pages instead of actual pages. This means that when you define a url, it will automatically handle the generation of the page markup behind the scenes when the url is served. If you want to define default widgets, then the APIs provide an outlet to do that. Because you no longer work with the page directly, you can no longer rely on the traditional ASP.NET lifecycle.
All non-control panel urls, with a few exceptions, no longer have extensions(.aspx,.ashx). You are encouraged to update any external bookmarks to reflect this change; however, should you try and use a url with an extension. The platform will automatically redirect the request to the extension-less equivalent.