Teun.ToString()

Update: I have enough proof readers now. Unless you really, really, really want to join, don't bother volunteering anymore. Thanks to the people who are helping out!

I took a few days this week to finish my work on the 'web parts book' I have been working on every now and then for the past year. I was hard to keep my focus on it; respect in hindsight to the editors at WROX who hurried me into writing the VB XML book in three months.

I now feel that I have covered most of the ground, using slightly more than 100 pages. That is the number of pages I initially though of as 'just right'. I do feel that the text needs some polishing; it may be to dense here and there and need some expanding. Also the source code download must be tidied up. But I think it is ready for proof reading.

If you are interested in ASP.NET developement and Web Parts, feel freeto send me an e-mail at teun[at]duynstee.com. Please state your background and I will send the first X people a PDf of the current state of the book. Proof readers that provide serious feedback will also receive the final version when it is ready, of course.

Labels: aspnet_webparts

This thread on ASP.NET forums called my attention to a fact about ASP.NET 2 web parts that I had never noticed before. When you set AllowClose on a web part to False, the web part infrastructure will hide the Close verb from the user. The setting will not only prevent the action of Closing with an exception, but will also hide forbidden options in the UI.

However, when you set AllowEdit to False, the Edit verb does not disappear; when you select Edit, the EditorZone will not display any tool part, but you can still switch to edit mode. Why would that be?

I checked the code with Reflector and indeed, in the WebPartChrome.ShouldRenderVerb method, the logic seems to make and exception for the Edit verb: the right display mode is checked, but no check for the AllowEdit property on the web part. Also, the designers of the framework seem to have intentionally made fixing this very hard: you can create a custom subclass of WebPartChrome, but

• ShouldRender is private, so cannot be overridden
• FilterWebPartVerbs, which uses ShouldRender is virtual, but if you override it, you cannot add or remove verbs from the WebPartVerbCollection the base implementation returns, because it has no Remove method and Add is marked internal
• You cannot subclass from WebPartVerbCollection to add these features, as it is sealed
• You cannot use the WebPartVerbCollection(ICollection) constructor, because the verbs that are created by the WebPartZone all have ID "". The copy constructor will refuse to create a collection with duplicate IDs (except by usings the internal Add method, which is fine with duplicate IDs)

It escapes me why it would be so bad to have the opportunity to remove verbs that were added by the base implementation and I am still wondering why we should not hide the Edit verb from users when editing is not allowed anyway.

It all looks a bit sloppy to me.

Labels: aspnet_webparts

"I might as well put it out there to trick myself into finishing it"

I have been working for a wile now on a book on the Web Part Infrastructure in ASP.NET 2.0. I had been working on this before, when the software was still beta1, but somewhere along the way, I lost interest (and discipline) and I stopped working on it. Now, I have taken the old chapters, the old sample code, converted it and started writing again.

The aim is to write a small book (appr. 150 pages) on just the Web Part Infrastructure. So no 700 page tome with a lot of well known information, this book should really explain the subject and then dive in deep.

I have no publisher (yet), but I intend to publish it through lulu.com (or one of their competitors). That way, I will never sell the numbers I used to when I published through Wrox press, but I will at least get most of the cover price myself. And people who want the book can get a nice printed book sent home for a very reasonable price or a PDF for even less.

But that will take a few more months of work. For now, I figured I might as well put some of the chapters out there. I created a PDF of the start of the book and a few chapters. Especially the chapter on Web Part Connections is not a very wellknown subject. Maybe it is of use to some people out there.

Download the preview chapters here. Note that the work is still very much in progress and that this PDF will be updated with newer/better versions in the future.

Labels: aspnet_webparts

The Web Part Infrastructure in ASP.NET 2 offers a very neat system that allows users to configure and personalize parts of a web page, dragging the web parts to their preferred position, etc... When you are administering a web site that works with web parts, you'll soon want to know how many of your users actually personalized their page. And what settings did they use? Surely, you can find this out by inspecting the personalization database? Wrong.

The personalization of all web parts in a web part page is stored in a binary field in the database. This field holds the position and configuration of all web parts on the page and also which extra parts a user may have added to her page. All this information is not readily available.

Last year, I wrote a post detailing how the WebPartManager stores its information in the personalization system and I created a small library that could be used to read and change the configuration of a page from code and without the ASP.NET context available. This was working with beta 2 of ASP.NET and sadly, the format of the storage later changed in anumber of very subtle ways, leaving the library broken.

I have now updated the library to work with the final release (it turned out to be difficult to have it work with both versions). It comes with a little sample program that shows how to read the binary info from the database, make a few changes and save it back to the database. This is the code of the sample program:

string connstr = "Data Source=.\\SQLEXPRESS;AttachDbFilename=\"C:\\projects\\Teun\\...\\ASPNETDB.MDF\";Integrated Security=True;Connect Timeout=30;User Instance=True"; PerUser data = new PerUser(); Unformatter.PerUserTableAdapters.aspnet_PersonalizationPerUserTableAdapter adapter = new Unformatter.PerUserTableAdapters.aspnet_PersonalizationPerUserTableAdapter(); adapter.Connection = new SqlConnection(connstr); adapter.Fill(data.aspnet_PersonalizationPerUser); foreach (PerUser.aspnet_PersonalizationPerUserRow row in data.aspnet_PersonalizationPerUser.Rows) { PageState UserState = new PageState(row.PageSettings, PersonalizationScope.User); UserState.Locations["Weather"].ZoneID = "RightZone"; UserState.DynamicParts.Clear(); string NewBlob = UserState.Encode(); byte[] binBlob = Convert.FromBase64String(NewBlob); row.PageSettings = binBlob; } adapter.Update(data);

As you can see, I use a typed dataset and the automatically generated TableAdapter to load the byte array of configuration from the SQL Express database, then I create a PageState object with this data. In the PageState, I make two changes: I delete all dynamically added web parts from the page and I set the web part with ID Weather to the RightZone. Lastly, the updates are stored in the dataset and persisted to the database.

The library and sample program can be downloaded here. No warranties.

Labels: aspnet_webparts