"Catch all the exceptions, ALL OF THEM!!!"

"Catch all the exceptions, ALL OF THEM!!!" were the words that ran thru my head as a saw the dreaded
..catch(Exception)
{}...

WTF??!?!

a)Why would you ever catch all exceptions? You should know what exceptions are coming back at you catch specific ones and deal with them appropriately. The only* time I could ever see this being usefull is for logging purposes...
b)Dont hide exceptions... deal with them. Catch exceptions and doing nothing is pretty rank... at least comment the hell out of why you are doing it.
c)Get FXcop or some tool that tells you when there is rubbish code in your solution!

*OK there is probably a few areas, but not as many as some would think...

MVC and Building User controls (Specifically .Net ASCX files).

MVC and Building User control's (Specifically .Net ASCX files).

User Controls are a common way to develop reusable UI components that use a common layout or have common generic functionality. Unfortunately I so often see these controls being developed, in my mind, incorrectly. User controls should generally be dumb. They should know very little of the out side world (except of course of the namespaces they inherit from and maybe utility classes that perform common public static encapsulated method calls). Think text boxes, drop down lists etc. These don't know about your business objects! You passed in and retrieve properties from them. They may do some basic processing however this is generic. They should certainly never call or run business logic or know about services. So how do we use User Controls to run common logic? On the user control there should be publicly visible properties. This is usually a given. There can also be methods and events. Often I call a PopulateControl(Type type) (which is a public void Method) that takes in a control specific DTO (or collection of DTO's). Usually this merely passes each of the properties in the DTO to the properties in the Control. Right, so data is in the control, how do we do stuff with it? The page load may have some generic code, but avoid adding smarts that are too specific. How about passing data back to the parent? Either retrieve the data from a MyDto read only property the does the exact opposite of the populate control returning a DTO or create a custom event eg Save and pass a delegate into the control. Yes this mean code stays on the page. So?? If it commonly called create a class that does all the leg work for you that all page can call. This then follows the MVC pattern and separates the visual aspect from the Data aspects

Question: why do you use PopulateControl(Type type) and RetrieveDTO() and not properties? Answer: I am of the opinion that a property should never be able to throw an exception or call code that can throw an exception. If you are confident that this can not happen then, sure, use the property approach. However, if there is functionality that may cause an exception, then use the method approach. I wouldn't expect people to strictly follow this, this is just my preference.

Question: When to use Delegates? Answer: When it is obvious that this control does something, like its is a control that has customer details for adding or editing then a save delete and cancel buttons may be appropriate. Control of what is done on the User Control (usually the page) with the event (ie EditCustomer_OnSave()) means that page can pass in the correct logic or call to the manager of logic as a delegate. Obviously this means exposing something to apply the delegate to, such as an event!

I am more than happy for feed back on this. I want to do better code, you may be able to help!

Breadcrumbs Sitemaps and Querystring Part 2

Ended up not using Mr Chens example as we had reservations on how whell this would be used with the SiteMapResolve event. The current implementation is a complete hack requiring 2 (yes 2 providers) one to check the node and the other to build up a temp sitemap with query strings appended and a user control sitting in master pages working with the two. This means the code is very delicate and only take one person to change the default provider to break the whole thing. I think i have written more comments that code on this and cant say im too proud of the work, but mainly disappointed in MS hack around site map and thir providers... more perhaps to come once this goes though full test environment.

lessons have been learned

Pixel Monkey week!

Not only has SilverLight been official relased (and rebranded from WPF/e) but a nice little paint app to override/replace your basic (oh so basic) windows paint app has been released. Its pretty handy and does most of the stuff I would want out of a paint app and its free and open source so we can pull it apart and look at its guts!

BreadCrumbs SiteMaps and QueryString... argh!

if this article does what i want it to do i will hail Danny Chen, well at least pay more attention to his blogs ;)

Long and short of it, xml site maps have never really sat well with me, i know Gumble has rewritten sitemap stuff before, however the project we are working on is using the xml source (not DB) so i'll stick to it.

Cheers to SteveE for the help on this too.

Scotts Gu's reply to AJAX secuity breaches

Scotts Gu's reply to AJAX secuity breaches can be seen here

AJAX Security flaws

Interesting article on AJAX Security flaws, sighted by Joe On .NET, but some reason its no longer showing on his site(?)
http://www.eweek.com/article2/0,1895,2110554,00.asp

"…. called JavaScript Hijacking—can be found in the biggest AJAX frameworks out there, including three server-integrated toolkits: Microsoft ASP.Net AJAX (aka Atlas), Google Web Toolkit and xajax—the last of which is an open-source PHP-class library implementation of AJAX…."

One line synopsis:
Basically don’t use in built AJAX when sensitive data is being passed, but it is fine on public sites.

ASP.Net DropDownList

Asp.net DropDownList does not work
The two events OnSelectedIndexChanged and OnTextChanged seem to actually check if the value of the dropdown list has changed. When queried what the selected index is it will give you the first value that has the selected value. Basically the OnSelectedIndexChanged is incorrectly named, it should be OnSelectedValueChanged.
Other bugs in this control are .SelectedValue actually returns the lowest indexed listitem with the selected value, and when you would expect .Text to map to the visible text it actually is the corresponding value (so both of these are incorrect in kinda the same way).
Because of this, the OnTextChanged event does actually work "correctly" just not at all intuitively and it appears that it too comes under the nonexistent OnSelectedValueChanged event.
To be honest im a little disappointed that this has persisted through to .Net 3.0, I would love to hear a why this is still the case.
How I have found this (yes i'm sure millions of other have), is a client wants duplicate values with diffent text in a drop down... not sure if there is a real business reason, bu theres the background anyway.

End rant, sorry my firstone was negative... oh well

See you soon :)
Rhys