ctodx

This Blog

News

Favorite Posts

Archives

May 2008 - Posts

  • Editing with LinqServerModeDataSource

    We've had some feedback about our LinqServerModeDataSource not supporting editing out of the box. (Suggestion S19363 talks about this rather tersely, mainly since it's constructed as a memo to ourselves.)

    Since there's been a few, er, discussions related to data sources on this blog recently, I though I'd give you all a heads-up that we've now added support for editing via this class with Linq2Sql sources and it will be available in version 2008.2, the next major release.

    If you are interested in participating in the beta for this support, please track the above-mentioned issue. We'll get in touch with the trackers once we're ready for someone to bash on it.

    Until then, this knowledgebase article (K18092) describes a workaround.

  • Did you know?

    Did you know that we've been shipping unit tests for DXperience since version 2008.1?

    If you've bought the source code version of one of our products, go to our folder in Program Files (or Program Files (x86), if you're running a 64-bit operating system). Navigate into the Sources folder, and choose a product, like DevExpress.Web.ASPxGridView. Under that you should see a Tests subfolder holding all the NUnit unit tests for that product.

    Some of the older, more established products don't have NUnit tests yet because they used our in-house testing system (which you really don't want to see), but we're working on it. However, in general all the products we've been releasing over the past several months, say, are represented.

    Have a look at the tests, run them, file bugs against them if you find something. We're glad of all feedback.

  • Smooth, Silky, Sleek, Sweet -- The Movie

    OK, this is purely and simply an experiment: have Camtasia, will travel.

    What I've done is to record a quick screencast to show off the animation effects with our DXGrid for WPF, since the static images in this post don't exactly convey their coolness. And rather than wait for some superior talent to edit the screencast, I decided to just put it up. Our Gary Short calls these guerilla screencasts.

    I hope you liked it. Please give me feedback.

    Good or bad.Big Smile

  • Gauging Reactions

    Man, I'm starting to think that TechEd is not going to be long enough for us to show off our new stuff. This morning, for example, with the help of RomanK from our WinForms team, I've been delving into XtraGauges, our new product for WinForms applications that enables you to display various types of gauges. Ray showed off screenshots from a very early demo here, and you can be sure that this will already look different at TechEd.

    The XtraGauges product has been engineered from the outset to be multi-platform, with the first platform to be supported being WinForms. This initial release will be for DXperience v2008 vol.2 and will contain circular gauges (or, more accurately perhaps, gauges whose needles rotate around some point), linear gauges, and digital gauges. We hope to support ASP.NET in the next major release after that, v2008 vol.3. Other platforms, like Silverlight and WPF, are also under strong consideration, especially given the way we draw the gauges.

    We intend, at least for the first few releases, to use our skins model as a basis for the gauges. In other words, we will supply a whole set of pre-defined images for the gauges and will release new images as and when our graphics designer produces new ones.

    How are those images produced? For me, this is possibly the most interesting part of the whole design. The team has specified that they should be vector images, not raster, so that gauges can be expanded or shrunk without awful pixellation effects. They also decided early on to use XAML as the image definition language rather than rolling our own.

    Whoa, won't that mean WPF has to be installed? Believe it or not, no, WPF is not required. The reason is that they've written a light-weight XAML parser and image renderer as part of the product. These design decisions have several benefits:

    • The XAML language is great for producing scalable vector images and is well documented
    • Our graphics designer can use Microsoft Blend to produce high-quality gauge images; we don't have to create a special one-off image editor (like we did with our skins)
    • We can release gauge images whenever we have them, we don't have to wait for a DXperience release
    • Using the hand-written XAML parser and renderer we can produce great images for both WinForms and ASP.NET
    • When we are ready with our WPF and Silverlight versions, we don't have to do anything to migrate our images: we merely "turn off" our renderer and use the .NET Framework instead.

    It must be emphasized though that we haven't written a feature-complete XAML parser and renderer. That would be way too much work. Indeed, I would argue why replicate what Microsoft have already done? So there are some limitations: for example, no animations within the images and we only support certain simple XAML elements like Canvas, Rectangle, Ellipse, and so on. But that's certainly enough to get some stunning gauge images, and future-proof them into the bargain.

    (A quick warning: we are not going to be documenting the XAML renderer so please don't ask. It is an internal class and is not intended for generalized use as a component. We've written and tuned it for one purpose and one purpose only: rendering gauges, and that's it.)

    We're still fine-tuning the API to the library, but in essence the way it'll work is that the developer writes code to select a gauge and needle image from the pre-defined set, defines the scale, and then notifies the gauge through some event handling mechanism that the reading on the gauge should change.

    However, this process is still in a state of flux and may change since we're more striving for ease of use and not necessarily ultimate flexibility. Our goals for the product are not to replicate the major gauge libraries out there, or even to produce the most flexible gauges, but instead to cover the most common scenarios for using them and to do it well, in our inimitable DevExpress style.

  • Smooth, Silky, Sleek, Sweet? Meet DXGrid for WPF.

    You may think that being a CTO of a successful UI controls vendor like Developer Express means that you run the risk of becoming jaded with the new controls, products, and functionality that R&D produce. Does it have that Wow factor? Can they surpass themselves this time? Is it a leap ahead? Heigh ho, let me watch the paint dry.

    Well, let me tell you: absolutely not. I consider myself to be extremely lucky to be in this position at such a time in DevExpress' history. Some of the things we're producing right now has me completely jazzed and amazed. Our developers are simply at the top of their form. I've run out of forehead for my eyebrows to rise any higher. My lower jaw has dented the desk.

    You may now be asking what I've just seen to make me feel this way. Well, lots, but this post is specifically about DXGrid for WPF. I finally had to wrestle the CD out of Ray's hands and dash down the hallway to install it so I could run the demo. (He wrote Go Lakers! with a permanent marker on it. Sheesh.)

    You know, I love our grids' look and feel in WinForms and ASP.NET but this DXGrid for WPF just feels so ultra smooth and silky, it almost purrs. It feels like the clunk of a Mercedes car door versus that of an Ford. It's the quality and heft of an Apple iPod versus a no-name MP3 player. You just want to touch it and experience it. The subtle animations we've added just add to the overall quality feel; they're not jarring or out of place.

    Mere static images cannot do it justice, but, hey, OK, I'll give it a try.

    First off, some bald facts. Tabular list of records, check. Sorting by clicking on a column, check. Grouping by one of more columns by drag and drop, check. Card view, check (with data on both sides, sweet!). Resizing, moving columns by use of the mouse, check. Filtering support, check. Summaries by group or overall, check. Unbound columns, check. Run-time control over column layout, check. Navigate the grid by row or cell, check. Row templates, card templates, check.

    Enough of that. Let's see some images. (Note: click on them to see them full-size.)

    Here's what you might call a standard view. There's a tabular list of records, sorted in ascending order by Last name. The current data row is shown in more detail in the panel at the bottom.

    What the static image cannot show you is the sleek transition of the image and data in the bottom panel as you navigate the rows, or the subtle smooth highlighting as you move the mouse cursor over the column headings.

    Let's go one step further: grouping. For a change, I'll display the grid with the Green theme. Here we're showing the data grouped by Country and then City. I've expanded Canada and then Montreal.

    Here again, the static image doesn't do it justice. Expanding a group slides the rows underneath down and collapsing it again slides the rows up. It's a smooth animation, one that is best experienced as you navigate the focused row up and down using the arrow keys (right and left expand and collapse respectively).

    You can switch into card view easily. Here's the same data in a card view.

    Here's another shot showing the filtering support you can build into the column headers. First a selection of possible values. As you uncheck countries the grid updates underneath automatically.

    Then filtering by quantity. This is fun: drag the slider across and the grid filters and refreshes automatically as you go. Love it.

    A quick shot showing some group summaries. I've switched to the dark lilac theme.

    Notice how this theme styles the groups and the list of records in each group with rounded corners on the top row (and the bottom row, which isn't shown) and on the cell.

    Here's an image showing the cards layout again. I've collapsed some of the cards and I've dropped down the column chooser so show it off: you can drag a column to the group panel to group by that column, or just click on the column to sort.

    Again, it's difficult to appreciate without the animation, but the column chooser in this theme slips down and then slides open when you click on the button. Neat and effective.

    Finally, let's look at the row templates. Here's an image showing the current row expanded into a panel within the grid.

    The animation here is smooth too: as you navigate up and down you get the feeling of using a sophisticated rolodex with the current record seemingly lifting out of the other records.

    Enough's enough. I do hope I've whetted your appetite for our new grid control for WPF. As you may have gathered, I'm delighted with it, gobsmacked as they say in England. The team that produced this are astonishing. But, don't take my word for it, come up to me in the booth at TechEd and I will show it off in its full glory.

    Editing, I hear you ask? Later on, this post is way long enough aready.

    And the beta? A couple of weeks after TechEd is what I'm told. Be patient, now!

  • Paging is good. But throughout the stack, please.

    Sometimes I'm amazed about people's perception of how a web application works, especially when used with advanced controls like our ASPxGridView.

    Let's, if you will, imagine a standard web application with a grid that displays data from some table or view in the database. By default, it's a multi-tier application. There's not a lot you can do about it; it's par for the course. Automatically, you have to think in terms of the individual tiers when you worry about loading, about memory usage, about performance. You cannot think of it as a whole, a gestalt, right up front; each tier matters in its own right.

    At the tier everyone notices, because, well, it's the visual part of the whole thing, there's the display of the grid in the browser. There's some Javascript around so you can use the mouse and keyboard to do things like move/resize columns, change the focused row, and so on.

    Most obviously, there are a couple of things to say about this presentation layer (oops, some architecture terminology crept in there). You want to minimize the amount of Javascript you download because (1) it takes a little extra time to download, and (2) it takes a little extra time when loading the page on the client for the Javascript to be parsed and executed. But most of all you want to minimize the amount of data you download to the browser; essentially all you want to download is enough to display the page in the grid you're looking at. Boiled down to its basics, you just want to download the HTML that displays the table that defines the grid.

    Back in the old days (cue violin music) grids used to download the entire dataset to the browser, together with enough Javascript to float a battleship. These days, vendors are more lean and mean with their controls, recognizing that downloading such volumes of data is counter-productive, especially when the datasets are huge, and AJAX is around to do work in the background downloading data without going through a full page cycle on the server or page refreshes on the client. The pendulum has swung the other way.

    On to the next tier. Well, this is where so many people go wrong and assume there is only one other tier. Sorry, but there isn't. There are at least two other tiers, not one, otherwise we would be justified in calling it a client/server application.

    The first tier is the web server (the bit that executes the ASP.NET application) and the second the database server (the bit that dishes out the data). They are not the same, and you should not consider them the same. In general, they will run on completely different machines, if not for performance reasons then for security reasons.

    Oh certainly, grid vendors -- even us! -- demonstrate their products at shows like TechEd with the web server and database server on the same machine. It's just easier that way. (For that matter, the browser is on the same machine too.) But that is not the primary scenario for a web application in production and so you should take these demos with a grain of salt performance-wise. Remember our slogan: mumble, COMPARE, mumble? The comparisons you're making should involve testing in a similar environment to your production one.

    So let's take these tiers separately. The web server is next in the chain. Here we assume that the server is servicing many clients simultaneously, say 100 to use a round number. Because of the way web servers work, each time a client makes a request the server executes another instance of the web application, sets it up by creating the Page and all its controls, processes the request, renders and sends the reply, tears it down. Sure, the instance may come from the application pool, but in essence this is what's happening. As you can imagine, with 100 active clients the web server is going to be doing a lot of work.

    And note that using AJAX doesn't change the equation too much here. Even with a callback the application is instanced on the server, the Page is created with all its controls, and execution is passed to the control which has to service the callback. Postback processing is avoided, of course. In essence, AJAX gives you a better experience at the browser and smaller HTML payloads, but as regards the server workload it's all pretty much of a muchness.

    The general principles we had with the client -- minimizing data downloads (this time downloading from the database server), minimizing memory usage -- are just as important with the web server. It is pointless and counter-productive and a sheer waste of memory to download an entire dataset from the database server, just so you can perform grouping. Or just so you can filter the data. Or just so you can calculate a summary. Remember: if the control does this kind of processing, it's going to happen with up to 100 separate instances of the application at the same time. Memory usage on the web server is going to go through the roof. Swapping pages to/from the web server disk is going to be excessive. I know that these days 64-bit web servers can have gigabytes of memory, but in the end there is still only so much RAM you can plug in and pretty quickly your bottleneck will be your CPUs instead.

    So, we have to write our ASP.NET applications to be frugal with memory too, the more simultaneous clients we envisage having, the more frugal we should strive to be. Controls we use shouldn't download entire datasets as part of their internal processing, they should page data as and when they need it. Sure, paging when the grid is only displaying records in a list is simple to implement and very effective, but the same should apply when the grid is doing more advanced work, presenting broader analytic functionality for the end-user.

    Note that this principle has nothing to do with LINQ or any other data retrieval process. It's all about how much data is downloaded from the database server. The web application (and the controls it's using) must page its data. After all, instances of the application are being created and destroyed all the time. It doesn't make sense to have a memory-hungry, data-guzzling application since all this work setting it all up takes too much time and bashes performance.

    The final tier I'm going to talk about is the database server. Get this: it has one client and one client only, the web server (lots of connections, maybe, but all asking for the same data). It can allocate as much memory as it wants to cache data for that one client. And guess what? As far as the database server can see, this client just keeps on asking for chunks of data from the same tables and views, bam, bam, bam. This client seems to suffer from extreme short-term memory loss. So the database server caches the heck out of the data in order to fling it back to the forgetful client as quickly as possible.

    And what's more, the database engine has been thoroughly optimized to process analytic type queries far better than you or I could code up on the web server. Grouping? Should be done on the database server. Filtering? Ditto. Summaries? Most assuredly. Furthermore, you can tune the database server so that queries that run most frequently are optimized. It doesn't make sense from a processing viewpoint or a performance viewpoint or a networking viewpoint to issue a SELECT * query to the database server, load the entire result set into a List<T>, and then use LINQ to filter that list. "Hey, at least we can tell our customers we're using LINQ!"

    This layman's analysis of the multi-tier aspect of web applications reinforces and validates the work we did with the ASPxGridView, work that no other vendor has done. We deliberately wrote a data controller that runs in conjunction with the grid code on the web server to page data from the database server. This data controller works with standard "tabular list of records" type views, it works with sorting and grouping those records, it works with filtering the records, and it can calculate the correct summaries both overall and per group. All without reading an entire dataset from the database server into the web server's memory.

    If you are writing a web application you owe it to yourself to understand how the controls you're using process the data they display. Ask your vendor: when the grid is grouping records, is this processing done on the database server or on the web server? (If your grid vendor is DevExpress, the answer is: on the database server of course. Duh.) Turn on tracing in SQL Server and then test your application. Ignore the marketing-speak from the vendor and watch what the controls are really doing as you use the application. Then, decide.

  • We're a finalist (squared) with Best of TechEd awards

    Heh. So we got an email this morning with some exciting news and, as it happens sometimes, we each thought one of the others would blog about it. So it wasn't.

    I'm hereby grabbing the baton and running with it. Cue evil laugh...

    Windows IT Pro has announced the finalists for its Best Of TechEd 2008 awards. (If you remember we won one of the Tech-Ed Attendee's Pick Awards in 2007 with DXperience ASP.NET.) We've made it through as a finalist to two of the four awards:

    Database Development Award: we're a finalist with XAF (eXpressApp Framework).

    Software Components & Middleware Award: we're a finalist with DXperience.

    We have our fingers crossed to actually win one (or both!) of the awards at the show. This involves a visit from the judges to the booth where we can show off the products, so, no pressure or anything. Phew!

    Score!

  • Get yer screenshots here!

    I see Ray trumped me with the announcement of our latest product, secret up until now: the DevExpress Silverlight Grid. So secret that we don't really have a good name for it yet. But I digress...

    In the video he posted, if you can get around the shock of seeing yours truly on YouTube, you'll see a couple of screenshots of the grid in the background. Because of the resolution of the standard YouTube video is too coarse, it's hard to discern any detail.

    Well, phooey to that. I went to our internal grid demo site and snapped a couple of screenshots, full size. Feast your hungry eyes on these:

    AgDataGrid-Groups

    This one shows our advanced grouping technology in full force, grouping over two columns. Not shown is that the drag-and-drop of column headers into the grouping panel works exactly as you'd imagine. Also not shown is the subtle animation we've added to the column and the grouping headers. The grid feels "alive" in some way.

    AgDataGrid-Preview

    This shot shows that the preview mode is fully available already (excuse the compressed nature of the details). Not shown is the way the image automatically grows when you hover over it, shrinking the description panel to the right.

    AgDataGrid-Templates

    This one shows that we have templates for cells. In particular, I'm showing the dropdown calendar that appears when editing a date value. So, yes, we have editing capabilities in the grid already.

    I hasten to add, as I said in the video, that the reason our progress for this grid seems so much faster than the progress for our grid for WPF is that we've leveraged and reused all the work we'd already done for that latter grid. Since we couldn't use the standard WPF classes to get the advanced paging and user experience capabilities we needed for the WPF grid, we had to implement a lot of infrastructure and that infrastructure was easily ported over to Silverlight 2. If you like, by looking at the Silverlight grid screenshots here, you can see that the WPF grid is very much more advanced.

    If you want to see the WPF and Silverlight grids in action, be sure to visit our booth at TechEd in Orlando, from June 3rd through the 6th.

    And, of course, step by the booth to hear our new licensing plan for the Silverlight Grid. You'll like it.

    (Aside: I think our grid team have been playing too many old Japanese anime games: "The test do here" indeed. Anyway, it shows the fact that I just ripped these shots without a lot of marketing clean-up.)

  • "Paging grid team, paging grid team..."

    Late last week, after listening to and reading the feedback we'd been getting from our customers, the main architects of the ASPxGridView, Mike and Andrew, added support for the default LINQ paging parameters to the grid. After some further testing over the weekend, they've now merged their changes into the main branch.

    These changes will be available in the next minor release of DXperience, version 2008.1.4, and obviously in subsequent versions.

    There will be an option to turn off our advanced paging capabilities (those which are optimized for our superior grouping, filtering, and summary facilities) and turn on the capability to pass default LINQ paging parameters to the ExecuteSelect() method. We're still discussing the name of this property so I can't reveal it just yet.

    In this mode, the grid will essentially just function as a tabular set of rows. So if that's your main user scenario, you can set this property true — its default value is false — and the grid will just present a paged set of rows using the default LINQ paging statements.

    If however you want the best-of-breed grouping, filtering, and summaries afforded by our paging technology in order to give your users the richest experience available anywhere and the ability to analyze data in the most performant manner, then leave this property at its default setting and party on.

  • Extended datasource APIs with the ASPxGridView

    Recently there have been a number of technical questions raised about how the ASPxGridView works, with large datasets in general, and with LINQ in particular.

    Let's go back to basics first, and especially the user experience that our grids afford. I'm not talking here about how to develop with them, what you have to link up and where, just the end-user features and benefits. For a start there's sorting (click on the column header), grouping (drag the column header to the grid's grouping panel and drop), filtering (type in a simple criteria as text). There's also extra information that can be shown: the column and group totals and so on.

    Unbeknownst to the user but still crucial are the paging capabilities of the grid: the user doesn't have to wait extended lengths of time for data to be shown in the grid as they manipulate the grid. Of vital importance with this paging is that it still works well when the user is grouping records. By that I mean that if the user groups on City, say, and the grid displays a page of cities, all collapsed, then the paging subsystem only returns those city records, and not all the detail records making up the groups. Expand a city, and the paging subsystem returns the records needed to expand that group and fill the grid.

    So, back at the beginning of last year (2007), when we were designing this new grid, we determined pretty quickly that we'd need an intelligent paging subsystem that could help with all the user experience scenarios we envisaged. In particular, we really wanted to make sure that our story with grouping was compelling, since the grids out there just weren't. And since we had much of the functionality in XPO (eXpress Persistent Objects — our ORM solution — already, it made sense to use it, and so the famous IListServer interface was born along with its first implementation.

    A lot of customers saw that IListServer was good, but they wanted other implementations to cover other data sources and scenarios. At the beginning of this year (2008), we released our implementation of it that used a LINQ provider, and thereby supporting all manner of data sources.

    Now, with LINQ being available, the question arises whether we should even do this intelligent paging at all. The standard LinqDataSource does efficient paging, so why not use that? Cut out the middleman!

    As it happens, although it does sound like an attractive idea, it won't work. Let me rephrase that. Not "work", but "work well enough". In the last couple of days, as an experiment, the guys on the team implemented support of the standard LinqDataSource inside ASPxGridView. And it works very well for the basic feature of paging records into the grid. It doesn't work at all well for grouping and filtering, and certainly doesn't work for creating summary or total values.

    So what should we do? Should we add an option to switch the grid between this hobbled version and the fully functional version (I'm thinking about it from the end-users viewpoint here)? Or should we just accept that our grid's end-user functionality is of prime importance, even if the developer has to jump through a couple more hoops to get there?

    Of course, this is not the final word. We'll continue to investigate this issue to see if there is some other solution we can explore. So, even if the current answer is "business as usual", stay tuned.

1
2
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners