I have been up to my neck in Java and BPM stuff for a while, but nothing really exciting. So, since I haven't posted for a while, I thought I'd clean up an old .NET / WCI portal project I did and tell you guys about it.
The Story
The MooTools JavaScript library has an excellent set of validators that were developed by the guys at Clientcide. They are really elegant in both implementation and presentation. Once you load the MooTools library on the page, and add one line of JavaScript, you just add a class name for the validator you wish to use to the HTML form item you want to validate and BAM! that's it. If you want it to look pretty, just add a stylesheet. All of the effects are controlled through styles.
Here is a quick example to give you an idea: ( show code )
<link rel="stylesheet" type="text/css" href="http://www.floydwalker.com/files/MooControls/Demonstation.css" />
<script src="http://www.floydwalker.com/files/MooControls/clientcide-trunk-622.js" type="text/javascript"></script>
<form id="myForm" name="myForm" target="_self" action="SmallDemo.htm">
<script type="text/javascript">
function bodyOnLoad() {
var oFormValidator = new FormValidator('myForm');
}
</script>
Required: <input class="required" id="MooTextBoxDemo1" name="MooTextBoxDemo1" />
<br />
Numeric: <input class="required validate-numeric" id="MooTextBoxDemo2" name="MooTextBoxDemo2" />
<br />
<input id="btSubmit" type="submit" value="Submit" name="btSubmit" />
</form>
<img src="http://www.floydwalker.com/files/MooControls/Blank.gif" border="0" style="display: none" onload="bodyOnLoad();"/>
More information about these validators can be found at the mootools.net site. Note
Note: These user controls were made with a dated version of MooTools. And, the validators at that time had not yet been integrated into MooTools. They were still being managed by CNet / Clientcide. If I get some time, and I think it's interesting enough, I'll update it to the latest version.
Now every good web developer should know by now that you can't rely on just JavaScript to insure you get valid data to the server. Plenty of people know how to hack the systems to submit unwanted data. That is where these custom .NET User Controls come in.
The MooControls complement the MooTools validators to insure that data validated on the client (with the MooTools validators) gets validated again on the server to insure data consistency. And, if the validation fails on the server, the form appears in the browser again just like it would if it failed the JavaScript validators. The user gets the flashy validators. The server is confident that it gets good data. And, the developer doesn't need to sweat about the details of the arrangement. Everybody wins!
In The Portal
While these controls work great in a standard ASP.NET web application, they are really designed specifically to run in an Oracle Web Center Interaction (WCI) portal.
Designing portlets for a WCI (aka. Aqualogic User Interaction (ALUI), aka. Plumtree) can be a bit daunting for junior developers. The Oracle .NET Application Accellerator makes things a bit easier by capturing post-backs and updating the portlet in-place. But, if you want to do fancy AJAX stuff like some of the MooControls do, then things get dicey. The Microsoft AJAX controls just don't play well with WCI.
The MooControls, combined with the Oracle WebCenter Application Accelerator for .NET makes creating nice, form-based WCI portlets much easier. Plus, there are a few tricks it can do to really make the portlets pop.
Don't have a WCI portal? Don't worry; the MooControls work fine in a regular ASP.NET application. One nice feature of the MooControls is that it can detect whether or not the application is being hosted in a portal or not. This makes debugging the UI outside of the portal a little easier.
The Controls
Each MooControl is a derivation of one of the standard .NET WebControls you are probably already know and love. The next table shows a list of the MooControls. The names of the controls and their base class should tell you what they do. If you need more information, check this page for details on each control and their attributes, methods and behaviors.
| MooControl | ASP.NET Base Control |
| Simple Controls |
| MooFormValidator | System.Web.UI.WebControls.WebControl |
| MooCheckBox | System.Web.UI.WebControls.CheckBox |
| MooDateTextBox | System.Web.UI.WebControls.TextBox |
| MooDropDownList | System.Web.UI.WebControls.DropDownList |
| MooRadioButtonList | System.Web.UI.WebControls.RadioButtonList |
| MooTextBox | System.Web.UI.WebControls.TextBox |
| MooButton | System.Web.UI.WebControls.Button |
| MooLinkButton | System.Web.UI.WebControls.LinkButton |
Complex Controls
|
| MooGridView | System.Web.UI.WebControls.GridView |
| MooPopupView | System.Web.UI.WebControls.Panel |
Portal-Specific Controls
|
| MooPT | System.Web.UI.WebControls.WebControl |
| MooPTImage | System.Web.UI.WebControls.Image |
| MooPopupPortletContainer | System.Web.UI.WebControls.WebControl |
The MooControls and their ASP.NET Base Class Controls
First, the MooFormValidator control tells ASP.NET how and when to load the MooTools JavaScript library onto the form. It will initialize the JavaScript object and control all of your MooControls on the form. Consequently, you will need one of these guys on each form you use a MooControl.
The other "Simple Controls" behave exactly like their base control counterparts. They even appear in the ASP.NET Toolbox and look nice in the "Design" and "Split" views of the Visual Studio IDE.
To begin using the validator functions of the MooControls, you just need to specify two attributes:
- The "MooFormValidatorID" needs to contain the Id given to the MooFormValidator control on the form you want the control to be asscociated with. (Yes, you can have more than one for a form.)
- Type one or more validator names from this list into the "ValidatorTests" attribute. The validator names should be separated by a singe space.
- required Displays an error if the field is empty.
- minLength Displays a message if the input value is less than the supplied length.
- maxLength Displays a message if the input value is more than the supplied length.
- minValue Displays a message if the input value is less than the supplied value.
- maxValue Displays a message if the input value is more than the supplied value.
- minDate Displays a message if the input value is less than the supplied date.
- maxDate Displays a message if the input value is more than the supplied date.
- validate-numeric Validates that the entry is a number.
- validate-digits Validates that the entry contains only numbers
- validate-alpha Validates that the entry contains only letters
- validate-alphanum Validates that the entry is letters and numbers only
- validate-date Validates that the entry parses to a date.
- validate-email Validates that the entry is a valid email address.
- validate-url Validates that the entry is a valid url
- validate-date-au Validates that the entry matches dd/mm/yyyy.
- validate-currency-dollar
- validate-one-required Validates that all the entries within the same node are not empty.
- validate-fedid Validates that the entry is a valid Federal Tax ID or SSN.
The MooButton and MooLinkButton have been modified to insure that the client side MooTools validators validate the controls before executing their server side event code.
Dependent Controls
I implemented in the MooControls the idea of dependent controls. What this means is you can have a set of MooControls that are dependent upon one MooControl. These dependent controls either appear/disappear, enable/disable, validate/don't validate based upon the value of the master control.
This is useful for forms where you need additional information if a user selects a certain radio button or checkbox, or even puts a large value in a numeric textbox. Of course, you need to provide the test in JavaScript (for the browser) and then again on the server (in server side code). See the example project in the download if you want to see how it's done. It's really not that complicated.
Example use case: (Click on the "Yes" and "No" radio buttons.)
You don't want the "Please Explain" prompt to appear unless the user specifies "Yes" in the master MooRadioButtonList. The "Please Explain" label and associated MooTextBox are in a DIV element that specifies the container for the dependent controls. When the dependent controls are not visible, their validators are not active.
Other Features
The MooControls has a really neat date entry control in the MooDateTextBox (thanks to MooTools). It has really good date entry, selection, and validation. Plus, you can specify date range validation.

