ComponentArt

MaskedInput Transform Intellisense

Jovan — Mon, 27 Oct 2008 14:06:00 GMT

MaskedInput class's Transform property that I described in depth in a few preceding blog posts presented us with an interesting design dilemma. At first it seemed like it should be a typical enumeration property, with one value for each Transform type. However, since the architecture allowed new Transform types to be added in a number of different ways (see the previous blog posts), the enum turned out to be too stifling. For that reason, we opted for a string instead.

However, we still wanted to offer some Intellisense, to give the developer a hint at the values he would most likely want to use. We did it by placing the TypeConverterAttribute on the Transform property:

public sealed class MaskedInput : BaseInput
{
  ...
  [TypeConverter(typeof(MaskedInputTransformConverter))]
  public string Transform
  {
    get {...}
    set {...}
  }
  ...
}

The implementation of MaskedInputTransformConverter is very simple:

/// <summary>
/// Provides Visual Studio intellisense for Transform property.
/// The list of StandardValues here corresponds to the properties of client-side ComponentArt_MaskedInput_Transforms object.
/// </summary>
public class MaskedInputTransformConverter : TypeConverter
{
  public string[] StandardValues =
  {
    "empty", 
    "CreditCard_VisaMasterCard",
    "CreditCard_AmEx",
    "Telephone_NorthAmerica",
    "ZipCode",
    "PostalCode",
    "PostalCode_Australia",
    "EmailAddress"
  };
  public override StandardValuesCollection GetStandardValues(ITypeDescriptorContext context)
  {
    return new StandardValuesCollection(StandardValues);
  }
  public override bool GetStandardValuesSupported(ITypeDescriptorContext context)
  {
    return true;
  }
}

This works really well in ASPX Intellisense, popping up the list of standard values, without forcing you to use one of them - exactly the behaviour we needed. The Intellisense also works for the Properties pane. Unfortunately it does not work in the CodeBehind files, and I don’t think there is a way to implement it there.

Share this post: email it! | bookmark it! | digg it! | reddit!

Building in new MaskedInput Transforms

Jovan — Fri, 24 Oct 2008 14:05:00 GMT

In the previous post I explained how you can customize the behaviour of MaskedInput’s Transforms. That should probably cover all your needs. However, MaskedInput’s architecture does allow for one more way to customize transforms. You can actually build in your own.

As you can see from the MaskedInput_Transforms.js file attached in the previous post, all the built-in transforms are contained in a global JavaScript object named ComponentArt_MaskedInput_Transforms, indexed by Transform name. So building in a new Transform is as easy as adding another property to ComponentArt_MaskedInput_Transforms. You can do that in a few ways:

You can completely redefine the object ComponentArt_MaskedInput_Transforms:

 <script type="text/javascript">
   window.ComponentArt_MaskedInput_Transforms =
   {
     'UpperCaseInput':
     {
       'validate': function(maskedInput) {return true;},
       'unmask': function(maskedInput) {return maskedInput.masked.value.toUpperCase();},
       'mask': function(maskedInput) {return maskedInput.unmasked.value.toUpperCase();}
     }
   }
 </script>
 <ComponentArt:MaskedInput runat="server" ID="MaskedInput1"
   Transform="UpperCaseInput"
 />

Keep in mind that because you are overwriting ComponentArt_MaskedInput_Transforms, the built-in transforms will no longer work.

A less drastic solution is to just add your new Transform to the existing ones:

 <ComponentArt:MaskedInput runat="server" ID="MyMaskedInput" />
 <script type="text/javascript">
   window.ComponentArt_MaskedInput_Transforms.UpperCaseInput =
   {
     'validate': function(maskedInput) {return true;},
     'unmask': function(maskedInput) {return maskedInput.masked.value.toUpperCase();},
     'mask': function(maskedInput) {return maskedInput.unmasked.value.toUpperCase();}
   }
   window.MyMaskedInput.set_transform('UpperCaseInput');
 </script>

If you have a source code license and are compiling your own custom builds, you can easily add your transforms directly to the JavaScript file. They will then work just like the original built-in transforms.
If you are doing this, you may also want to extend MaskedInput Transform Intellisense, as described in the next blog post.

Share this post: email it! | bookmark it! | digg it! | reddit!

Customizing MaskedInput Transforms

Jovan — Thu, 23 Oct 2008 13:30:00 GMT

In this blog post I will assume that you understand how MaskedInput Transforms function. It was explained in the previous blog post.

Here is the list of currently implemented transforms:

CreditCard_VisaMasterCard - Visa or MasterCard credit card number.
CreditCard_AmEx - American Express credit card number.
Telephone_NorthAmerica - North American telephone number.
ZipCode - American ZIP code.
PostalCode - Canadian postal code.
PostalCode_Australia - Australian postal code.
EmailAddress - e-mail address.
empty - accepts all inputs.

empty Transform is a special case. It accepts all inputs, and it doesn't mask or unmask them. Here is how it looks in code:

 'empty':
 {
   'validate': function(maskedInput)
   {
     // Accept all input:
     return true;
   },
   'unmask': function(maskedInput)
   {
     // Just pass on the edited displayed text:
     return maskedInput.masked.value;
   },
   'mask': function(maskedInput)
   {
     // Just pass on the unmasked value:
     return maskedInput.unmasked.value;
   }
 }

There is not enough space in this blog post to show the code of the rest of the Transforms, but I made the source code file available for download.

