General Settings


November 26, 2008



While the formatted properties of the Open Web Studio control allow a user to display most content, in any way possible - there are a several restraints we like to apply for extending some of the usability of the interactive content. The majority of the basic options are included within the Default Properties region of the Administrative View Options. Aside from the sorting options, which can be displayed in any manner desired, the page selection, number of records per page, searching and alphabetic filtering are provided in a static layout at the top and bottom of the report whenever those options are enabled.

Paging Properties

Tip: While the options provided here are a bit restrictive in their display, it is key to use your own special technique whenever possible. If you don't like the page selection method, the search option method or the quick filtering - you can always use session variables within your queries to format the output as you desire. You can even use multiple Open Web Studio modules in combination to produce report and page selection manually. The possibilities are endless.

Records Per Page

To control the default number of records that appear on each page of the ows output, an integer can be placed in the "Records Per Page" form field. A non-numeric entry or an entry that is less than or equal to zero will cause all records to be  returned.

Show Records Per Page

This allows the designer to specify whether or not to allow the consumers of the ows to display a drop-down list selection for the number of records to show per page. The standard list of items are specified within the Ascx, and can manually be modified if necessary.  The default Records-Per-Page value will automatically be added to the standard records-per- page list. Checking this option will force the drop-down become visible, activating the related functionality.

Show Page Selection

When not operating in AJAX mode, the paging functionality can be hidden from view by leaving this box unchecked. If you would like the same capacity in AJAX mode you will need to check the box labeled “Ajax Interaction – Custom Paging”.

Use Custom Paging

Many table scenarios may be crossed in which the classic SQL paging mode, employed by default by ows, needs to be manually controlled. Manual Control means that, as the developer, you will handle datal selection for a specific page of records. This feature supports a much improved capability but requires know-how and understanding of database systems. For a complete breakdown of Custom Paging and examples of its use, check the chapter on Custom Paging

Filters and Sorting


Show Alphabetic Filter

Similar to the familiar alphabetic filter selections in many available products, we have provided a preformatted Alphabet for filtering your queries. Checking "Show Alphabetic filter" will force the letters to render and can be used in your query by specifying a valid SQL statement within the Filter Query.

Allow Multi-column Sorting

ows supports simultaneous sorting of multiple columns. Your first column may be sorted ascending while the last two are sorted descending. Leaving this value unchecked forces the list to allow only one column to sort at a time.

AJAX Integration


Enabling AJAX Interaction

The concept of requesting only a portion of data from the web server instead of requesting an entire page is not new, but it has become extremely popular lately. The best-of-breed technology on which this is based, called AJAX, refers to the blending of Javascript and the XML Http Request objects provided by the browser. Javascript creates and maintains the interaction with the server and the client so that the results can be integrated directly into the existing page. This greatly improves performance, especially with web applications like DotNetNuke because much of the overhead of rendering the page is unnecessary. ows provides a separate rendering engine, which can be paged easily and automatically handled through AJAX. It is important to note, up through version 1.5.2, AJAX supports only session variables for utilization. Form, QueryString (URL parameters) , and ViewState variables are not passed back using AJAX.

It is important to understand exactly how enabling ajax changes the functionality of your configuration. When using a standard post-back approach, all link and other interactive elements of your module would be passing information back and forth by submitting the entire page back to the server, and awaiting the (lengthy and slow) response. With AJAX enabled, all interaction for paging, sorting, and filtering are passed back to the server and only awaits changes to the specific module itself.

With AJAX enabled, the page load will occur, without actually retrieving any data from your configuration. The actions WILL execute, but the final binding will not occur because the idea is to limit the amount of data passed back and forth. You can disable entire blocks of code from executing on page load by adding a Region and configuring that Region to execute only on AJAX or PAGE LOAD, depending on your needs.

Once the page load is retrieved initially, the ajax request is made and the content is then loaded into the page for the specified module/configuration.

