In my last two blog posts (
here and
here, I discussed the scenarios that I'll have on mind when reviewing the two databases we've selected for our local storage reviews (VistaDB and db4o). This blog post and the next are about what I'll be looking for in the products (and also let me discuss why I'm not reviewing SQL Server Express or the Jet database that comes with Microsoft Access).
Interestingly enough, based on the scenarios that I described in my last post some of the criteria that I would be interested in when looking at a "real" database don't apply in this situation. To begin with, I'm not particularly worried about performance even though one of the scenarios focused on "performance enhancement". The database is going to have very few clients (probably just one), the amount of data is going to be small compared to what the remote database will be holding, and the client computer has only a single user at a time. In fact, I would suspect that most of the time, most of the data being accessed is going to be held in memory by the local database. My assumption is that performance is going to be very fast no matter what the underlying storage mechanism is.
What I am most concerned about is ease of deployment. This is why SQL Server Express isn't attractive to me: SQL Server Express is, essentially, a separate install from my application. Ideally, I want something that will automatically be rolled into my setup package and will silently install with the application (and without the user being aware of it). My test here is probably a one-touch deployment: If the database can install with my application in a download environment then I will be very happy.
Of course, because SQL Server Express does exist and is free, it also means that I'm looking for a relatively cheap solution. While I'm willing to pay for a simpler deployment package I'm not willing to pay a lot for that -- I'm probably looking in the $500 range for a product.
I'd also like a local database engine that I can roll out with each individual application, so a smaller footprint is preferable to a large one. I would also need these database engines to run simultaneously without stepping on each other's feet. SQL Server Express often takes up more disk space than the application I've created that uses it, and I've never even tried managing multiple instances of it on the same computer.
Reliability is critical of course: since this is running on a local computer I don't want to have to visit each computer to fix problems. That's difficult to test in a review situation, however, so I'll probably just have to take the vendor's words for that. Ubiquity is important, though. I'd love a single solution that uses the same library in both 32-bit and 64-bit environments.
While those are the essential criteria, there are some additional criteria that I'll be considering -- I'll cover them in my next blog post. And, as I work with the products, I'm sure that I'll develop additional criteria. It's amazing what a new product can teach you.
Posted by Peter Vogel on 06/15/20103 comments
As I mentioned
in my last blog entry, we picked out two databases to review for our "local database storage" review for the July issue timeframe: VistaDB and db4o. This blog (and the last) answer the question, "What do I mean by a local database?" I discussed one of the scenarios (performance enhancement) for local storage in my last blog.
A second scenario where local storage is needed is to support processing when the network connection to the application's remote database isn't available: continuity of service. By downloading and caching key data on the local computer, the application can continue to work even if the most recent data (back on the remote server) isn't available.
Obviously, this is only going to be possible if the data is relatively non-volatile. If the application can't refresh the local data from the server the local data goes stale and, if the data is volatile (changes frequently), bad things happen to good programs. A variant on this scenario is using local storage to store the user's changes until the connection is made when the user's data can be uploaded to the central database.
As I mentioned in my last blog, I have an interest in these tools (as I do in most of the tools we review, quite frankly). My application is a Windows service that uploads data from sensors at the client to a central Web service. To handle continuity of service each client has two threads: one that writes data to a flat file and another that reads from the file to send the data to the Web service. When we lose the connection to the 'net (and we have) the file just grows until the connection is re-made. I don't object to using flat files but a local database would make this part of the service considerably easier to maintain.
We're also considering creating a server-side version of this application where working with flat files isn't an attractive option. For the server-side version we'd rather keep all of our data (including the data currently going into the flat files) in a database. Rather than have two codebases (one using a client-side flat file and one using a server-side database) we'd rather have a single code base that uses the same storage throughout.
Which leads to the criteria for the products under review. That'll be my next blog post, though.
In the meantime -- do these scenarios sound sane to you? What else (if anything) should a local database support?
Posted by Peter Vogel on 06/10/20100 comments
We picked out two databases for review in our July issue assessment of "local storage" tools: VistaDB (my choice) and db4o (on the recommendation of one of our readers). While the review of db4o regrettably didn't make it into print, you can expect to see my hands-on take appear on this site in the next week or so.
Regardless of which products appear in print, the next step in my review process was to define what functionality I'm supposed to be assessing. Or, to put it another way, what do I mean by a "local database"?
My assumption is that, by and large, developers create applications (Web or desktop) that update some remote data store. In that scenario, the developer might still want some place to store data on the local computer: the local storage. The data could range from user preferences, to sets of "working data," to downloaded data to be used for offline analysis.
The first scenario for using local storage is to improve performance by eliminating the round trip to the server. The alternative to using local storage is to load data into memory (and there are a bunch of in-memory databases that support that scenario). However, I'm assuming here that the developer wants some form of long-term persistence: the developer wants the data to stick around. In some cases, especially where the developer is going to be analyzing the data offline, the amount of data may be too large to hold in memory or the user is expected to add to the local data store over time. A related scenario is where the developer has data that doesn't need to be in the central store (e.g. the user preferences mentioned earlier) and decides to keep it locally.
I'm keenly interested in this topic because I've written a client-side, multi-threaded Windows service that is busy receiving data from a variety of sensor devices (the service spawns a client app for each sensor). As the client apps gather this data, they upload the data through a Web service to our server-side application, which parses the data and stores it.
My client would also like to extend the functionality of the Windows service to provide some near-realtime services at the client. To support that, in addition to parsing the data on the server, we'd also like to parse the data at the service to provide faster access to the embedded data. Since the parsing process is table-driven, this is going to involve keeping copies of some server-side data at the client.
Posted by Peter Vogel on 06/09/20100 comments
As parallel processing becomes main stream, tool vendors are moving to provide more support. See
my conversation with Stephen Forte of tool vendor Telerik, who sees parallel processing and multicore support as having the single biggest impact on .NET development in the near future. The latest version of DevExpress' Refactor! and CodeRush (reviewed recently
here), for instance, support new refactorings for parallel processing. I spoke with Mark Miller, chief scientist at DevExpress and a C# MVP, about refactoring in .NET.
Peter Vogel: What are the challenges and opportunities in supporting refactoring for parallel processing in .NET 4 and Visual Studio 2010?
Mark Miller: The biggest challenge we faced was the moving target, as these refactorings were designed and built almost a year before .NET 4.0 shipped. With regard to opportunities, supporting parallelization continues our long history of supporting the latest technologies developed by the language and framework teams at Microsoft. Also, refactorings that convert old technology into new make it easier for customers to learn and adopt the new technology.
PV: What was hard to implement?
MM: Our biggest challenge was in the implementation of the "Execute Statement Asynchronously (FromAsync)" refactoring. That refactoring converts existing code like this:
using (Document document = new Document())
{
document.Print();
}
Into code like this that takes advantage of the support for parallel processing:
using (Document document = new Document())
{
var t = Task.Factory.FromAsync(document.BeginPrint, document.EndPrint, null);
t.Wait();
}
This assumes that the Document class looks like this:
public class Document: IDisposable
{
public void Print()
{
//...
}
public IAsyncResult BeginPrint(AsyncCallback asyncCallback, Object obj)
{
IAsyncResult result = null;
//...
return result;
}
public void EndPrint(IAsyncResult iAsyncResult)
{
// ...
}
public void Dispose()
{
// ...
}
// ...
}
Notice that in the conversion above we go from a Print method call into referencing BeginPrint and EndPrint methods passed as parameters into the FromAsync method. The availability check for this refactoring is complex, as it needs to start with the document local variable, then move to the Document class, then search that class (and its ancestors) for methods called BeginXxxxx and EndXxxxx (where Xxxxx" matches "Print" in this case) and ensure those methods have the expected signature.
Posted by Peter Vogel on 06/06/20100 comments
DevExpress DXperience 10.1
We reviewed the DevExpress DXperience suite, which concentrated on Windows Forms and Web controls,
some time ago. DXperience 10.1 (also called V2010 vol. 1) is now out, but it emphasizes support for WPF, Silverlight, and XAF.
On the Silverlight front, DevExpress focused on Silverlight 4. DevExpress wanted to move forward quickly in the Silverlight arena while minimizing breaking changes. While DevExpress still seems to regard WPF developers as being on the bleeding edge (though they seem to like supporting the bleeding edge) they have made significant improvements to their WPF DXPivotGrid. And if you thought that XAF was a reference to a North African currency code.... No, you were wrong. It stands for eXpressApp Framework, which appears to be a platform independent application generator (currently supporting WinForms and ASP.NET 2.0). You can find more about DXperience 10.1 here.
Preemptive Dotfuscator 4.8
More recently we looked at Preemptive Solution's Dotfuscator. As of June, the latest version of Dotfuscator now secures Silverlight, WPF, and XAML/BAML files.
As I noted in the review, it's a shame that Dotfuscator is so closely associated with code security, because the company also provides great tools for tracking your code at the client's location through their RunTime Intelligence offering. That tool is now integrated into Visual Studio 2010, so you'll be able to take a look at Runtime Intelligence there (once you upgrade). Check out Dotfuscator 4.8 here.
dynaTrace 3.5
While the changes in the two products above reflect evolving technology in the toolspace, changes in dynaTrace's application monitoring tool reflect a change in integration. We've taken two looks at dynaTrace: one at their free JavaScript product, and the other at their enterprise product.
The latest version of the tool attempts to integrate what I cared about as a developer (tracking, reporting, and monitoring a transaction through all the layers of an application) with what I cared about back when I ran an IT department (business transaction management). The company's goal is to take the application performance data that the tool produces and apply some business context (e.g. revenue contribution, service level monitoring). Check out dynaTrace 3.5
here.
On Deck: DevExpress
Finally, DevExpress has also released a new version of their add-in for Visual Studio, with new refactorings for parallel processing. In my next blog post, I'll be talking with DevExpress Chief Architect Mark Miller about the technical those new refactorings created for DevExpress.
Posted by Peter Vogel on 06/04/20100 comments
The current plan for the August issue of Visual Studio Magazine is to take a look at the new Visual Studio 2010 versions of the developer productivity add-ins Developer Express CodeRush and JetBrains ReSharper. Anything can happen ahead of our publishing deadlines, so no promises, but definitely look for these products in the VS Toolbox section of the magazine come August.
We looked at the Visual Studio 2008 versions of these two products last year. Check out Write Better Code, Faster, with ReSharper 4.5 from our September 2009 issue, and Turbo Charge Visual Studio with DevExpress CodeRush from our October 2009 issue. However, the significant changes with Visual Studio 2010 and .NET Framework 4 make it worthwhile to revisit these products, which have been substantially reengineered to work with the latest version of Visual Studio.
Before we get cracking on the review, I'd like to know what you would like to know about these tools. Email me at phvogel@1105media.com, or leave a message in the space below.
Posted by Peter Vogel on 06/04/20102 comments
Back when I
reviewed Nevron's Diagram for .NET, I
wrote in a blog post that it took some pressure off of me when I reviewed a unique product. As I poked around in the field, though, I found that there were any number of diagramming tools available. This is why I never say, "This is the best product." I just try to assess the product I'm reviewing on its own merits.
In fact, there are markets with competing products that I didn't even knew existed. Among diagramming tools, in addition to Nevron's Diagram for .NET, there's also yWorks Diagramming Components for .NET, SyncFusion Essential Diagram, and a variety of tools for .NET, WPF and other environments from MindFusion. And there are more out there.
Spellcheckers are another field with multiple competitors, including major players like ComponentOne with its standalone product IntelliSpell, suites from Infragistics and Telerik with spellchecking components, and lots of specialized companies like Keyoti with its RapidSpell Desktop .NET and SpellCheck with its line of products.
There are markets I didn't even know about that feature multiple players. I didn't realize that signature capture was a market until I found Bennet-Tec's Web Signature product. It competes against, for instance, Topaz Systems SigPlus Pro line and CIC's suite (which goes way beyond just capturing signature to managing providing servers for managing authorization/authentication workflows). And that's not getting into companies offering products to implement biometric authentication like fingerprints.
The tools market is sufficiently varied (and odd) that this week I turned to Mark Driver, vice president at Gartner Research, for some understanding. Since we'd just reviewed one of Telerik's suites, I went beyond asking about the general Visual Studio/.NET toolspace to look into the component suite market segment. Here are links to the first and second Q&A blog posts with Mark.
Posted by Peter Vogel on 06/03/20100 comments
In
my last blog entry, I spoke with Mark Driver, a vice president at Gartner Research focusing on the Visual Studio market. In that talk, I got Mark's view of the Visual Studio/.NET toolspace. In this blog entry, I wanted to ask him about the large component suites.
Peter Vogel: Who buys the big component suites? Why?
Mark Driver: Generally, enterprise teams and large organizations -- teams building a pipeline of ongoing applications and turning out stuff pretty consistently. They don't want to build their user interfaces bit by bit, they want to avoid the "Visual spaghetti problem." It's the difference in the question you ask. Do you say "I only need one control, I don't need 20 controls?" Or are you looking for an ongoing, consistent user experience?
While creating consistency across projects is important to these teams on the look-and-feel/styling side, the teams also look for consistency in their code base. The controls in a suite not only look the same but work the same.
Often these teams are building in several different environments. The downside in dealing with all the APIs (WinForms, WebForms, WPF, Silverlight, AJAX) is that it creates a point of confusion: "Which API should I be targeting? Is WinForms a legacy API? When should I be developing in WPF and jQuery UI?"
If you buy from a small company, that company may only support one environment: whenever I add a new API, I have to go out and buy new controls. These teams get a significant savings by licensing through upgrade paths and having one vendor who supports them across multiple environments. In some cases, the team is looking to the vendor to provide an on-ramp to the next technology.
PV: Is the suite market growing?
MD: It's growing with the overall .NET market -- but we're also seeing a shift in the ratio of big to small projects. I'm seeing growth in "stystematic" projects: more large scale, mission critical projects than was ever done in Microsoft platforms before. These projects are taking up a larger proportion of the Microsoft space than before. This is driven by a general increase in the quality of service provided by the Microsoft operating systems, Web servers, etc. That's supported by a better price/performance ratio in the Intel chips which are competing more successfully against RISC servers.
These larger projects demand better fit and finish, with an emphasis on a higher-fidelity user experience. So in addition to growth for the .NET API, I'm also seeing a larger share of the market devoted to those projects that use the component suites.
Generally, people don't change suites. There's a high threshold of pain to switch, and normally it's only done if there's a performance or a significant bug. Most companies use one suite and have used it for a long time. But a major project may encourage moving to a new suite because of dissatisfaction with the current package.
Posted by Peter Vogel on 06/02/20100 comments
I spoke recently with Mark Driver, a Vice President at Gartner Research. Mark focuses on the Visual Studio market, so he seemed like an ideal person to provide some insight on how the Visual Studio/.NET tool market functions.
I had two sets of questions that I wanted to ask Mark. First, I was interested in the structure of the Visual Studio/.NET "toolspace" and his answers to those questions make up in this blog. Since we had recently reviewed Telerik's RadControls for ASP.NET AJAX (see the May issue review titled Adding AJAX with Telerik RadControls for ASP.NET AJAX), I also wanted to ask about the "suites" portion of the market. His answers to those two questions will be in my next blog entry.
Peter Vogel: Who makes up the Visual Studio/.NET toolspace?
Mark Driver: The "third party UI control market" is a broad but shallow market. It's heavily dominated by very small vendors -- "Mom and Pop" developers. We see a lot of single point solutions. A few big companies have created a viable business model. But even the big companies aren't that big: a couple of hundred million dollars. It's a great model for a company with 20 employees
There are lots of reasons for that. First, there's so much free out of the box when you get Visual Studio and .NET. On top of that, there's so much freeware and shareware in the marketplace. The proliferation/growth of CodePlex for essentially free software is contributing to the free side of the market, for instance.
PV: Why do developers buy controls?
MD: The first questions are "Why build it yourself? Where's your return on investment in investing time to build your own chart control?" There's zero business differentiation value unless the control you want to build is something unique -- in which case you can't buy it anyway. And if you're not careful, you'll get stuck in the mire of creating system software instead of applications.
Tools are also priced aggressively, with most using a "per developer model" for pricing rather than a "per use" or "per client" model. So buying a control allows developers, for a small investment, to focus on what they should be focusing on: business logic.
And I'll go out on a limb here and say that, in recent years, media rich UIs and Silverlight have focused on UI 'fit and finish'. Why? Because the user experience is becoming increasingly important.
In many ways, Microsoft Office drives users' expectations about the user experience: it's the app people live in the most and so people expect all apps to work the same way. Let's say you're building an executive dashboard for the first time. Your users are using the new version of Office and expect the same kind of look and feel -- a "higher fidelity" user experience. It's like moving from AM to FM to CD quality.
And the investment to create that higher fidelity experience is greater than it used to be. When video games used 8-bit graphics, it took a few people a few months to build a game; now a new game demands large teams and is a million dollar project. So, a developer asked to deliver an equivalent user experience to Office is going to say, "I can give you a cool transition but don't expect me to program it!" You'll need a really high-end charting/graphing component to improve the user experience.
You can't have black text on a gray background anymore. You must not only have good code, but good-looking code. But if you want the "look and feel" with that professional polish, you won't have the time or expertise to do it yourself. Buy the control you need.
Posted by Peter Vogel on 06/01/20100 comments
From looking at the documentation and what little server-side programming I've done with Telerik's suite, it looks like the controls work as well or better than the equivalent ASP.NET control from Microsoft (where an equivalent control even exists). I'm willing to imagine that, as a server-side control, their RadGrid may lack features that I like in some other company's Grid controls... but I'm not interested in doing a feature-by-feature comparison with every other suite because that would take something like forever.
What I am interested in, in an AJAX suite, is the suite's support for client-side development. I've spent a day or two now working with these controls. Several of the controls (the RadGrid, the RadTreeView, the listing controls) support binding to a Web service so I don't have to load data at the server. The controls all fire the client-side events that I'd be interested in catching (other developers might want to have more events fired during the formatting phases than I do). The event handlers are all passed parameters with the properties that I'd want to manage the control from client-side code.
I do have a complaint and I've got it with all AJAX-enabled controls that I've seen so far: Web service databinding is one-way. I'd love to have a grid control that not only used a Web service to fetch data from a Web service but also automatically returned data to a Web service when a user did an update. Instead, I have to write that code myself in the controls' event handlers.
Outside of the training PDF, I found that the documentation, while written in English, was obviously written by someone who's first language was a middle European language. Some controls I was interested in (e.g. RadXmlHttpPanel) had no documentation that I could find, other than an overview (even some sample code would have been nice). But I have to admit, I didn't check the forums -- I just followed the help links in the tools.
And the "Upgrade Wizard" I mentioned in an earlier blog? (see Digging into Telerik RadControls for ASP.NET AJAX.) While it would help me upgrade to a new version of the suite, it wouldn't help me with converting from the trial version to the "real" version. Fortunately, I only used the trial version on test projects so I'll just discard those projects. And, as I expected, when I installed the "real" version of the product, all the Telerik controls were added to my Toolbox (I also got lots of demo applications).
But, at this point, I've gone into enough detail about these controls. Time to move on to the next product.
Posted by Peter Vogel on 06/01/20100 comments
Back when I started, I used some new templates provided by Telerik to create a Web site where I could test their controls. Now that I'd gotten Telerik's controls onto the Toolbox, I figured that I should see if the controls would work on an "ordinary" site.
I opened one of my existing ASP.NET sites and dragged Telerik's DateTimePicker on to a page with ASP.NET's ScriptManager control. That got me two new DLLs in my bin folder (see figure 1). Other than adding a Register tag that referenced the Telerik DLL, nothing else seemed changed.
[Click on image for larger view.] |
| Figure 1. Dragging a Telerik control onto a page in your site adds two new DLLs to your bin folder. |
I noticed that, in the Telerik-generated project, my web.config file had included some references to Telerik's spell check component. To see what would happen if I tried to use that control without the entries in the web.config, I dragged Telerik's spell checker onto the page. On its SmartTag I found an entry called "Enable RadSpell HttpHandlers." Clicking on it generated two dialogs informing me that my web.config file had been updated (and, when I checked, it had, of course). The enable option disappeared from the SmartTag once its work was done, also.
Being of a perverse frame of mind this day, I deleted the entries in the web.config file, saved it, and clicked on the spell checker's SmartTag -- the "enable handlers" menu choice came back. It's nice to know that the controls will protect themselves from me.
[Click on image for larger view.] |
| Figure 2. Some of Telerik's controls require entries to a site's web.config file. These can be added from an entry on the control's SmartTag. |
While hardly a complete test, it suggests that integrating Telerik controls with an existing website is certainly doable -- the controls will add the support they need (and only the support they need) as they're incorporated into pages. It also suggests that the Telerik controls are comfortable working with ASP.NET's ScriptManager which is another good thing to know.
Don't get me wrong: I wouldn't be surprised to find that, down the line, I might run into a situation where some necessary item wasn't added automatically to the web.config file and I'd have to add it manually (the dictionaries that the spell checker needs didn't seem to get added to the App_Data folder, for instance). But, on the other hand, I've no desire to work through every control in the suite looking for something to go wrong and the controls seem to handle the "typical case."
 
Onto the AJAX Extensions
I'm finally feeling comfortable enough with Telerik's RadControls for ASP.NET AJAX to try, you know, actually using them. I returned to the project with the page that I'd created from the Telerik templates in yesterday's blog (Digging into Telerik RadControls for ASP.NET AJAX). From what I'd seen, it's obvious (now) that the "Scenario" choices on the Telerik menu are there to generate sample pages to let you play with the controls.
You can read the initial VS Toolbox review of the product
here.
What's interesting are the controls that go onto those sample pages. In addition to whatever control you selected, you get Telerik's RadScriptManager, RadAjaxManager, and RadStyleSheetManager. I know that Telerik's controls work with the standard ScriptManager, so the RadScriptManager either speeds up processing or adds additional functionality. The RadScriptManager definitely has some additional functionality: there are new CDN settings that seem to point to a Telerik server and enableScriptCombine is replaced with HttpHandlerUrl.
RadAjaxManager, it turns out, is a better version of the UpdatePanel. Rather than drop controls into a Panel, the RadAjaxManager gives you two lists of controls on the page. On the left-hand list, you check off controls to generate postbacks like controls in the UpdatePanel do (you still have to set the AutoPostBack property on the control to True). On the right-hand list, you check off the controls to be updated without a full page refresh when the results come back from the server. The property window on the far right lets you create a little whirly to spin while the postback is in process. It's sort of an UpdatePanel without the Panel and lets you scatter your AJAX-postback controls across the page instead of having to group them into panels.
The RadXMLHttpPanel also goes beyond the UpdatePanel, but does it by reducing the overhead involved in using the UpdatePanel. Like the UpdatePanel, only controls inside the RadXMLHttpPanel are refreshed. Unlike the UpdatePane, which causes all server-side events to execute, the RadXMLHttpPanel allows you to specify the WebMethod to call to fetch the data you want and skips the rest of your server-side code. The payload going up to the server is still fixed, though, and includes the ViewState.
While the control sounds cool, the documentation for it is sketchy. The 800 page training package, which I mentioned at the end of yesterday's blog, doesn't include anything on the RadXMLHttpPanel, for instance.
The RadStyleSheetManager allows you to combine calls to stylesheets to download multiple CSS stylesheets in one trip. Also a good idea.
Tomorrow I'll wrap up the in-depth exploration of Telerik RadControls for ASP.NET AJAX with a look at client-side development.
Posted by Peter Vogel on 05/27/20100 comments
Yesterday
I wrote in this blog that I was considering upgrading from the Telerik trial version to the official non-trial version. But with my tight deadline (and the size of the suite) I decided not to risk shooting myself in the foot and to continue my testing with the trial version. If all goes well, I'll have a chance to re-test after doing an upgrade and see if anything goes horribly wrong -- which actually seems like a pretty good thing to find out about the product. You can read the initial VS Toolbox review of Telerik RadControls for ASP.NET AJAX
here.
After starting Visual Studio, I decided to skip the Telerik menu and use the standard File | New WebSite menu choice. I found a new project type -- Telerik (I also found a new Telerik project type under File | New Project). Picking it brought up the wizard I mentioned in the previous blog and created a new Web site with a default.aspx page in C#. If you read my Practical ASP.NET column you know that I still do a lot of Visual Basic work. (Readers of my code generation book, which is C# and nothing but C#, may be surprised.) My consulting clients are probably still split 60/40 between Visual Basic and C#, so I tend to have more Visual Basic code lying around than C# code. I was initially disconcerted but then I realized that, since this is ASP.NET, I can add pages in any language I want. I added a page using Visual Basic to see what would happen. Everything worked fine. I then deleted the C# page.
Now I want to add some controls to the page. Another surprise: No Telerik tab on the Toolbox or any new controls in any of the other tabs. Also nothing if I right-mouse click in the editor window and nothing if I right-mouse click on the page in Solution Explorer.
Ah! But if I right-mouse click on the project in Solution Explorer I get a "RadControls for ASP.NET AJAX menu" with a choice called "Add RadControls Scenario" (this menu is also available from the Telerik menu on Visual Studio's main menu bar after you create your first project). I selected a scenario to add a DateTimePicker. This choice, it turns out starts a Wizard that lets me select a control (on the first page), change some settings that apply to all controls (on the second page), and change some control-specific settings (on the third page) -- see figures 1, 2, and 3.
[Click on image for larger view.] |
| Figure 1. Add control scenario. This wizard let me generate a page with a specific Telerik control on it. |
[Click on image for larger view.] |
| Figure 2. Selecting common properties. The second page of the wizard lets you select the language of the page being generated, whether you want to tie into Microsoft's CDN or register with jQuery, and whether to turn on RadAjax -- whatever that is. |
[Click on image for larger view.] |
| Figure 3. Setting control-specific properties. The third page of the wizard (not present for all controls) lets you select initial values for a control. In this case, I could select how many instances of the control that I wanted on the page. |
What I ended up with, however, was a whole new form with the DateTimePicker on it. This includes a RadScriptManager in addition to the control I picked. It seemed unlikely that this was how I was supposed to use the controls.
You know, I might actually have to read the documentation.
One note: The Telerik menu has an "Upgrade Wizard" choice listed so the concerns that I raised in an early blog about upgrading a Web site already using an older version of the Telerik controls may have been unfounded. I'll try an upgrade at the end of my testing. Tune in later.
I also poked around in the New Project templates and found templates in both the Visual Basic and C# areas. It's just the choice under the Telerik project type that only does C#.
Getting to Know Telerik's RadControls for ASP.NET AJAX
Telerik provides two sources for technical information. On-line there are some focused Web pages providing support for individual controls in the suite (these pages are also accessible from the SmartTags on each control). Also available is an 800 page PDF document/training package, which the Telerik site pointed me to with the link "Enjoy over 800 pages of dense training material...".
As a dinosaur and a part-time technical writer, I probably enjoy looking at other people's written work more than most people. But I think "enjoy" is asking a lot of the document's readers. And I don't think people take "dense training material" as a positive thing. Perhaps Telerik is being ironic.
Regardless of how Telerik expects me to feel about the document, it was exactly what I was looking for: a single volume, comprehensive discussion of the suite's controls. It didn't discuss the installing the package, but seemed to assume that the controls would be available on the toolbox. So, I used the 'Choose item' option on the Toolbox and added the Telerik controls. You shouldn't draw too many conclusions from me not finding the controls on the Toolbox initially: I probably fumbled something in the install.
As usual with these suites there are a ton of controls (see figure 4), even assuming that some of these are parts of larger controls and shouldn't be added to a page by themselves. There are some powerful controls in here: a scheduler, a spellchecker, and a grid. Given Telerik's history with creating ASP.NET controls I'm willing, at least for now, to assume that they work as server-side controls. I want to play with their client-side abilities.
I dragged some controls onto a form and pressed F5 -- everything seemed to work. Tomorrow I can start actually doing something with the controls.
What's your opinion: What do you want in documentation? Are lots of code samples enough for you? Do you prefer something brief and terse like what you find in the Help system (usually)? Or does an 800 page training package sound like the right solution for you?
Posted by Peter Vogel on 05/26/20100 comments