I designed a custom IIdentity to support an enterprise integrated identity for my client. We were having problems that Cassini would fail with a SerializationException: Type is not resolved for member... error.
The fix is here: Check out John Lewicik's comment to this post by Rocky Lhotka.
I got bit recently and squandered time because I didn't know that the VS2005 setup projects have adequate support for ASP.NET applications. Scott Guthrie has a post that shows you how and how to to avoid some pitfalls.
Don Box shares links from two ASP.NET leads on the new Atlas Ajax technology. Read them or miss out!
Update: sorry, forgot link to the article.
This C|Net news article introduces Atlas, a client side object model for JavaScript (read DHTML) coding. My readers may know that I believe that the end of Ajax, WSRP, and Portlets leads directly to Smart Clients. It's interesting that the article itself calls JavaScript spaghetti-code. Why write spaghetti code when you could be doing Avalon+Indigo? None, unless you want to support the minority (is this true?) of systems that won't run them.
Here's a
great post by MVP
Rick Strahl on how to client-side callbacks (Ajax) using the built in features of ASP.NET 2.0. Looks like more plumbing and glue are needed for it to succeed in a large project.
If you look in the nooks and crannies where I work you can plenty of Web Portal servers lurking. WebSphere Portal is a standard for many groups. However a group working on an Oracle platform would naturally gravitate to the Oracle Application Server Portal, for example. Certainly groups that are targeting the .NET platform are gravitating to SharePoint Portal Server 2003. Moreover since SharePoint Services is “free”, it has the tendency to grow like a weed. Not your application portfolio manager's greatest friend.
But wait a minute! OASIS has solved the problem for us! They've defined the Web Services for Remote Portlets standard and all the major portal server vendors have vowed support (see WSRP link). Here is Microsoft's press release promising support. Now all the portal servers' Portlets and WebParts can seamlessly talk to each other. Problem solved! Or is it?...
That Microsoft's current WSRP Consumer and Provider are GotDotNet workspaces, does not exactly engender the greatest confidence in their commitment to the spec. Moreover, this Usenet thread comment by Dino “Gimmesomathat” Chiesa, the MSFT PM for developer tools, makes me doubt that WSRP will ever rise to the level of “Product”, at Microsoft. His message? Use Web Services.
Does anyone think WSRP will actually work?
One of the benefits I have now that I'm a “Corporate Architect” is that I don't just deal with the technology I'm currently working on. Now I have to know everything all at once. Whether that means I'll be rust free or just worn out remains to be seen. :-)
A colleague was working on a custom ASP.NET control that was accepting DHTML drop information. He wanted to be a good citizen and use the Page.GetPostBackEventReference method. This method produces a string that is called from the client side, usually as a control event handler.
However, in his case, he needed to get the drop text dynamically, so his event handler called a function to get that. He also passed the result of GetPostBackEventReference, and called eval on its value to do the post back.
Well, that's fine. However he wanted to pass back the value of the dropped text. Since this is determined dynamically by the user GetPostBackEventReference is useless. It's output is:
"__doPostBack(<Mangled CtrlID>, <static string text>)"
The whole idea being that the identifier of the post back routine and the server-side identifier of the control should be hidden to the script writer. This works great as long as the information you want to post back is static.
He asked the “Right Way” to do this.
It's interesting that Dino suggests to just set the hidden post back variables yourself and avoid __doPostBack entirely. (See Handling the Server-Side Event) Not exactly great tasting from the encapsulation point of view.
I'm guessing there is really no good way to do this. If you look at the function's output, we've got three four bits of data:
- The function identifier
- The function signature
- The control id
- The data argument placement
You would really need to have an abstraction method that would output a function that would take the data argument and embed the call to __doPostBack. That doesn't taste good either. It appears to me that if you want to be a good citizen the control should manage a hidden field and pick that up when the RaisePostBackEvent method is called. Look here for more info on how to do that.
Rats. The RaisePostBackEvent argument is useless for dynamic data.