New ASP.NET Web Resources Control Feature in Whidbey

Nikhil has posted two blogs on the new web resources feature in Whidbey.  At a highlevel it provides a nice way for control developers to encapsulate resources for their controls within a compiled assembly (as resources), and then be able to leverage them at both runtime and design-time without having to copy files all over their dev machine and web-server (for example: for images, scripts, etc).

You can read both articles here:

http://www.nikhilk.net/Entry.aspx?id=23

http://www.nikhilk.net/Entry.aspx?id=24

Below is a full screen-shot of what the WebResources feature enables at design-time for the new TreeView control.  Note how the images for the nodes show up both on the design-surface and within the auto-format dialog -- these aren't on the file-system anywhere, instead they are pulled directly from the control's assembly (caveat: this only shows up with beta builds -- it wasn't enabled yet at the time of the alpha).  The same approach works at runtime (the runtime piece works in the alpha -- just the design-time part that isn't done yet).

In general, I'd highly recommend subscribing to Nikhil's blog if you are interested in server control development.  RSS feed at: http://www.nikhilk.net/Rss.ashx?id=1

6 Comments

  • But why o why is the sitemap xml tree only readable from a FILE and thus can the treeview only be bound to a FILE, not to an XML tree build at runtime? With a tree at runtime, it is way more useful for CMS's which do not have a static sitemap.

  • Ahh -- but that is where you are wrong... ;-)



    The Whidbey Site Navigation system is provider driven -- meaning you can swap in any underlying site map abstraction you want (including a CMS system or just a plain database).



    The SiteMapDataSource binds directly to the Site Navgiation System, and the TreeView (and Menu and SiteMapPath control) bind to it.



    This means that you can easily swap in an alternative site map provider to your site (just update the config file or use the admin tool to point to the alternative provider), and all of your pages will then be driven off of it -- no code or page changes required.



    Hope this helps,



    Scott

  • That's awesome news Scott :) I saw a presentation at the dutch .NET usergroup about this and they said it was file driven and I couldn't believe it how MS would make such a mistake :) Thanks for clearing that up :)

  • I wonder how static/dynamic this sitemap thing realy is. We at DNV have a database containing 5000 ships. Each ship have from 100-2000 web pages each with information about them. (I think this is quite the same as somebody with a large product database).

    The data (and thus the exact pages) is constantly changing, at least a bit. For instance, one boat get a particular pump installed. This creates one or more new pages with the information about this particular pump on this particular ship (type, tests, drawings, etc)



    OK, so here is the question:

    Is such a system where the amount of pages are very large, and constantly changing, can the sitemap system be used?

    Seems to me that every part of the system must be provided "on demand", there and then, for it to be usefull.

  • Hi Tor,



    You can build a SiteNavigation provider that is driven off of a database instead of a configuration file. You could then use the SQL Cache Invalidation feature to cache the TOC, and then dynamically regenerate it everytime the ships database in your sample above was changed.



    Hope this helps,



    Scott

  • Hi Scott



    So we would derive from the sitenavigation class and override all of the items within, correct? Then how do we tell our Treeview to bind to that custom provider?



    Thanks

    Matt

Comments have been disabled for this content.