Today a newsgroup post reminded me that I did not yet publish the necessary changes for my Http Module that corrects the Ugly MCMS URLs caused by ASP.NET postbacks when ASP.NET 2.0 master pages are used.
The HttpModule I published earlier does not work in this scenario as it relies on the fact that a HtmlForm control exists in the root control collection.
This is not the case for ASP.NET master pages! Here you will find the HtmlForm control in a child collection of the MasterPage control.
And an additional problem occurs: with MasterPages I found that the ID of the HtmlForm control will not be the ID rendered in the html content. So we cannot retrieve the ID in the same way as with ASP.NET 1.1 or with ASP.NET 2.0 without master pages.
This allows us to simplify the OnInit method of the HttpModule:
A small caveat exists: this version of the httpmodule is no longer compatible with ASP.NET 1.1.
Was it my post in the news group that prompted you? :-)
indeed it was your post.
how to inherit and override the AuthoringSaveNewAction abstract class.
the comment section is only intended to be used for question or comments for the article.
Please post general MCMS questions into the public newsgroup microsoft.public.cmserver.general
I will answer them there.
How would I maintain query strings and control state/view state during post backs? I notice that it takes the form name and replaces the action with the posting Url.
Hi Jennifer, the behaviour with this module should be the same as without it.
Hope you like it, let me know your toughts.
we are creating and updating the posting from admin. if i dispose the CmsApplicationContext i am getting this error.
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
If i didn't dispose i am getting ODBC error.
what the issue?
please open a support case for this. This is not a known problem.
How strange. I just found this little (important) fix, and couldn't understand why I couldn't make it work. That is, until I realized it only works when using currentPage.RegisterClientScriptBlock(...), not when using the more correct currentPage.ClientScript.RegisterClientScriptBlock ??? I tried putting both this.GetType() and currentPage.GetType() as first parameter, but neither worked.
Do you have any idea why this is?
the reason is that MCMS itself uses currentPage.RegisterClientScriptBlock to register a different script using this id. My script overwrites this script. Using the other method will not overwrite the script from MCMS but add it as additional script which will not lead to the desired results.
Ah, okay. That makes sense - thanks!
As some of you already noticed: GotDotNet is now down and the code samples previously hosted there have