The overall structure of Open Web Studio is handled in two halves. The first is provided through the logic of the Actions
. Use the Actions
tab (also present at the top of this articles) to review the available actions. Actions are used to handle all sorts of functionality, and can be expanded to support a limitless future set of capabilities.
The other half of the logic, also assigned here as a Template Action is the idea that - your actions are producing a general template that is yet to be bound to a query. This is known as the Template. Templates consist of three different types of structure, Query, Headers and Footers or Details (with or without a query or results). You can pick between this types at the top of the property selection for the action.
Open Web Studio can bind to any available data, as long as it can execute the statement against your source server. Since the source server is anticipated as SQL Server, Open Web Studio is capable of doing more than a simple selection - in fact, you can have entire conditional statements as well as stored procedures, functions and other extended T-SQL features. To create a query, simply enter the query within the provided property structure.
Whenever you have a Query template in the process of binding to the Action_Template (Detail Template). You can retrieve a column value for each row just by entering that value within left "[" and right "]" brackets. For example, lets say you are selecting data out of a table full of User information. [Username] can be used to get the data out of the "Username" column. Far more information is provided on this within the Columns and Values topic.
The statement can utilize any number of Session, Query String, Form and ViewState variables, and also a few added system variables for convenience. However, whenever using values within your query, your should always consume the values through the Template Variables. This is for security reasons, as well as reducing the complexity of the required statement. PLEASE PAY CLOSE ATTENTION TO THE SECURITY CONCERNS REVIEWED THERE.
The physical handling of the Query execution begins with translating the Query Variables within the SQL Query Statement. Once completed, the next step is to identify and transform any of the runtime variables which occur within the Statement. These variables provide the true meat of the interaction, handling the filtering and sorting of the control.
Provided below, the breakdown and usage of the Runtime variables:
• [FILTERTAG] - renders a fully qualified filter fragment for your query, this item is necessary for any of the custom filtering options. The FilterTag should always follow or be contained within a WHERE clause.
• [FILTER] - renders the specific letter selected in the alphabetic filter selection.
• [SORTTAG] - renders the complete sorting statement fragment. This statement provides a list, comma delimited, of the columns sort enabled within you list. The order of each of these columns is handled via the interaction, and can be forced to allow multi-column sorting, or single column.
The default operation of SORTTAG is to automatically return 1, representing the ordinal position of the first column in your result when no sort is yet assigned. There are problems with this syntax during specific situations. For example, when using Custom Paging for SQL 2005 you cannot use an ordinal here because column positions are not allowed in Windowed Functions. Essentially, because no columns have yet been returned, SQL is unable to sort on that column. To work around this problem, and also to control the default sorting SORTTAG has an additional functional consideration.
[SORTTAG,optional default sort] – when this is used, you may specify the default column name to use for the sort. For instance – [SORTTAG,TabID]. If no sort has yet been defined, TabID will be the default value. Refer to the Custom Paging examples for this scenario.
The following example, used later to demonstrate interaction with the DotNetNuke EventLog utilizes both of the Runtime Variables:
FROM EventLog l
JOIN EventLogTypes elt
ON elt.LogTypeKey = l.LogTypeKey
ORDER BY [SORTTAG]
For information on Custom Connections to your external data.
For information on Custom Paging with a query.
Providing a Microsoft Access Style report formatting engine, capable of building extremely complex hierarchical formatted output is made easy through the Template Actions for Header/Footer/Details. Think of these as ways of grouping your data, whether it is general header and footer (top and bottom of a grid) surrounding your physical data, or a header/footer combination that changes whenever a specific column value changes. Tip: You can be extremely creative with you formatting because of the rendering behavior of Open Web Studio. As Open Web Studio renders its output, it loops through the list of columns provided in the data result, replacing occurrences within your List Formats with the values in the columns. You can have completely dynamic result structures by placing occurrences of Column Values within the results, therefore nesting one inside another. This is particularly useful in instances where you display is dynamically based on parameters you are passing in to your SQL. Keep in mind, the columns are replaced in the order which they occur, so when you attempt this behavior only columns occurring after the nested column can be replaced within the nesting.
To provide the ability to repeat bounding headers and footers based on changes in columns, you must add new Template Header and Footer Actions and control the order of these groups through the attribute setting for the index.
Some extremely specialized syntax is included in the rendering process for handling all type of interaction with the Open Web Studio
module. From just simple Column Values and formatting, through Sorting, Check and Radio lists and Actionable items, follow the links and descriptions provided below to gather understanding on each of these features, and are discussed throughout the wiki. Refer to the Columns and Values
topic. Place the content within this region that you will be using to display the content. This can be of any format, but generally the output is HTML, so standard HTML syntax is available to use here. Refer to the Editor
for futher information.
The Group statement is similar to the usage of the Header, Footer and Detail values in regards to the replaceable Column Values. Upon iteration of each record in the resulting table, the Groups are checked in their hierarchy based on the formatted Group Statement. If the resulting value of the Group Statement changes, the Headers and Footers for the Group in question, and its sub-groups will render. Group statements are not visible to the actual user, and are only used for this purpose. Since the Header and Footer in question can be extremely large, it is far more efficient to detect changes in a relatively short value rather than a large one. In the example above, we are checking whether the Column Value for MainGroup or SiteGroup have changed. The Header and Footer may contain many other formatted Column Values, but only when either of those columns change will the Header/Footer combinations be rendered. YOU SHOULD ALWAYS MATCH YOUR HEADER AND FOOTER INDEX AND GROUP STATEMENT FOR PROPER LAYOUT.
Group Index plays vital role in sub groups to be executed in query template layout. Group Index can be either alphabetic or numeric but always recommended to use numeric values starting with 0. Every header may have respective footer. And position of the header within query template will not affect the results. Example: For a Main Header having one group: Main header index starts with 0 and subgroup (repeated group) index should be 1.
The Detail template is the physical content to display on a record by record basis. Groups generally are produced just prior to rendering each record (whenever the groups are changed based on the Group Statement). For example. Your may be providing a simple table layout where you will have a header with the column titles, and a footer to end the table. Provided between the header and footer is all the record content. To do this, you just need the following:
Template Header (Index 0):
Template Footer (Index 0):
When an alternating format is desired - place the alternate format within this detail type.
The Default Item utilizes that standard syntax parameters of Header, Footer and Detail - however, it is only displayed when the bound data source contained no records. If you want to hide the module completely whenever no results are returned from the query, check the Hide Module box.
The Default Item utilizes that standard syntax parameters of Header, Footer and Detail - however, it is only displayed when the bound data source contained no records and the Query was not defined, or resulted in an empty string. If you want to hide the module completely whenever the query is empty – press the Hide Module checkbox.