ctodx

This Blog

News

Favorite Posts

Archives

September 2008 - Posts

  • Dogfooding our ASP.NET controls in SharePoint - part 1

    Over the past couple of months, we've been creating and using an internal company portal site using the Microsoft Office SharePoint Server (MOSS).

    For several years now we've used a simple wiki to do the job of tracking what the company is doing, or should be doing but isn't, or is doing but shouldn't, or could be doing but doesn't have the resources for, or any other combination. That's been a pretty good solution over the past few years but this year we've come to the conclusion that a wiki's very freeform-ness translates a little too quickly to the execution of our company plans and roadmaps. Hence, we made the decision to make this stuff more rigorous and have settled on SharePoint to track it all.

    Of course, there was an ulterior motive to this decision: we get a lot of requests for how to embed our ASP.NET controls into MOSS and what better way to accomplish that than too actually do it and use it ourselves.

    image

    This screenshot shows one of our experiments, one that we're using in the Marketing area of our portal: replacing the standard left-hand navigation bar with ASPxNavBar. It uses our BlackGlass theme and you can see the collapsible headers and sections of the navigation bar quite clearly. And we put it in the Marketing area because they're not the developers, so we'll get some real feedback...

    So how's it done? As it happens, replacing an existing navigation pane with an ASPxNavBar is pretty simple: just a matter of dropping an ASPxNavBar control onto the page and binding it to a data source that supplies the quick launch links.

    First, we open our site in Microsoft Office SharePoint Designer and check out the default.master page:

    image

    We'll manually register the ASPxNavBar and its assembly at the top of the page:

       1: <%@ Register assembly="DevExpress.Web.v8.2, Version=8.2.4.0, Culture=neutral,    
       2:    PublicKeyToken=9b171c9fd64da1d1" namespace="DevExpress.Web.ASPxNavBar" tagprefix="dxnb" %>

    As you can see, the v2008 vol 2 version of ASPxNavBar will work in MOSS quite nicely; no need to wait for v2008 vol 3.

    Now find the default navigation pane <Sharepoint:SPNavigationManager/> named QuickLaunchNavigationManager, and replace it with our ASPxNavBar:

       1: <dxnb:ASPxNavBar       
       2:     EnableViewState="false"       
       3:     runat="server"       
       4:     width="100%" >
       5: </dxnb:ASPxNavBar>

    We'll bind it to the list of quick links via a SiteMapDataSource like so:

       1: <asp:SiteMapDataSource 
       2:     SiteMapProvider ="SPNavigationProvider" 
       3:     ShowStartingNode="False" 
       4:     id="MyQuickLaunchSiteMap"
       5:     StartingNodeUrl="sid:1025" runat="server"/>
       6: <dxnb:ASPxNavBar 
       7:     DataSourceID="MyQuickLaunchSiteMap" >
       8: </dxnb:ASPxNavBar>

    And we are done with the swapping part of the exercise. However, before the control can be used, it must be deployed on the target server and registered with SharePoint as a safe control.

    Deploy the following assemblies to your server:

    • DevExpress.Web.v8.x
    • DevExpress.Data.v8.x

    and GAC them. Then open your SharePoint website's web.config file and register them as "safe" by adding the following in the SafeControls section (note that your assembly version may be different).

       1: <SafeControl Assembly="DevExpress.Web.v8.2, Version=8.2.4.0, Culture=neutral, PublicKeyToken=9b171c9fd64da1d1" 
       2:     Namespace="DevExpress.Web.ASPxNavBar" TypeName="*" Safe="True" />
       3: <SafeControl Assembly="DevExpress.Data.v8.2, Version=8.2.4.0, Culture=neutral, PublicKeyToken=9b171c9fd64da1d1" 
       4:     Namespace="DevExpress.Data" TypeName="*" Safe="True" />
       5:  

    Now, onto the problem of applying themes. By far the easiest way to do this is to create a simple web site in Visual Studio, drop the control on the designer, theme it, and then copy/paste the generated theme files and aspx code into your SharePoint web site.

    For example drop an ASPxNavBar control on a page and invoke AutoFormat from the smart tag:

    image

    Theme it using the BlackGlass theme:

    image

    At this point all the necessary theme files will have been generated in the \BlackGlass\Web folder. Copy that folder to your site's "_themes" folder and adjust the paths of the ASPxNavBar control accordingly:

       1: <dxnb:ASPxNavBar 
       2:     EnableViewState="false" runat="server" 
       3:     width="100%"
       4:     DataSourceId="MyQuickLaunchSiteMap"     
       5:     CssFilePath="/marketing/_themes/BlackGlass/Web/styles.css" 
       6:     CssPostfix="BlackGlass" 
       7:     GroupSpacing="3px" ImageFolder="/marketing/_themes/BlackGlass/Web/">
       8:   <CollapseImage 
       9:       Height="17px" 
      10:       Url="/marketing/_themes/BlackGlass/Web/nbCollapse.gif" 
      11:       Width="18px" />
      12:   <ExpandImage 
      13:       Height="17px" 
      14:       Url="/marketing/_themes/BlackGlass/Web/nbExpand.gif" 
      15:       Width="18px" />
      16: </dxnb:ASPxNavBar> 

    And that's it. We get the view in the first image above.

    We'll be bringing out more information about using our ASP.NET controls in MOSS over the coming days and weeks so that you too will be able to improve the usability of your SharePoint sites. Stay tuned.

  • Internet Explorer continues to slip

    Last week, I was chatting to a friend who'd posted in his journal that IE6 -- yes, 6 -- had 32% of the browser market. To me that figure seemed way too high (a third of all surfers are using IE6? We're in deep trouble, guys) and I asked him where he'd got it. It turns out that he'd quoted the IE6 share for 2007 from this wikipedia page (look for the sub-heading "Market share by year and version" about half way down). Both he and I then checked our own stats to find out that IE6 over the past month or so had roughly 15% browser share. To me that still seems high, but then again it takes all sorts; I'm a Firefox user through and through.

    The interesting point we both noticed was that IE, as a whole, had less than 50% browser share, with Firefox being at roughly the same spot. I could even report that nearly 5% of the visitors to my site were using Chrome.

    The point here is that, if you are targeting the Internet with your web application rather than just a closed environment like a company intranet, you can no longer assume that the majority of your visitors will be using Internet Explorer. In fact, I would go even further: you should be actively monitoring your web stats to see what people are using, both in terms of OS and browser, and making sure that the vast majority of your visitors get a good experience no matter what combination they're using. Losing potential customers because they happen to be using Firefox rather than IE is a short-sighted tactic indeed.

    Tim Anderson reports today that the jQuery site looks scrambled to him in IE7 (it doesn't for me), but this goes to show that the main game in the browser town these days is not only HTML/CSS rendering but also JavaScript compatibility. If you've only just logged on and are wondering what's so special about jQuery, both Nokia and Microsoft announced Friday that it would become part and parcel of their web application platform. Yes, you'll be getting the open source jQuery library with your Visual Studio, the first time Microsoft will ship an open source library with its offerings (I remember the arguments way back when about including NUnit with Visual Studio, so this is a momentous occasion).

    Of course, we at DevExpress have been making sure for a very long time that our JavaScript doesn't just work in IE. We recognized early on that we had to support more than the one browser with our controls and libraries and we continue to make sure that we support IE, Firefox, Safari and now Chrome. You can rely on us and our controls to make your website as compatible as it can be.

  • Javascript gets new lease of life

    Over the past week or so, I've been using the new Chrome browser from Google -- not because I happen to be a geek fashionista and have to have all the latest gadgets, but to check out its JavaScript interpreter performance with real-world applications, including our own ASP.NET controls.

    You may not have noticed but in the arcane world of JavaScript interpreters there has been some remarkable changes in the last few months. In essence, JavaScript interpreters have been gaining just-in-time compiler features, or JITters, just like we have in .NET.

    This, to me, or indeed to anyone who has dabbled in JavaScript, is nothing short of amazing. JavaScript is a dynamic, weakly-typed, interpreted (or scripting) language with some very strong functional language features, despite its name implying Java and hence being statically-typed and imperative. The thought that this "freeform" quality can be compiled, and not only that but compiled just in time, seems contradictory and reeking of magic.

    Luckily, not everyone is as gobsmacked as me, and they have been working hard to improve the performance of interpreting and executing JavaScript code. After all, most of the Web 2.0 sites out there are heavily using some form of AJAX, where the "J" stands for JavaScript, so a simple way to improve everyone's website performance is to improve the execution of the code.

    There have been quite a few developments in the JavaScript interpreter space:

    • TraceMonkey: this is the new JITter/interpreter for the upcoming Firefox 3.1. Firefox 3.0 and earlier use an engine called SpiderMonkey. (In essence, TraceMonkey is SpiderMonkey plus tracing of the code so that sub-method blocks can be nanoJiTted.)
    • V8: the new JavaScript engine in Google Chrome.
    • SquirrelFish: the JavaScript interpreter for Safari 4.0, used in WebKit, the underlying HTML renderer in Apple Safari. (Confusingly, Google Chrome uses WebKit for rendering, but V8 for JavaScript code execution.)
    • Futhark: the engine for Opera 9.5 or later.

    The interesting thing about these new interpreters is that they all blow IE's interpreters out of the water. And that includes IE8 beta, as well as IE7. It's becoming clear that if you want superior JavaScript performance for your web apps, you need to specify ABIE (Anything But Internet Explorer).

    Currently there are two main JavaScript execution benchmarks: SunSpider (WebKit's benchmark for pure JavaScript, that is, no DOM processing), and the Google Chrome benchmark (again for pure JavaScript with no DOM). The difference between them is that the Chrome benchmark is very recursion intensive, something that TraceMonkey cannot do well at this stage. In Google's defense, using the DOM for anything intensive is going to be very recursion-oriented. (There is a new benchmark being developed that mixes in DOM processing as well, Dromaeo, but it's in its early days yet.) All the beta JIT engines perform extreemly well with these benchmarks, with V8 doing best at Google's own benchmark. IE is a no-show in some of the results since its interpreter has a tendency to crash with some benchmarks.

    I do note that the fastest JavaScript interpreters/JITters are still in beta, but the whole area certainly looks very promising. I must admit that I hope the JavaScript execution engines become standalone, so that you can use your favorite browser and plug-in the engine you prefer. Perhaps a vain hope, but a hope nevertheless.

    As for Chrome, and speaking as a user, it certainly seems to be very responsive on AJAX-abundant websites, including our own website, demo pages, and community site. The rendering speed is excellent too.

    I look forward to yet more improvements in JavaScript performance. Certainly, as Scott Hanselman acknowledged, Silverlight may not yet have the upper hand yet in web applications.

  • Windows and Web Charts: All About Series

    I'm back with a quick video about series in XtraCharts.

    The first time I looked at XtraCharts, I was a little confused what a Series Template was and why you should use it (or, for that matter, not use it). In essence, the Series Template is great when you have a set of data you want plotted where each data point in the set is defined by three values or dimensions. In other words: you have 3D data for a 2D chart. The Series Template enables you to set one of the dimensions as the series data member, and then XtraCharts will automatically divide up the set of data along that dimension into a collection of separate series. The individual series are all then plotted in the same diagram as a set of charts.

    But that ease-of-use means that you lose some flexibility, and so XtraCharts also provides the ability to define the series manually yourself.

    image

    In this video I show the same data plotted using the Series Template method and using the manually-defined Series collection method to produce the same chart. And, to ring the changes, I used a web application instead.

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