Ideally the available transforms will be enough for your requirements. New transforms are very easy to build in, so please don't hesitate to send in your suggestions.

However, for those times when your requirements cannot be met by the built-in transforms, there are a number of ways to customize the MaskedInput.

In addition to Transform, MaskedInput exposes three more server-side properties: TransformValidate, TransformUnmask, and TransformMask. These allow you to override the behaviour of any of the three transform functions. For example, to make the Visa card transform featured in the previous blog post mask with dashes instead of masking with spaces, you can do something like this:

 <script type="text/javascript">
   function maskVisaWithDashes(maskedInput)
   {
     return maskedInput.unmasked.value.replace(/^(\d{4})(\d{4})(\d{4})(\d{4})$/, '$1-$2-$3-$4');
   }
 </script>
 <ComponentArt:MaskedInput runat="server" ID="MyMaskedInput"
   Transform="CreditCard_VisaMasterCard"
   TransformMask="maskVisaWithDashes"
 />

This allows you to fully override any of the Transform's functions. Note that you can also leave the Transform property blank. In that case, the control defaults to the empty transform.

In the next blog post, I will introduce another more integrated way to add a new Transform.

Share this post: email it! | bookmark it! | digg it! | reddit!

MaskedInput Transform functionality

Jovan — Wed, 22 Oct 2008 14:06:00 GMT

The format of the masked input is fully defined by the "Transform" it uses.

A Transform is a client-side JavaScript object containing just three functions:

validate – A function that takes a look at what the user just typed into the masked input box, and returns a boolean value: true if text is valid, false if it isn't.
For example, if the transform is used to accept a Visa card number, and the user types in "4506/00020002-0002", this function returns true. (It just makes sure that there are exactly 16 digits.) If the user types in "2008-10-14", the function returns false.
unmask – A function that takes a look at what the user has just typed into the input box, and "unmasks" it. Typically, this means that the text is cleaned of formatting, leaving behind just the raw data. Unmask gets called even when validate does not return true, so it should not assume that the masked text it is working on is valid.
In our example, if the user typed in "4506/00020002-0002", this function will return "4506000200020002".
mask – A function that takes a look at the raw, clean data, and "masks" it: formats it for display.
With our raw data being "4506000200020002", this function will return "4506 0002 0002 0002".

Each of these methods takes only one argument: the reference to the client-side MaskedInput JavaScript object. The function can then easily use this object to get any other information it needs. For example, here is the entire code of the Visa card transform:

 'CreditCard_VisaMasterCard':
 {
   'validate': function(maskedInput)
   {
     // Ensure the unmasked edited text has exactly 16 digits:
     return this.unmask(maskedInput).length === 16;
   },
   'unmask': function(maskedInput)
   {
     // Simply remove all the non-digits from the displayed text:
     return maskedInput.masked.value.replace(/[^\d]/g, '');
   },
   'mask': function(maskedInput)
   {
     // Insert spaces between four-digit groups:
     return maskedInput.unmasked.value.replace(/^(\d{4})(\d{4})(\d{4})(\d{4})$/, '$1 $2 $3 $4');
   }
 }

Two often used properties of the client-side MaskedInput object are maskedInput.masked and maskedInput.unmasked:

maskedInput.masked refers to the display textbox element that the user sees and edits. It contains the masked text.
Although the masked text is typically not examined on the server, it can be accessed as MaskedInput's DisplayText property.
maskedInput.unmasked refers to a hidden input that contains the unmasked text.
The unmasked text is often examined or manipulated on the server, where it can be accessed as MaskedInput's Text property.

Hopefully it is now clear how Transforms function. In the next blog post I will explain how you can customize them.

Share this post: email it! | bookmark it! | digg it! | reddit!

Major input control Gotcha

Jovan — Tue, 14 Oct 2008 15:17:00 GMT

Short Story:

This will not work:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="MyNumberInput.decreaseValue();" />

This is how to correct it:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="window.MyNumberInput.increaseValue();" />
<input type="button" value="-" onclick="window.MyNumberInput.decreaseValue();" />

Long Story:

This will work:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="increase();" />
<script type="text/javascript">
  function increase()
  {
    MyNumberInput.increaseValue();
  }
</script>

But, as mentioned before, this:

<ComponentArt:NumberInput runat="server" ID="MyNumberInput" />
<input type="button" value="+" onclick="MyNumberInput.increaseValue();"/>

will instead produce a JavaScript error: MyNumberInput.increaseValue is not a function

But isn't that the exact same code?? What is going on?

It turns out that in the second case "MyNumberInput" is not referring to the client-side NumberInput object. Instead it is referring to a DOM element of the same name.

Like most ComponentArt controls, input controls create a number of client-side DOM elements and JavaScript objects.
In this particular example, with a NumberInput named MyNumberInput:
In JavaScript, the most important object is named MyNumberInput, and is an instance of client-side class ComponentArt.Web.UI.NumberInput.
In the DOM, there are a number of different elements, including a text input with the id MyNumberInput.

This results in a very unusual naming conflict. Normally, when you write MyNumberInput in client-side code, you expect it to refer to the global JavaScript object of that name. And it does. Except when the code is running in the event handler of an HTML tag. Then MyNumberInput refers to the DOM element with that id. Which is probably not what you want.

To avoid ambiguity, you can use window.MyNumberInput to refer to the JavaScript object, and document.getElementById('MyNumberInput') to refer to the DOM element.

So why don’t we fix this? Well, it turns out that there is no real bug here.
First of all, this is not a design that is unique to ComponentArt input controls. In fact, most ComponentArt controls produce JavaScript objects and DOM elements with matching identifiers, for a number of reasons. What is different with input controls is that the DOM element in question happens to be a form element. This triggers the naming conflict.
However, having these matching identifiers turns out to be needed for the input controls to work smoothly with ASP.NET’s client-side validation, which is a very important feature.
So it is unlikely that we will be able to "fix" this. Instead, just please keep this gotcha in mind.

Share this post: email it! | bookmark it! | digg it! | reddit!

Web.UI 2008.2 Grid News: Grouping

Milos — Tue, 23 Sep 2008 18:34:00 GMT

Now that Web.UI 2008.2 is officially out the door, I can take some time to sit back and reflect on what's been done. There are some great new controls, as usual, and major enhancements to our Grid control.

I'm particularly excited about that last part, as I've felt for a long time that some of the limitations with its grouping functionality needed to be addressed. With this release, we took the time to really re-think this aspect of the control, and instead of merely patching on additional features, to remake it in a powerful and elegant way and still keep it backward compatible. I believe we've managed to do that.

So, without further ado, here's what's new with Grid grouping:

Multiple Grouping

One of the Grid's major deficiencies for some time has been its inability to group by more than one column at a time. This had to do with various factors having to do mostly with the way we were rendering groups on the client. We have now surmounted those obstacles and groupings can be done on as many columns at a time as the user deems reasonable.

This ability extends across all running modes, usage scenarios and grouping modes.

Wait... Grouping modes?

Grouping Modes

When re-thinking the way grouping should work in Grid, we realized that there are at least three different ways in which paging through a grouped record set could work:

ConstantRecords; in this mode, the number of actual data records, regardless of how many groups they are distributed across, remains constant across pages. This mode is very simple to handle programmatically, since data-access code doesn't actually need to know anything about groupings. It simply retrieves the one page of records, which are then organized in appropriate groupings before being rendered on the client.

See demo here: ConstantRecords Grouping Mode

Thanks to its simplicity, this grouping mode is supported in all running modes, including WebService.

ConstantGroups; this mode replicates the default grouping behaviour that Grid exhibited up to this point. Paging a Grid grouped in this mode means that the same number of top-level groups is present on every page. All the contents of those groups (sub-groups and records) are pre-loaded and no additional data access is required to expand and render that content.

See demo here: ConstantGroups Grouping Mode

ConstantRows; the two modes described above have one common downside: as groups are expanded on the client, the number of rendered rows increases, and can stretch the height of the Grid control. With ConstantRows, the total number of rendered rows (records + group headings) is kept at the constant number dictated by GroupingPageSize.

See demo here: ConstantRows Grouping Mode

This running mode, when used in Server or Callback mode, requires some new server-side events (NeedGroups and NeedGroupData) to be handled in order to facilitate the efficient retrieval of only the necessary groups and records.

Which brings us to our next topic...

Grouping + Manual Paging

Up until this point, there was no good way to use manual paging (manual retrieval of just the required records from the database for each page) in conjunction with grouping with ComponentArt Grid. With the ConstantRecords and ConstantRows grouping modes, that is no longer a problem. Grouping can now be done while maintaining the efficiency of manual data retrieval.

Grouping + Scrolling

The ConstantRows grouping mode provides an additional important benefit. To support grouping in conjunction with the Grid scroller, maintaining a constant number of rendered rows was crucial. A Grid which changes its height as it is scrolled completely ruins the visual feel of a scrolling interface. With ConstantRows, grouping can finally be used with the scroller.

See a demo here: Scrolling a Grouped Grid in Callback Mode
And here: Scrolling a Grouped Grid in Client Mode

Grouping + Web Services

Grid's WebService running mode, while offering the best possible performance and elegance of design, does have limitations due its inability to perform complex server-side logic as data is loaded. This makes it difficult to support the loading of groups on the server (web service), but once again, the grouping modes greatly improve the situation.

The ConstantRecords grouping mode is easily supported in WebService running mode, since it only relies on the regular paging of records. Through this mode, grouping is now supported with web services. In the future, we will be expanding this functionality to support as much of the other two grouping modes as we can, but we feel that this is already a decent start.

See a demo here: WebService Running Mode

Conclusion

We hope you find Grid's new grouping functionality useful. We will continue to improve it and, as always, take your views and needs into account. Do let us know what you think.

Enhanced grouping isn't the only thing that's new in Grid 2008.2, but it's certainly the most significant. Nevertheless, I will be writing about the other Grid enhancements in a follow-up post. Stay tuned.

Share this post: email it! | bookmark it! | digg it! | reddit!

WebChart View Angle Chooser Control: Client-Side 3D Rendering

Bojan — Wed, 23 Jul 2008 02:57:00 GMT

View Angle Chooser is a UI control that comes included with the Charting 2008.1 product. It displays three sides of a rectangular box which can be rotated using a mouse to select the best chart viewing angle. Check out the Charting toolbar demo to see it in action.

In this post I will explain how it was implemented. The challenge was to efficiently draw 2D shapes (which represent projected 3D surfaces) using only standard DHTML technologies: HTML, JavaScript, CSS and DOM. There is no standard JavaScript library for drawing shapes, and the ones that do exist are highly inefficient, potentially requiring 100s of div elements.

We followed a trick outlined on www.uselesspickles.com which allowed us to draw horizontal or vertical right angle triangles using div elements.

The idea is to color one of the border edges of a div element and make an adjacent border edge transparent. The width of the other two border edges should be set to zero as well as the width and the height of the div itself.

  <div style='width: 0px; height: 0px; border-left: 0px;
              border-bottom: 0px; border-top: #ff0000 50px solid;
              border-right: transparent 100px solid;'>
  </div>

A triangle produced by the above code looks like this:

The other three right angle triangles can be drawn similarly. To draw a triangle of any size and orientation we need to subdivide it into constituent vertical or horizontal right angle triangles. A possible subdivision for the following triangle looks like this:

Not all triangles can be divided into a finite number of constituent right angle triangles as seen in the above figure. In that case, the subdivision can be stopped after the desired level of detail has been reached.

Our first attempt at subdividing the sides of a rectangular box involved dividing each quadrilateral side of the box along the diagonal into two triangles and subsequently dividing each of the resultant triangles in turn. This is what such a subdivision might look like:

White dots started appearing from imperfect alignment where two triangles are joined along the hypotenuse. To eliminate that effect and to decrease the number of triangles we changed our subdivision method to first select the largest horizontal or vertical rectangle that can be inscribed inside of the quadrilateral side. One rectangle and four triangles are produced. The rectangle can then be drawn with a simple div while the triangles are subdivided the normal way. This is what such a subdivision might look like:

Notice that no two triangles are joined along the hypotenuse.

The following drawing shows the View Angle Chooser rectangular box with each of the constituent rectangles and triangles drawn with a different shade:

When drawing 2D triangles using this technique keep the following browser incompatibilities in mind:

Internet Explorer 6 – Transparency is not supported, but you can use the chroma filter and choose one color to be transparent. Your triangle divs will be of the following form:

  <div style='filter:chroma(color=#abcdef);
             width: 0px; height: 0px; border-left: 0px;
              border-bottom: 0px; border-top: #ff0000 50px solid;
              border-right: #abcdef 100px solid;'>
  </div>

Opera (any version) – Divs are at least as high as the current font, so there might be a problem drawing small triangles. To get around this problem do the following:

  <div style='line-height: 0px; font-size: 0px;
             width: 0px; height: 0px; border-left: 0px;
              border-bottom: 0px; border-top: #ff0000 50px solid;
              border-right: transparent 100px solid;'>
  </div>

Interestingly, this control looks best in Firefox 3.0 because it is automatically anti-aliased while it renders the fastest in Safari 3.1.

Share this post: email it! | bookmark it! | digg it! | reddit!

Drilling deeper into the Charting client-side API

Bojan — Mon, 14 Jul 2008 19:17:00 GMT

ComponentArt Charting 2008.1 introduces an easy way for end users to customize the look and feel of charts. This is accomplished through a JavaScript client-side API. Charting toolbar demo in ComponentArt’s new Charting gallery shows how this can be done.

The toolbar demo allows the end user change the following properties:

Chart type
Color scheme
Orientation
View angle
Projection
Perspective
XY, YZ and ZX plane visibility
Legend visibility
Series order
Series highlighting
Choice of rendering engines, high-quality or high-speed

These properties are accessed via a ComponentArt Web.UI ToolBar control.

Properties with an on/off state, such as the visibility of the XY, YZ and ZX planes and the visibility of the legend, are implemented using toolbar buttons directly.

Properties that have several options, such as chart type, color scheme, orientation, projection, series order, series highlighting and the engine selection, use Web.UI Menu controls connected to their corresponding toolbar buttons.

The perspective property uses a Web.UI ComboBox control embedded in the ToolBar.

View Angle Chooser is a custom control implemented entirely in JavaScript. It is packaged with the WebChart assembly and can be used in your application separately from the toolbar demo.

The control must be enabled on the server before it is used:

