3. View Syntax
3.1 General
A view file uses a basic xml syntax where elements start with tags, have a set of attributes and can contain other elements. The view parser is pretty strict and will break on most invalid xml. Please note that xml and xhtml are case sensitive, and this is also the fact for SASP view files: a lowercase attribute is a different one that the uppercase.
A view file contains basically two things: xml elements and view variables.
Elements and controls:
Every xml element in a view file can be converted to a SASP control when a server-side token is present (see 2.4 Creating controls from a view). If no custom control then the equivalent default SASP control will be created. For most elements the control created will be of type HtmlControl?, see 3.2 Default SASP controls for a list of the available SASP control mapping.
You can define custom controls to use in a view by declaring them at the top of the page, using the header directive syntax like:
<% MyControl : /PathTo/Control %>
You can then place the control like any other xml element:
<MyControl _id=”myCtl” someAttribute=”someValue” />
If you wish to use namespaces in your tags, you can do that too:
<% ns:MyControl : /PathTo/Control %> <ns:MyControl _id=”myCtl” someAttribute=”someValue”> <p>paragraph</p> </ns:MyControl>
Don't forget, you must still define a server-side token for the control to be created in the code behind.
All server-side controls will be created in the form of a control tree, that matches with the nesting of elements in the XML view code (very much like ASP.NET). All text in the view code that is not part of a server-side control (not part of an element with a server-side token) will still be converted to server-side controls of type Literal, but will be much harder to manipulate in code behind (because they are not meant to be ;-)).
View variables:
A view variable is a variable that is set in the code behind and is printed in the view. A view variable is always identified by the first token $, followed by the variable name. The variable is located in the control class as either a field or property of the class, or a key in the Bag property. Bag is a simple dictionary that can be used to push key/value pairs to be used in the view.
Example valid view variables:
$label $person.Name $DateTime.Now $(company.Address.Street) $!statusMessage $F(DateTime.Now,dd MM yyyy)
View variables offer a lot of flexibility, see 6. View variables & using the Bag for more information.
When SASP parses a view file, it creates a special class for it. That class inherits from SasView?, and the source code for these classes can be found in the Temporary ASP.NET files folder of your .NET framework.
3.2 Default SASP controls
The following is the list of default controls that are available in the SASP framework, and the xhtml syntax that will get them created.
| XHTML | Control type | SASP specific xhtml? | Remarks |
| <Container /> | Container | yes | See 3.4 Container control |
| <ChildContent /> | ChildContent? | yes | See 8. Templates |
| <input type="submit|button|image|reset" /> | SasButton? | no | |
| <input type="checkbox" /> | SasCheckBox? | no | |
| <input type="radio" /> | SasRadioButton? | no | |
| <script /> | ScriptBlock? | no | |
| <anyothertag /> | HtmlControl? | no | |
| * | Literal | no |
Every xhtml element ofcourse assumes the presence of a server-side token before a matching control gets created.
3.3 Switching Views
A control can have a View file attached, but this is not required. If a matching View file is found, it will automatically attached to the control upon creation. It is possible to switch to another View file during the execution of your SasPage?. You can change the view of any control by calling the AttachView? member method. AttachView can take one or two parameters: the descriptor of the View file and a boolean specifying the control mapping behavior when switching views.
/// <summary> /// Attaches a view class to the current control, the view class represents /// an output template. /// </summary> /// <param name="viewPath">Relative path to the view file.</param> /// <param name="ignoreExistingControls"> /// True if the controls from the view should be used only as entirely new controls, /// and should not inherit properties or values from existing controls with the same /// id that are attached to the parent. Default behavior is that repeater and visibility /// settings of the current controls are copied to the new controls (value false). /// </param> protected internal void AttachView( string viewPath, bool ignoreExistingControls )
Example: See demo site 'Attach Views'
3.4 Container control
If you want to group controls together in a single block, you can use the Container control. Container is a transparent control that can be used in the standard way and can have attributes set, but it does not render any output except the output of the child controls it contains.
<Container id="registeredUser"> <table> <tr><td>Name</td><td>$user.Name</td></tr> <tr><td>Email</td><td>$user.Email</td></tr> <tr><td>Logged on</td><td>$user.LastLogon</td></tr> </table> There are currently $userCount users online. </Container>
3.5 Response headers
It is possible to specify custom response headers in the view file. This is useful if you wish for example a certain output to be sent as xml instead of normal html. A response header directive is of the form <%! NAME: VALUE %>. When attaching the view, all headers specified in the view file will be added to the response stream.
<%! Content-Type: text/xml %>
<%! Content-Encoding: utf-8 %>
<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0">
<channel>
<title>$Page.Title</title>
<link>http://$E(requestHost)$E(requestPath)</link>
</channel>
</rss>
The following is a list of default response headers in the view file:
- content-type
- content-encoding
- status
- status-code
- status-description
- redirect-location
- suppress-content
These will be set using matching properties of the .NET HttpResponse object. Custom headers are also allowed but will simply be added to the header list as strings.
Note: If you switch view in your code, the headers set by a previous view will remain unless explicitly reset by new directives or in code.
3.6 Using Templates
SASP has a page templating system that is very simple to use. A template is nothing but a regular custom control that inherits from SasTemplate? instead of the more generic SasControl?. The only other condition is that a template has a single ChildContent control where the content will be inserted. To attach a template to a page, you can use a simple attribute.
As an example, the following would be a valid template (/UserControls/Templates/MyTemplate.html):
<html>
<head><title>Hi there...</title></head>
<body>
<h4>This is the title...</h4>
<div class="inner">
<ChildContent _id="childContent" />
</div>
</body>
</html>
And you could attach it to a page in the following manner:
[Template("/Templates/MyTemplate")]
public class MyPage : SasPage
{
...
}
You can nest multiple templates and you can access templates from child controls or from the page, for more information see 8. Templates.
Example: See demo site 'Attach Templates'
3.7 Special attributes
The following is a list of control attributes that can be set in the view file, but will not be present in the control Attributes collection because they will be mapped to other properties if possible.
- id
- sid
- r
- repeater
- rSource
- repeaterSource
- item