MooDateBox Sample
The MooTextBox control can insure you provide a specific number or a range in the number of characters entered. If it is a numeric MooTextBox, you can insure that the number is in a specified range.
These ranges and validators can be added, removed, turned off or on, in the client-side (JavaScript) code. You can specify where you want the validation messages to appear. You can change the validation text if you want. Custom validators aren't too difficult to create, especially if you know regular expression syntax (not required) and rudimentary JavaScript.
All of these features are demonstrated and documented in the sample project in the download.
The Complex Controls
The MooGridView control works like the out-of-the-box GridView conrol. But, it has a few extras added to allow the user to create a grid of MooControls. This is useful if you need to collect a series of zero or more instances of a data type. Say you need to have the user enter the beginning and ending employment dates and the name of the employer. Each row begins with a checkbox (for row selection), then two MooDateBox controls and a MooTextBox control, each with their own validators. At the bottom of the MooGridView is two buttons: "Add" and "Delete". This allows the user to add and remove rows in the collection.

MooGridView Sample
The MooGridView manages the dynamic creation and removal of the MooControls contained within the rows of the grid. The developer just needs to drop the controls in a template row, and bind them to the data source correctly. An example is in the download.

MooPopupView Sample
Next, the MooPopupView is just low-hanging fruit. MooTools provides what they call a StickyWin control. It is a very customizable modal DHTML window which can appear and disappear based on user interaction. Every bit of HTML that appears within the start and end tags of the MooPopupView control will appear inside a StickyWin window. It will appear as a modal, draggable window. The rest of the page will be "greyed-out" and disabled. And, the developer gets to select the buttons that appear at the bottom of the StickyWin. See the download project for an example and documentation.
The WCI Portal Controls
If you are going to use the MooControls in a WCI portlet, the MooPT control should be on every page that is hosted in a portlet. First, it detects whether or not the browser request is coming from the portal, or straight from the browser, then changes the script path accordingly. This is wonderful if you need to test your portlet outside of the portal a bit. When it is in the portal, it gets the MooTools JavaScript files from the Image Server. Otherwise, it will look for the files in the web application.
The second thing it does is drop the "pt:token" tag on the page, so you can make all of the names and Id's in the portlet page unique.
The MooPTImage tag behaves like the out-of-the-box Image control when the page request comes directly from the browser. But, if it comes from the portal's gateway, it will put the "pt://images/" prefix in front of the image URL. This insures that your images are served from the Image Server when the portlet is deployed. And, if you want to test your page outside of the portal, you don't need to change the URL's of your images.
The last of the portal MooControls is the MooPopupPortletContainer control. This control is also the most complex of them all. Setting it up requires a bit of orchestration. But once operational, the effect can be quite cool.
Here is the idea. You have one portlet on a portal page. In that portlet, you have a link or button that when pressed causes a form to appear in a modal style like the MooTools StickyWin or MooPopupView control. The difference is, post-backs occur in-place inside the modal window. When finished, the user clicks a button on the form, it posts-back to save the form data, then the modal window goes away and sends a result back to the parent portlet.
This is done by having a portlet page with the MooPopupPortletContainer in it. The control causes the portlet to disappear from the portal page. When a specific JavaScript function is called, the invisible portlet loads an ASPX page, becomes visible and changes it's dimensions so that it becomes a MooTools StickyWin. The Oracle WebCenter Application Accelerator for .NET handles the rest. When done, another JavaScript function is called, and MooPopupPortletContainer returns to its original, invisible state.
The End?
I am not actively maintaining this library. But, I did have a great deal of fun developing it. I really should update them to support some of the great things in the latest version of MooTools. Perhaps if I get really bored one day… I thought it was a really good idea. Especially since I really hate the out-of-the-box validators that Microsoft gave us with ASP.NET. And, the MooTools validators are very pretty.
I have included a demonstration project with the download. It not only shows you how to use the controls, but also contains a bit of documentation as well. Here they are, for your enjoyment:
Download MooControls for the WCI Portal (requires the Oracle WebCenter Interaction Development Kit (IDK) and the Oracle WebCenter Application Accelerator for .NET)
Download MooControls for regular ASP.NET development. (WCI Portal controls and features are disabled)