[ C# ]
targetChart.Clientside.ViewAngleChooserEnabled = true;

The HTML code that this control generates is obtained by calling the GetViewAngleChooserHTML() method of the WebChart JavaScript object:

[ JavaScript ]
WebChart1.GetViewAngleChooserHTML();

Position, sizes and colors can be customized. The View Angle Chooser control will be discussed in more depth in a future blog post.

WebChart’s client-side API must also be enabled on the server before it is used. This was accomplished by setting the Clientside.ClientsideApiEnabled property to true. After the API is enabled it can be accessed through a JavaScript object whose name is the UniqueID property of the WebChart.

[ C# ]
targetChart.Clientside.ClientsideApiEnabled = true;

The chart properties are accessed through the getter and setter methods:

[ JavaScript ]
WebChart1.set_mainChartType("AreaSmooth");
WebChart1.set_colorPalette("Organic");
WebChart1.set_legendVisibility(true);
WebChart1.set_planeXYVisible(false);

To refresh the chart, after the properties have been set, the refresh method needs to be called.

[ JavaScript ]
WebChart1.refresh();

There are two ways in which the refresh method can function: an AJAX callback, or a traditional postback. This can be selected in the server-side code.

[ C# ]
WebChart1.Clientside.RefreshMethod = ClientsideRefreshMethod.Callback;

In our demo, the refresh method is not called explicitly because the AutoRenderOnChange property is set to true in the server-side code. This will cause a refresh to happen automatically after any client-side property has been changed.

[ C# ]
WebChart1.Clientside.AutoRenderOnChange = true;

Client-side customization is not limited to just these properties. In fact any property in your web application, chart related or not, can be customized through the client-side API. This can be accomplished using custom properties:

[ JavaScript ]
ComponentArt.Charting.WebChart.set_customProperty(name, value);

To retrieve the value of the custom property in the server-side code call:

[ C# ]
public string GetCustomProperty(string key);

Once the custom property value is retrieved you can do anything with it, such as modify any aspect of the chart or effect a change in another part of the application. See the Drill-down demo for an example of how custom properties are used.

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt Web.UI 2008.2 Details Announced

Miljan — Thu, 10 Jul 2008 18:34:00 GMT

The Web.UI product team has been hard at work on the next major release of ComponentArt's flagship product line. I am pleased to announce that the release of Web.UI 2008.2 is on the horizon and that it will include three new controls, a major Grid overhaul and several important new suite-wide features.

Three New Controls

The Web.UI suite is being expanded yet again. The following controls are being added with v2008.2:

Input for ASP.NET
Slider for ASP.NET
ColorPicker for ASP.NET

Major Grid Overhaul

Since its initial release, ComponentArt Grid has been perceived as one of the most valuable controls within the Web.UI suite. Our Grid-related R&D work has introduced many important innovations into the ASP.NET control space: client running mode, client-side structure creation, client templates and direct binding with web services, just to name a few. We are excited to push the capabilities of this control even further by adding the following features in v2008.2:

Multi-level grouping (web service running mode only)
Header context menus
Improved editing capabilities
Revamped keyboard support
Client-side sub-level sorting
Templated footer rows

New Suite-Wide Features

The following suite-wide features are being added with v2008.2:

Extended support for direct binding with ASP.NET AJAX web services
Accessible output and Section 508 compliance
ASP.NET MVC support
Extended keyboard support
Revamped product documentation

Release Dates - Updated!

The anticipated release dates for Web.UI 2008.2 are as follows:

Beta Release: Week of August 18, 2008
Full Release: Week of September 15, 2008

Please note that these release dates are based on our best estimate and are subject to change.

Share this post: email it! | bookmark it! | digg it! | reddit!

WebChart Drilldown Demo: A pathway to greater things

Filip — Fri, 20 Jun 2008 19:03:00 GMT

Upon visiting the drill-down live demo in CompoentArt's new Charting gallery one can easily see the benefits of client-side events within WebChart's client-side API. Not only can you register event handlers when a data point or series is hovered over, but in that event handler you get access to the data point, series and chart client-side objects that are related to the data point. This goes a long way in building interactive UIs that show more information than just a chart image.

But this is not the only interesting piece of code used in this demo. The demo also uses custom properties set on the client-side in order to customize the SQL query to the data source, and come up with a unique image from the same WebChart instance.

Let's take a closer look at both of these techniques.

Client-side Event handlers

If you take a look at the code behind the drill-down demo (available in the sample project that comes with the installation of WebChart 2008.1 or by pressing the SHOW CODE button in the demo) you'll notice that the mouse hover event handler is simply registered in the ASPX page with the following code within the WebChart tag:

<ClientEvents>
    <DataPointHover EventHandler="onDpHover" />
    <DataPointExit EventHandler="onDpExit" />
</ClientEvents>

In the call to the JavaScript onDpHover function, we will receive two parameters. The first will be the WebChart instance that generated the event, while the second will be a DataPointHoverEventArgs instance. We can use these two classes to extract any data relevant to the data point, its parent series (available from the DataPoint class), or the WebChart (also available through the parent series of the datapoint). In this example we simply pop up a DIV which shows the Y value of the data point that is hovered over, along with its X label. However, this API can be used in many powerful ways:

To add up the values of all data points in a series and display a total
To find if certain data points fall within a dangerous range in order to pop up a warning
Create links, or fire function calls that are relevant to the data point or series
Update additional parts of the UI that may be related to the data point or series

It is also important to note that this functionality was made possible by enabling WebChart's RenderAreaMap, Clientside.SerializeDatapoints and Clientside.ClientsideApiEnabled boolean properties in the server-side code.

Custom Properties

In addition to client-side events the Drill-down demo uses custom properties in order to pass additional data to the server-side. Custom properties are set on the client-side through WebChart's setCustomProperty(key, value) method and retrieved on the server-side through the String GetCustomProperty(string key) method.

The method provides a way for developers to quickly pass parameters from the client-side to the server-side code in a way that is optimized to take as little overhead as possible. The developer can then retrieve the parameters in the server-side code and change the WebChart instance or any other server-side code in any way imaginable.

In the Drill-down demo, we use the custom properties in order to customize the SQL query to the database. We pass values of MONTH, YEAR and DAY for the period custom property in order to customize the SQL query to sum up the daily sales from the database for the given period, and produce a suitable data source for the WebChart based on the period chosen.

This concept can easily be extended to:

Select the data that the user wants displayed in the chart
Select functions that the user wants applied to data (max, min, derivative or any custom function)
Apply a custom template to the chart upon a user action, based on user preferences

Caching Customized Charts

In addition to providing flexibility to a single WebChart instance, use of custom properties can be important when caching chart images. Since our live demo is posted on a high-traffic site, and the data in the sample database does not get updated, we do not have to render a new chart for every request made to the page. Furthermore we know that all charts with the same custom properties (i.e. MONTH view, December, 2004) will produce the same image. Since setting custom properties on a chart makes that chart customized we want to enable caching for customized images in order to save our CPU from needlessly rendering images.

WebChart1.Clientside.ClientsideCustomizedImageCachingEnabled = true;
WebChart1.CacheInterval = 86400; //1 day in seconds

This ensures that each unique chart image is rendered once daily and the same image is reused (with virtually no overhead) for all subsequent requests within a day.

Conclusion

Even though at first glance the Drill-down demo looks the least impressive of the three live demos, when you look under the hood you'll find a lot of features to get excited about. Whether you're building powerful and interactive UIs, allowing end-users to customize the data shown in the chart or designing your web app to be CPU conscious and take advantage of caching you can use this demo with its sample code as the starting point to implementing the techniques described above.

Share this post: email it! | bookmark it! | digg it! | reddit!

WebChart AJAX Zooming and Scrolling: How to get the most out of your data

Filip — Wed, 18 Jun 2008 17:32:00 GMT

Zooming and scrolling is one of those essential features that is a must-have for any comprehensive charting product. However, deciding how to implement zooming and scrolling within WebChart was not obvious as there was no industry consensus on how this feature should look and operate, let alone how it should be implemented.

Our first decision was an easy one as it had to do with the technology used to implement the feature. Right away we knew that we did not want any third party plug-ins (including Flash) to be needed in order to use the feature. It had to be pure JavaScript and DHTML, yet still look good and be user-friendly. The reason for this was not only ease of compatibility with virtually all of today's environments but also the ease of customization for our customers. The second decision had to do with how the feature should work. Some common implementations allow end users to use the mouse to draw a rectangle that represents the area that you want to zoom into. This fairly useful, however zooming out is not elegant with this model. In addition to zooming, we also wanted to give the end user the ability to scroll through large sets of data, which was not possible with this implementation.

So we decided to go with an implementation that uses a second instance of WebChart as the zooming and scrolling control, as seen in our demo. This was the only implementation that satisfied all of our requirements while still visually looking good and being user friendly. Below is a capture of the control in action:

Configuring Your Own Control

ComponentArt's concept of a zooming and scrolling control is a simple one. You create another instance of WebChart, set its Clientside.IsScrollControll property to true, and finally connect it to all the charts you want to control with this instance (yes, this means one zooming and scrolling control can control multiple WebCharts). When the page is rendered in the browser, the control chart will be enhanced with the scrollbar and the shading which will allow the end user to zoom and scroll.

The best way to get started with zooming and scrolling is to take a look at the live demo of the zooming and scrolling control. It is advisable to then read the documentation of this feature as well as look at the code that makes up the live demo (both of which are also available through the documentation and the sample project that come with the installation of WebChart 2008.1)

When you feel you're ready to make your own control, here are a few tips to keep in mind:

Connecting your display chart to the control chart is done through the display chart's Clientside.MyScrollControl, which should be set to point to the instance of the control chart. This allows multiple display charts to be controlled by a single control chart
Always use the same data source in the control and display chart. This prevents the data in the display chart from falling out of sync with data in the control chart. The result of this is that the display chart will have more data than needs to be displayed at any one time, but this is the correct implementation, further explained in point 3 below.
Set the initial display range through control chart's server-side SetZoomRange(from, to) method. This sets the appropriate display range on all the controlled charts, as well as shade in the appropriate region when the scroll control renders. The parameters passed need to be of the same type as the values in the X axis, either DateTime, String or numeric. The call to SetZoomRange needs to be done before any of the display charts perform their data binding, in order for the appropriate range of data to be extracted from the data source. For this reason it could be considered good programming practice for the control chart code to precede the display chart's code.
Do not set WebChart.CoordinateSystem.XAxis.MinValue or CoordinateSystem.XAxis.MaxValue on the display chart as that will override the values set by the zooming and scrolling control.
Setting WebChart.AdjustReferenceValue to true will zoom in to show just the Y range in which all the values in the current chart fall into. This is very handy for use with display charts that have large and varied data sets.
Customize the look and feel of the zooming and scrolling control by changing the images for the scrollbar, the shadow color, shadow opacity as well as the HTML and the position of the Range Display pop-up. See the documentation on how to do this.
Align the axis of the control chart to the beginning and end of the scroll bar. This is done by matching the left and right margin to the width of the arrows on the ends of the scroll bar. Since WebChart's margin widths are set in percentages, we need to match that to the pixel widths of the arrow images. So if the scroll bar arrow images are 15 pixels wide and the chart is 500 pixels wide, the following code will do the trick:
```
WebChart2.View.Margins.Left = (15.0 / 500) * 100;
WebChart2.View.Margins.Right = (15.0 / 500) * 100;
```
Use WebChart's client-side API to dynamically set the active display range. For example if you want to have a button that will set the range to show year to date, you need to execute the following JavaScript code when the button is pressed:
```
var startD = new Date();
var endD = new Date();
startD.setFullYear(2008,1,1);
WebChart2.rangePicker.selectRange(startD, endD);
```
Again, the parameters passed to the method need to match the type of the X axis dimension, either Date, String or numeric.

That's it from me for now, I hope you find these tips helpful when creating your zoom and scroll charts. I will write more about WebChart's other cool client-side features in upcoming posts.

Share this post: email it! | bookmark it! | digg it! | reddit!

Charting 2008.1 - Boldly Going Where No AJAX Chart Has Gone Before

Miljan — Tue, 17 Jun 2008 18:24:00 GMT

We are thrilled to announce the release of ComponentArt Charting 2008.1. This product has been in the works for well over a year and it brings a number of truly important new features to the market. At this time I would like to highlight the two most significant areas of product improvement in v2008.1, and the Charting development team will follow up with additional juicy details related to the new functionality.

AJAX Interactivity

We think that the new view angle chooser, zooming and scrolling UI and the drill-down features push AJAX capabilities further than any other charting solution on the market. A key point here is that all of these features were implemented through the brand-new client-side API of the WebChart control. We are only scratching the surface of what can be done by showing a few practical applications of this API.

Dual Rendering Engines

The 2008.1 release of Charting for .NET introduces a new high-speed rendering engine, augmenting ComponentArt's famous 3D rendering quality with the ability to produce GDI+ chart renderings in high-traffic environments. All charts within our brand-new gallery can now be viewed through both rendering engines.

I hope this has served as a nice high-level overview of the most important new features in v2008.1. Many additional details will follow in the coming days and weeks.

Share this post: email it! | bookmark it! | digg it! | reddit!

Grid Configuration via Web Service

Milos — Fri, 13 Jun 2008 13:35:00 GMT

Since the introduction of the WebService running mode in ComponentArt Grid, and related functionality (like the client-side load method), we have seen this approach rapidly gain popularity and, naturally, produce demands for more features and more versatility.

Versatility is key when it comes to UI controls, so we have been spending some time improving WebService mode in this respect. As of Web.UI 2008.2 SP2 (build 2008.2.1180) Grid has a number of new features.

WebServiceConfigMethod

In addition to being able to define ASP.NET AJAX web service methods for data selection, insertion, deletion, etc, it is now also possible to perform Grid configuration in a web service.

Rather than defining top-level properties, GridLevels and their constituent GridColumns and all the accompanying styles on the ASPX page where the Grid instance is placed, all of these can now be loaded on the fly by defining the WebServiceConfigMethod server-side property and calling the client-side webServiceConfig method.

GridWebServiceConfigResponse

The web service method performing Grid configuration is expected to return an object of the type GridWebServiceConfigResponse. Such an object contains top-level property settings (contained in the Properties member), and GridLevel definitions (contained in the Levels property) which, in turn, can contain GridColumns.

Configuration can be done at any time on the client, without going back to the server from which the ASPX file originated. The configuration request passes in an optional custom parameter, so that configuration can be context-dependent.

GridWebServiceSelectRequest.Columns

To enable such potential on-the-fly changes to the Grid’s layout and definition, GridWebServiceSelectRequest now contains a Columns property. With every web service data request, Grid now sends along the collection of columns (data fields) that it expects on the client. This allows the web service selection logic to account for on-the-fly changes in the Grid’s client-side configuration, and always provide the required data.

And More

In addition to the above, a number of other enhancements to web service functionality have been made which should simplify its use in many scenarios and enable altogether new ones.

For example, GridWebServiceSelectResponse.Items can now contain simple arrays of objects corresponding to the rows of data requested by the Grid. Simple proxy classes no longer need to be defined, as long as the order of data in the arrays matches the fields specified in GridWebServiceSelectRequest.Columns.

The select response can now also contain hierarchical data, with rows containing more rows defined on the second (or third, etc) GridLevel. To keep on topic, I will write more on this particular functionality at a later date.

Cheers, and thanks for stopping by!

Share this post: email it! | bookmark it! | digg it! | reddit!

AJAX With ASP.NET MVC and ComponentArt CallBack

Milos — Thu, 01 May 2008 18:08:00 GMT

Web.UI vNext (preview build included in attached project packages) will include, among other things, a new feature of the CallBack control which will allow it to become extremely useful for integrating AJAX functionality in web applications build on Microsoft’s new ASP.NET MVC framework.

About Microsoft ASP.NET MVC

A few months ago, Microsoft announced a new, alternative framework for ASP.NET applications built around the model-view-controller architecture pattern. Scott Guthrie blogged about it and described in detail how this framework operates. Though still in a preview stage, ASP.NET MVC has already generated a lot of buzz and interest, and promises to be an important factor for some types of web apps. However, ASP.NET MVC has no AJAX support out of the box.

About ComponentArt CallBack

ComponentArt CallBack is a relatively simple ASP.NET control which contains HTML content and allows it to be updated asynchronously via AJAX calls back to the server. In a typical web form, the request is sent back to the page of origin and is handled by the control itself, which raises an event, allowing the developer to compose the content to be sent to the client.

A new feature introduced to CallBack for the next version of Web.UI is the client-side loadUrl method. This method allows the control to asynchronously call up any URL and display the content returned within its element on the page. This feature is useful for all sorts of situations, including rapid integration of partial AJAX updates in web applications built on Microsoft’s ASP.NET MVC framework.

ASP.NET MVC and ComponentArt CallBack

ASP.NET MVC request routing operates according to conventions for HTTP GET requests. Requests for pages are of the form /Controller/Action/Id, and the logic of the application is built to follow this flow: the appropriate Controller accepts the request, and handles the requested action by performing the appropriate business logic (in conjunction with the Model) and passing resulting data to the appropriate View which is then rendered to the client.

This architecture is a complete departure from that of ASP.NET web forms, which is based on postbacks and persistence of control state. The traditional use of CallBack (by raising server-side events to handle a callback request) is no longer applicable. However, with the addition of the loadUrl method, CallBack fits perfectly into the ASP.NET MVC architecture and provides the easiest and most integrated way of performing partial AJAX updates in an ASP.NET MVC application.

How it Works

When designing functionality that is to be useful for ASP.NET MVC apps, we found that less is more. Since the MVC model forces us to drop most of the complexities of the ASP.NET web form life cycle, control state and server-side events, we are left with just the basics of HTTP. In this case, that is all we need, and it is also the best way to seamlessly integrate into the MVC way of doing things.

CallBack's loadUrl method causes CallBack’s content to be loaded from the given URL, which, of course, can follow MVC conventions. We are therefore able to have a CallBack control on an MVC View Page (say, CallBack1), get it rendered to the client, and from that point, only interact with it on the client side, to perform actions and load new content, with typical calls like these:

CallBack1.loadUrl('/Search/Beverages/23');
CallBack1.loadUrl('/Products/List/Beverages');

On the server, layout is organized as a standard ASPX View, with distinct parts encapsulated in ASCX views.

After the initial ASPX view is loaded, those parts of it which are encapsulated in ASCX views (and placed inside instances of ComponentArt CallBack) can be updated asynchronously.

Organizing content areas in ASCX views is the key component of our MVC AJAX solution.

The loadUrl method also takes an optional second parameter, POST data. If data needs to be sent that is not part of the URL (including the optional query string), it can be combined into a POST data string on the client (in the form "name1=value1&name2=value2") and passed to loadUrl. It will be available in the MVC controller as part of the Request.

Examples

To illustrate these ideas, I include two examples below. With these web application projects, I have tried to demonstrate how Web.UI controls can be used in the context of MVC, including how partial AJAX updates can be performed with the CallBack control while maintaining the full MVC pattern. There are two separate applications:

MvcChartGallery

This ASP.NET MVC web application is an adaptation of a typical application dealing with hierarchical data, featuring ComponentArt Web.UI controls. The architecture of the web application uses simple one-time rendering of the controls, taking them out of the paradigm of web forms. Interaction with the controls causes full-page refreshes with appropriate MVC routing. Context data is passed in URL query parameters.

MvcAjaxChartGallery

This ASP.NET MVC web application is a reworking of the above example which encapsulates autonomous areas of the UI into MVC User Control Views, which are in turn placed inside instances of ComponentArt CallBack, allowing them to be updated independently and asynchronously (see diagram 2). Most importantly, these partial updates are HTTP requests MVC User Control Views and are fully routed through MVC. They can be treated in the same way as any other MVC request, and application logic does not need to do anything special to allow for this asynchronous operation, nor indeed to be aware of it at all.

Conclusion

Though still in an early preview stage, ASP.NET MVC has attracted a lot of interest and shows a lot of promise to grow into an important web technology. However, as of yet, ASP.NET MVC has no built-in AJAX support. Despite its divorce from web forms, applications built on ASP.NET MVC can still utilize rich ComponentArt Web.UI controls, and use the CallBack control, in particular, to quickly and easily add AJAX functionality in a way that seamlessly fits into the MVC pattern.

Share this post: email it! | bookmark it! | digg it! | reddit!

TreeView and Web Services

Milos — Wed, 23 Apr 2008 17:49:00 GMT

In my previous post, I talked about the web service functionality that's common to all ComponentArt navigation controls. I focused on common features that are present in many different controls, especially in this case, but this approach was unfair to one control. With its ability to load chunks of data on demand, TreeView is the odd man out, supporting everything that other navigation controls do, but adding its own unique twist.

Like the other navigation controls, TreeView has control-level WebService and WebServiceMethod properties. These determine which ASP.NET AJAX registered web service will be called, and which method of that service, when nodes are retrieved. For the initial data load, the behaviour is identical to Menu, TabStrip or NavBar. What TreeView can do that others can not is to only load some nodes initially, letting user actions determine what else gets loaded and when. Essentially, TreeView is able to operate in load-on-demand mode with web services.

To return load-on-demand nodes (parent nodes with no child nodes pre-loaded), simply set their UseWebService property to true. This will notify TreeView to consider these nodes to be parent nodes, and to call the web service again when they are expanded, to load their child nodes. When that happens, the same WebServiceMethod will be called, but with a twist: the TreeViewWebServiceRequest object that is passed in will have its Node property set to the node that requires data. Based on the Text, Value or ID of this node, appropriate new nodes can be created and returned, as they would normally, from the web service method. Note that these child nodes can also have their UseWebService property set to true.

After a web service call completes, the client-side event also exposes the node for which the call was made, in addition to the customData property common to all navigation controls. Here's an overview of the client-side TreeViewNodeWebServiceCompleteEventArgs class:

function TreeView1_webServiceComplete(sender, eventArgs)
{
  var node = eventArgs.get_node();
  
  if(node)
  {
    alert('Completed web service call for node ' + node.get_text());
  }
  else
  {
    alert('Completed web service call for top level data.');
  }
  
  var customData = eventArgs.get_customData();
  
  if(customData)
  {
    alert('Web service call returned custom data: ' + customData);
  }
}

You can see an example of this functionality online with the TreeView Web Service Load-on-demand sample. Please note that this functionality is fully available only as of Web.UI 2008.1 SP1, released on April 23rd 2008.

Summary

To recap, since TreeView can load node-specific partial data through web services (unlike other navigation controls, which can only load all the items at once), its related API is a superset of, say, that of Menu. TreeViewWebServiceRequest includes the Node property (null for initial, top-level loading), TreeViewNode has the UseWebService boolean, and the client-side TreeViewWebServiceCompleteEventArgs class includes a node property. These extensions enable efficient load-on-demand functionality built entirely on ASP.NET AJAX web services.

Share this post: email it! | bookmark it! | digg it! | reddit!