IF you need your content to be AJAX enabled, and yet SEO friendly, you MUST use the option labeled: Enable AJAX Interaction (Progressive Enhancement). With this enabled, the initial Page Load will load the content and bind the data. Paging, Sorting and Filtering will contain both SEO and non-SEO friendly functionality. When a browser (or spider) cannot execute Javascript, SEO friendly links are navigated. If AJAX is capable on the browser, than the non-SEO friendly links are followed. Therefore providing the best of both worlds.

When NOT to use AJAX

AJAX functionality works great in almost any scenario, barring a few identified structural requirements. Because the functionality issues a request on a separated XML HTTP object, the document received via the request, and the document displayed in the browser are two separate entities that have no direct correlation. This definition specifies that while you can easily pull content from one document and push it into another, which is essentially what AJAX is doing, you cannot parse certain document based objects, nor can you transmit objects that require custom transmission facilities.
What does this mean in English? While AJAX functionality can support nearly any content, it cannot support, or has limited support for specific tags that require extra, or integrated handling by the browser. The following tags are either ignored or have limited functionality in AJAX requests and should usually be avoided within AJAX enabled content:

<LINK> -  the standard embedded LINK functionality which will import the content of one URL into the current system. This link tag, not to be confused with the "A" or "Anchor" tag, is normally found in the HEAD section of an HTML page and is generally used for importing CSS Style sheets. This tag is unsupported in both IE and Firefox via AJAX requests.

<INPUT type=FILE> – when you need to transfer a file via the "Input type=file" HTML Element, the file body must be transferred via a form POST with Multi-part support. The AJAX library does not support the multi-part approach.  Because of this, files should not be transmitted via an AJAX postback. This tag is unsupported in both IE and Firefox via AJAX requests.

