As I mentioned to somebody else the other day, I’m relatively new to the portals. So this blog post might not be extremely revealing for somebody who used to be working with the portals for a while. On the other hand, while Microsoft does have a very extensive documentation on the portals, personally I’d love to see a bit of a high level overview first so I could put all other information into the appropriate buckets. I used to work on the custom portal implementations, so I can relate to some of the techniques / issues / solutions implemented in the former ADX / current Dynamics portals, but what I’m sort of missing is the introduction into what fits where in the data model.
So, with that said, let’s see if I can pull off my own introductory post.. And forgive me Adoxio people, I feel like I’m trespassing now
Anyway, when looking at the portal entities in Dynamics, a lot of them just make sense:
Intuitively, we know what a redirect is, what site settings are, what invitations are.. the same goes for ads, polls, poll placements, etc. You can look at many of them, read on quickly, and you’ll get a pretty good idea of what they are for.
Where it may get confusing, at least it did for me, is with these few:
- Web Sites
- Web Pages
- Page Templates
- Web Templates
- Web Forms
- Entity Forms
- Entity Lists
- Web Files
What’s a web page and how is it different from page template? How is page template different from web template? What’s a web form and how is it different from entity form?
Especially since most of those show up on this single screen:
So, before I continue.. What about the Web Files and Web Templates? They don’t show up on the screenshot.
With the web files, it’s relatively simple: as per the documentation, “A web file represents downloadable file in a portals website, used to store images, documents, and any other file type”. This includes CSS, png, jpg, etc files. In Dynamics terms, those would be web resources.
Web Templates are more complicated – they are part of the mix above, so we’ll get to them down below.
Now let’s start defining the purpose of those entities from “simple” to “complex” (technically, they should probably be arranged differently, but I’m only talking about the conceptual meaning).
Web Site
This is all about web site metadata including the header and footer references, site settings, access permissions, roles, linked page templates and content snippets, etc. Normally, there is 1 web site per environment (unless, I guess, you wanted to be able to switch between sites). Look at it this way.. Your portal deployment is just generic code – in order to display an actual web site it needs site-specific details. And you provide those details to the portal by provisioning a WebSite record in Dynamics.
Now, if a web site is more like an overarching entity, the 3 entities that follow are sort of page “content controls” since we can put them on the web pages:
1. Entity Form
One of the main benefits of using the portals is that we can design a form in Dynamics and, then, expose it on the portal. However, we can have a lot of entity forms in Dynamics, and we need to tell the portal, somehow, which one we want to use on the portal. This is what we can do using the Entity Forms. And, while doing it, we can also define some portal-specific behavior such as whether we want to generate steps from tabs, what we want to do on success, whether we want to add some javascript when the form is displayed, etc. But, essentially, it’s a “content control” for the portal, since you can use the same entity form on different pages.
2. Entity List
Just like with the entity forms, we can quickly expose a list of records, or a grid. And, just like with the entity forms, entity lists are built on top of Dynamics native metadata – for each entity list we have to identify the entity and the views. Other than that, there are some portal-specific settings such as which buttons to show, whether to display search, whether to add custom javascript, etc. Still, it’s yet another content control.
3. Web Form
Where an Entity Form represents a single form, a Web Form represents multiple Dynamics forms (or tabs from those forms). Each of those individual forms/tabs is represented by a Web Form Step. In other words, it’s, basically, a step-by-step experience.
A Web Form is a holder for all those individual steps, and every individual step is somewhat similar to an Entity Form.. but we are getting some multi-step specific settings and perks (“next step”, related web form sessions, etc)
By this moment what’s left of the original list is: Web Pages, Web Templates, Page Templates. So we are doing well – it’s down to 3 entities.
Now, I mentioned “content control” a few times before. This is not an official term, but I’d like to keep using for simplicity because here is how all those entities could be categorized, then:
- Content Controls: Entity Form, Entity List, Web Form
- Metadata: Web Site, Web Page, Page Template
- HTML: Web Template
Let’s have a look at the HTML category first
Web Template
This is your actual “HTML”, or the template. Conceptually, this can’t be any simpler – any web page should be displaying some HTML, whether it’s static or dynamic:
Of course that source code on the screenshot is far from being simple, but we are just trying to understand the purpose of the entities. Not the details of how to work with them.
Finally, let’s get back to the Metadata. We’ve looked at the Web Site, but, somehow, I have two more entities there: Page Template and Web Page. And, I think, this is where I may still be getting it somewhat wrong.
Every Page Template may have multiple associated Web Pages. Every Web Page has to have a Page Template. A Web Page is more about the portal structure, properties, and associated content controls – this is where you can define child pages, url, publishing state, associated web form/entity form/entity list, exclude that page from search, hide it from the sitemap, etc.
Whereas a Page Template is more about HTML metadata: this is where you can define the title, specify if the header/footer will be displayed, etc.
Given that a page template has only a few attributes (see below), what is the reason there is a special entity for that – why could not all those attributed be placed directly on the Web Page entity? Other than providing an additional level of abstraction/decoupling, I can’t think of any other reason right away.. This is where a good example would be handy, but, since I don’t have one, let’s just say that Web Page is what you need to create when defining a new portal page, and, in order to link that new web page to an actual Web Template, you need to use a Page Template (besides, this is where you can also say if you want to use header/footer for that web page or not).
Hope that helps.. Have fun with the portals!