To make your solutions truly interactive, you’ll want to start using Javascript in your XMod Pro applications. Whether it’s using a third party library or custom functions you’ve written, XMod Pro makes it easy to include interactivity via Javascript.
Once you get comfortable with the basics in XMod Pro - creating forms, displaying data, etc., you often want to take the next step and add some client-side interactivity. The tool for that is typically Javascript. Thankfully, XMod Pro makes it easy to use Javascript in various places within your solution. I'll talk about the tools XMod Pro offers that make your Javascripting life easier.
Plain Javascript
XMod Pro makes using Javascript within your forms and templates easy. Just type it in. You can place Javascript almost anywhere in XMod Pro. If that portion of the template or form is rendered at run-time, then your Javascript will execute.
<script>document.write("hello world");</script>
Injecting Javascript Functions and Libraries
Often, you need to make your functions available throughout the page or you need to use the functions in one of your Javascript libraries or a third party library. For these situations, XMod Pro uses the <ScriptBlock> tag (in forms) and <xmod:ScriptBlock> tag (in templates). Other than the tag name, these two tags are functionally the same. The example below can be placed in your template - outside an <xmod:template> tag. It could also be placed inside a <HeaderTemplate> or similar tag. However, this method ensures the block will be injected into the page, regardless of whether there are any records to display.
<xmod:scriptblock scriptid="AlertScripts" registeronce="true" blocktype="HeadScript">
<script language="javascript">
function helloWorld(){
alert('Hello World');
}
</script>
</xmod:scriptblock>
<table width="100%">
<tr>
<td width="250" valign="top">
<!-- SCRIPT BLOCK EXAMPLE -->
<a href="#" onclick="helloWorld();">Hello World</a>
</td>
</tr>
</table>
In the example above, we've injected a script block with a function named helloWorld in the HEAD area of the page because we specified a BlockType of "HeadScript". This ensures the function will be available to script in the rest of the page. Note that even though the ScriptBlock tag is next to the TABLE tag in the template, when it is rendered out to the page at run-time, the script will be placed in the HEAD while the TABLE will be rendered where the XMod Pro module is on the page.
XMod Pro's ScriptBlock tags also give you the ability to inject your script into other parts of the page. The "ClientScript" block type will insert it after the BODY tag (and after ASP.NET's FORM tag) near the top of the page. In most cases, the ClientScript block type is the best choice of the three. It is typically inserted early enough in the page so that any calls you make to those functions from within XMod Pro will work.
The "StartupScript" block type will insert it near the bottom of the page but before the closing /BODY tag. If you want some Javascript to execute after the page is loaded, try using the "StartupScript" block type. This type of positioning is good because most Javascript has been inserted into the page and the HTML has been written to the page by the time the browser processes your script. This gives you the opportunity to perform calculations based on data returned in a grid, for instance or to set some defaults in the a form, etc.
Attaching to An Event
Many times you’ll need to react to a client-side event that has been raised by an XMod Pro control. The most common example is confirming the user wants to delete a record.
<xmod:DeleteButton OnClientClick="return confirm(‘Delete this record?’);" Text="Delete" />
When the user clicks the button, the Javascript ‘confirm’ function is called, prompting the user to click OK to confirm the record deletion or Cancel to cancel the operation. It’s important to return a value or true or false in cases like this. If false is returned, the page will not post back to the server and the record will not be deleted. If true is returned, the processing will continue as normal and, in this case, the record will be deleted. If you forget to return a value, you may end up deleting a record even if the user clicks Cancel, so remember to return the correct value.
Combining Text and Field Values with [[Join()]]
Now, let’s say you want to pass a field value to your Javascript function. For this you need to use the [[Join()]] function token. It allows you to merge field values with text and other token values.
<xmod:DeleteButton ... OnClientClick='[[Join("myFunction(""{0}"");", [[CompanyName]])]]' ...
There are a number of things happening in the above snippet:
- Since we're using a token, we have to delimit the OnClientClick attribute with single quotes (') instead of double-quotes (")
- Javascript is just text until it's interpreted by the browser, so we pass the Javascript call in as the Input to the Join function (the first parameter). Within the Javascript text, we use numbered placeholders (starting with zero) which correspond with the additional parameters we pass to the function. In this case, we just have one parameter, but we could have two or three or more. At run-time, the {0} will be replaced by the value of the CompanyName column.
- For the sake of this example, let's say the myFunction function expects a text value, so we have to delimit it with quotes. However, since we're delimiting the OnClientClick attribute with single quotes, we have to use double quotes. The problem, though, is that we're also using the double quotes to delimit the Join function. What to do? We have to escape the double quotes by typing two consecutive double quote characters for each individual double quote character we need.
Getting Form Control Client ID's
If you're using Javascript in your forms, you'll more than likely need to access the controls on the form from within your script. You'll quickly discover, though, that the ID value you use for your control in XMod Pro, doesn't match the ID that is rendered in the final HTML source code. ASP.NET works to ensure that ID's in the final page are unique within the page. So, it takes your ID and generates a long, but unique ID to use in the browser.
While it's nice ASP.NET helps keep your code HTML compliant, all that re-naming ends up making it very difficult to write client-side script that uses those ID's. Well, XMod Pro has your back. The AddForm and EditForm tags each have an attribute called ClientName. Create a unique value and place it in this attribute. Then you can access your form controls with simple dot-notation:
<AddForm ClientName="MyUniqueId">
...
<TextBox ID="txtFirstName" .../>
...
<a href="#" onclick="alert(document.getElementById(MyUniqueId.txtFirstName).value;return false;">Click Me</a>
...
</AddForm>
Ah, but wait... What if you are using a couple of FormView modules, each of which uses the SAME form. Your ClientName will no longer be unique in the page. It's not a likely scenario, but you can still pull it off. Use the [[Module:ID]] token and the [[Join()]] function to ensure uniqueness in the page:
<AddForm ClientName='[[Join("MyUniqueId{0}", [[Module:ID]])'>
...
</AddForm>