<STYLE> – inline style tags (styles defined within a tag Attribute like "style='color: #dddddd;'" work perfectly within AJAX. However, you CANNOT use the <STYLE></STYLE> tag structure for defining new classes or redefining classes in AJAX driven content. There are reports, however, that Firefox may support this directly and IE may support the <STYLE> tag if a Form element is present within the AJAX content.

<SCRIPT> - As of version 1.9.5 of ows, SCRIPT tags and SCRIPT SRC= tags are now supported. In this past this was not the case, however, advancements in the ows rendering engine and client-side runtime now provide this ability.

AJAX Interaction – Manual Load

The ability to force a module to load ONLY when another module specifically calls the AJAX functionality to load its source (lxFetch) is provided through this open. This is particularly useful when you have multiple entities which are displayed via a Toolbar. Clicking the Toolbar should both display your owsX module and execute the lxFetch function against this module.

AJAX Interaction – Custom Paging

If you are the ows AJAX Interaction, the default placement of the Page Links is displayed below the rendering area of the page, and below the standard Status region. If you prefer to locate the paging elsewhere on the page, or within the specified ows Item Formatting, the capability is handled quickly and easily through this setting. Check the box, and ows will no longer automatically render the paging functionality. Instead, it leaves the location and style up to you. To place the AJAX Paging elsewhere on the module, place a DIV tag defined similar to the minimal example below:

<div id=lxP[*ModuleID]></div>

AJAX Interaction – Custom Status

If you are using ows's AJAX Interaction, but do not like the location or look and feel of the default status messages, you can control the style and position of the status element by checking this box and including a DIV tag within your module format. To display the AJAX status elsewhere on the module, place a DIV tag similar to the minimum syntax example provided here:

<div id=lxS[*ModuleID]></div>




Javascript - Include Utilities Library

ows supports and provides a set of Utilities for using and maintaining your solutions. The Utilities library adds the ability to handle Expand, Collapse and Toggle  functionality as well as a variety of other functions.
See Client Scripts

Javascript - Include Validation Library

The default Validation libraries which are shipped with the .Net framework are not very versatile, and don’t properly support today's browsers. Use the Validation library to provide inline validation for your entities.
See Client Scripts

Javacript/Css Plugin Libraries

Open Web Studio supports the ability to add additional libraries for javascript and stylesheets that can be references by each module, and automatically added to the header of the page when utilized by a configuration. In recent versions, the JQuery and JQuery thickbox libraries where added and provided by this feature. Refer to the result of the Quickbuilder for a sample of how to use the provided libraries.

NOTE: When a Module Cache time is specified within the module settings, the reference will be written to the Header of the module, not the Header of the page. This is due to a limitation of the Caching login within DotNetNuke.

JQuery provides a rich interactive capability for quickly selecting, manipulating and animating objects within the DOM.

JQuery NoConflict is used, and required for versions of DNN prior to 5.1.1 (PE/CE) because JQuery replaces the javascript $ function, which is already implemented by DNN and breaks earlier versions. Referencing NoConflict changes the $ function call to $jq for JQuery.

JQuery Thickbox / JQuery Thickbox Stylesheet provide the ability to open a modal popup within the DOM. Refer to the Thickbox documentation, or the sample resulting from Quickbuilder.

To Add your own plugin css and js libraries you must embed the references into an openwebstudio.*.config file, which will appear in the root of your site instance. Once provided, they can then be selected to be used for each configuration and will register ONLY ONCE in the page head, regardless of how many OWS modules are referencing the same plugin library.

  1. Create or copy your libraries and place them in "/DesktopModules/OWS/Scripts"
  2. Create a file named openwebstudio.custom.config and save it in the root of the site.

    OpenWebStudio uses a plugin architecture that stacks all the openwebstudio.*.config files during the load and uses those to identify all available plugins including actions, formatters, tokens, queries, administrative UI plugins and standard UI plugins. In your case you are adding standard UI plugins and the body of your openwebstudio.custom.config file should look something like this:

    <ui name="myfile.whatever.script" type="Scripts/myscriptfiile.js" title="My FILE Script" />
    <ui name="" mime="text/css" type="Scripts/myscriptfile.css" title="My FILE STYLE" />
  3. Finally - save the file, and then restart the site. This will reload the openwebstudio.config files and include your changes. Now on any configuration that requires those to appear on the page you can do so by clicking the General Tab and checking the boxes in the Include region that will have the titles matching the ones you provided above!


Site Integration


Module Communication - Message Type

For better coverage and integration, ows provides the ability to broadcast messages for listeners to receive, identifying the current action taken by the ows Module. These messages consist of either Filter, PageSize, or the Current Page command.

Javascript Function – On Load Complete

When in AJAX mode, or when the page itself loads, it is important to know when the results have been posted to the page. Execution of a javascript function at this conclusion will aid in your goals. Place the Name of the function in the textbox. Upon load completion the specified javascript function will execute..

Display Query Debugging Information

When difficulties arise in the development, or error trapping of a specific module is needed it is always important to view the information that the module is interpreting. By checking this option, the resulting output will include six additional reporting divisions.

•    Actions – provides a complete readout of all the actions that were executed, including the diagnostic and debug results for each action.
•    AJAX Actions – provides the same list as the Actions, except it identifies which actions were executed during the AJAX request.
•    Original - provides the original query syntax before any translation occured. This helps you diagnose if the original statement was formulated correctly.
•    Actual - displays the post transformation of the query, the actual query text that will be executed against the connection to your database server. Any errors in this query will result in an empty result set, so it can easily be executed within other environments to determine the errors reported.
•    Exceptions - displays any fatal errors experienced by the runtime debugger which caused the executing query to fail. If AJAX is enabled this feature is not visible. To debug your statements, you may need to temporarily disable the AJAX paging features.
•    Runtime - the statistics of the tables returned, the number of records, the number of columns as well as the breakdown of the columns by name and type.  Additionally, the current Filter, Alphabetic Filter value, Sorting syntax Current Page, Page Size and Total records are also reported. If AJAX is enabled this feature is not visible. To debug your statements, you may need to temporarily disable the AJAX paging features.

Because the information returned from the debugger could pose a security risk as it may contain information or directives about your solution that could expose your handling and management of the data, ListX provides the ability to Hide and Show the debugging only to specific groups of users.

Dislay for All Users

The debugging information will be globally displayed to all users who are using module. This is generally helpful only if you need to diagnose a problem for Unauthenticated of Registered Users that does not occur with other security roles.
Display for Edit Users
All users who are granted Edit access to the Module via the Module Settings can view debugging information.

Display for Admin Users

Only Administrative users (users marked as Portal Administrators) can view the debugging information.

Display for Super Users

This is the recommended setting for the debugging when working and designing your configurations. Once complete, the setting should be turned off and debugging left disabled unless a problem occurs.

Trace (Log) all Interaction

Checking this option will place the familiar Debug information directly into the ListX Log. This should be used sparingly as it will generate a large amount of information in the log very quickly.

Trace (Log) when Query Fails

Checking this option will place the Query Failure information directly into the ListX Log. It is common place to turn this on in production mode, and leave this on to track any ill performing modules or special cases.

Skip Redirect Actions

Because at times it becomes difficult to debug the Actions that are executed within an action loop, when a redirect action is involved – this setting allows you to ignore the Redirect actions and remain on the same page after the actions conclude. This way, you can disable your redirects while debugging and re-enable them once the problem is rectified.

Skip Subquery Debugging

When you have debugging enabled and subquery debugging is not disabled, you will see a set of debugging panels for each execution of a subquery in that configuration. At times this becomes a nuisance and can be disabled by checking this option.


In order to maintain backwards compatibility with older versions of ListX modules which handle some parsing and other capabilities slightly differently, optional enhancements have been designated which *may or may not* cause backwards compatibility issues. In most cases, the standard user base has not achieved a level of complexity in which any of the options should be disabled, but at times, you may experience problems when these options are enabled.

Use Explicit System Variables

Using explicit system variables means, that when using a tag like [UserID] instead of the system designated value of [*UserID] or [UserID,System] the column value of the UserID will be returned. If the UserID is not available within the query, no result will be displayed. This means that any system variable will require the “,System” or * formatting. This is not a compatibility concern, but can cause problems if you did not create your configurations with this enabled, and later chose to enable it.

Enable Compound IIF Statements

Version 1.9 provided the ability to use compound mathematical and logic statements within the standard IIF tag. When enabled, the standard parsing logic is no longer used, and the new enhanced logic is employed. Certain configurations, specifically those with date formatted values may have issues with the new structure, because \ and / are division symbols. Support for this will be added in 2.0, and will no longer be a concern.

Use Advanced Parsing Techniques

Version 1.8 provided a new parsing technique, which is automatically used in every new configuration created after 1.8, and is hidden from view. When the version is less than 1.8, the checkbox is visible, and can safely be checked unless “Escaping” was required within the Queries contained in the configuration. Older versions had a flaw which required excessive escaping of symbols, regardless of depth.

Force Query Command Separation on GO

Not all DBMS applications support the GO command, or do not support the return of more than one table within each script execution. For example, if you want custom paging in ListX and use ORACLE as your database system, you could not return two tables due an ORACLE limitation. To support this, enabling the forced separation provides this capability For example in ORACLE:

SELECT ordered.*  FROM ( 		SELECT  ROWNUM as RowPosition,original.*  		FROM ( 			SELECT  *  			FROM MY_SOURCE_TABLE  			ORDER BY  [SORTTAG]	 		) original 	) ordered WHERE  	RowPosition BETWEEN  		(([PAGENUMBER]-1) * [PAGESIZE]) + 1 		and  		( [PAGENUMBER]    * [PAGESIZE])  GO  SELECT count(*)  FROM MY_SOURCE_TABLE

Average (4 Ratings):
Want to help out?

New York, NY • Baltimore, MD • Vienna, VA • St. Louis, MO • Seattle, WA •

Bookmark & Share Bookmark and Share