-
-
Like many of you I guess, I am agile and extreme and I didn't know. I also realized that the first distributed application that I designed back in 1994 was already SOA-oriented--for what I can say I know about SOA today.
Wherever I turn to read about SOA, I see that the adjective asynchronous is regularly associated with SOA descriptions. Sure, SOA and async operations seem to be a perfect duo. My 2-cent question is: what about inherently synchronous operations? I'm far from saying and even thinking that one should embrace a design technology altogether, so I can easily imagine portions of distributed apps based on pure SOA services and portions designed according to other design patterns.
I'm confused because I see lots of articles and papers around that emphasize the benefits of SOA. But these benefits seem to assume asynchronous operations. What about the remainder--read, synchronous operations? Or, more likely, what am I missing here?
-
-
According to this authoritative post, I dare say it's now official: the future of SharePoint passes through ASP.NET 2.0 Web Parts. To me, this is GREAT news and perhaps the right spark to make SharePoint burst and gain even more success.
Here's an article that attempt to describe differences and features.
-
-
Imagine your page includes a drop-down list control filled with 300 country names. Do you think it will be persisted across postbacks? To this question, my answer would be NO. Wrong. The right answer is true. And where do you think all that stuff is stored across postbacks? In the viewstate, of course.
You may have heard (from me, for example) that data-bound controls don't persist their data source to the viewstate. For list controls (drop-down, checkboxlist, listbox), this is not exactly true. When you call DataBind on any of these, the data source is broken into pieces and loaded into the Items collection. And the Items collection is persisted to the viewstate.
To save your pages something like 10KB of viewstate per each country-list control in the form, you have to:
- Disable the viewstate for the control
- Retrieve the list of country from the cache and bind
You still have one problem left--the index of the selected item is lost across postback. This is another weird thing of list controls. The SelectedIndex property is NOT explicitly persisted to the viewstate and is NOT set out of posted data (the whys of this are currently beyond me). The property takes its value from the Selected property of the Items collection. As you can easily figure out, SelectedIndex is then implicitly persisted to the viewstate. That's why it gets lost across postbacks.
Workarounds? Just one--resort to the old fashioned but still effective Page.Request["countrylist"]. In Page_Load, it just returns the text of the selected item. Map that to an index position and you're done.