After a long silence... here we go again!!

And what better to come back than with a nice-long history?

We have this Commerce Server Site that uses Moss as it's content manager. We will have (someday) content-only pages, but for now, we have data-driven catalog pages. They are still Moss pages, that contain web parts that display catalog information based on what there is in the url.

Pretty basic stuff, uh? If it wasn't because we are using UrlRewriting .Net to "beautify" our urls I think we are not doing anything exceptionally smart.

And even so, url rewriting is not that big deal. It's not more than an HttpHandler, right? Well, it has its quirks that we had to overcome (postback issue that UrlRewrinting .Net solves nicely out-of-the box, but we had to hack because Moss request handlers are not instances of Page)

We thought we had everything under control but no, we didn't. When testing, I realized that none of the Content Editor Web Parts were working. "Cannot display web part content", they complained, but they could; except that when they complained "cannot save the content of the web part", they were "truthing" and the content wasn't being saved.

That only happened when we were in a virtual url content, if we edited the same page using its non-virtual url (old-fashioned /Pages/mypage.aspx). It was clear then, that our pretty urls were doing harm to CWP.

I have forgotten how painful is getting back to a language that you once (more or less) "mastered" (but you don't anymore). And I thought that javascript is not such a hell to debug with new tools (FireBug amongst others comes to mind). But alas! Firebug cannot be used because web part edition is completely different in FireFox as no rich text editor helps us.

I did not want to mess around with browser header or hacks of that sort. I wanted to get the work done and find what was wrong.

I already made this post longer that it should, so I will go straight to the point. In one of the .js (Ie55sup.js) files, queries against the Web Part Web Service are performed in order to get (and save) the content of a web part instance. One of the arguments  is the url of the page. And since it's using document.location.href in order to get that url, the virtual url was being passed, and the web service was not able to find the web part, thus the error. The same was happening when saving the web part content.

Solution: hack both the custom rewriting rules and the .js file with the help of a hidden field.

• Custom rewriting rules need to be changed so that they can populate an entry in the HttpContext.Items dictionary with the non-virtual url
• A custom hidden field needs to be added to the master page, and that hidden field will contain the non-virtual url that it's stored by the rule.

The Moss .js file needs to be changed so that instead of getting the url from the document.location, it first tries to find the hidden control and get its value, and then passes it to the web service call. This is more fragile part of the hack solution as whenever a new patch Service Pack is applied, we may need to reapply the changes to the .js file.

One more issue: I spent like an hour banging my head against the wall (not literally, no animals were harmed during the shooting), because I was able to initialize the CWP but was not able to save the content with aforementioned technique. It turns out that the name of the parameter for the save web service call, is cased in a different way. So beware casing and web service calls from javascript.

Hope it helps anyone