Is it really more complex than casting a bunch of controls using FindControl? Especially when some other developer could easily come by, change some ids and break your codebehind bad?

If another developer breaks your codebehind, he obviously doesn’t know what hes doing and therefore shouldn’t be developing on your application.

My major new problem with Jonathan Hollands approach was the following line CommentDateTime.Text = currentComment.ShortDateTime;, surely you would consider ShortDateTime to be layout/formatting and it should be in the presentation layer. (although I generally consider the aspx + the aspx.cs the presentation layer and a code library to be the business logic).

If you want to create this presentation logic so badly, create your own control with a public property for string formatting. Then you can change the property on the control and not have to recompile.

I kinda regret reading this page.

Here goes a again:

————————————————————————-

I would prefer:

This would have to be backed by some extension methods (C# 3.0):

In the real MVC, the view goes to the model directly. That is implemented by an object datasource which can be a static facade or another object with default constructor which reads its conf. from the conf file.

I use Eval since it allows a much shorter notation. I also import the namespaces so that I don’t need Wyatts long paths.

Really the only thing needed to be implemented in the codebehind here is the actions, such as DoSuppressComments. This allows you (or designer) to change the page, possibly pulling in more entities using another objectdatasource, without touching the codebehind.

Wyatt is right that Eval uses reflection internally and thus is slightly (!) slower than direct access. However, with the number of typecasts in your example, I’m not so certain that is would in fact be faster. Anyhow, this is negligible.

The real problems here is that we are being let down by the MS ASP.NET team. C# got generics in C# 2.0, but the templates of ASP.NET still just assumes dataitems are objects. IMO repeaters and other data aware controls should expose a generic Item property method that - when bound to a statically typed datasource - exposed the item as statically typed.

Also, I would like to see a generic version of FindControl, enabling me to write FindControl<TextBox>(”Name”) - and use it strongly typed.

This would have to be backed by some extension methods:

In the real MVC, the view goes to the model directly. That is implemented by an object datasource which can be a static facade or another object with default contructor which reads its conf. from the conf file.

I use Eval since it allows a much shorter notation. I also import the namespaces so that I don’t need wyatt’s long paths.

Really the only thing needed to be implemented in the codebehind here is the actions, such as DoSuppressComments. This allows you (or designer) to change the page, possibly pulling in more entities using another objectdatasource, without touching the codebehind.

Wyatt is right that Eval uses reflection internally and thus is slightly (!) slower than direct access. However, with the number of typecasts in your example, I’m not so certain that is would in fact be faster. Anyhow, this is negligible.

The real problems here is that we are being let down by the MS ASP.NET team. C# got generics in C# 2.0, but the templates of ASP.NET still just assumes dataitems are objects. IMO repeaters and other data aware controls should expose a generic Item property method that - when bound to a statically typed datasource - exposed the item as statically typed.

Also, I would like to see a generic version of FindControl, enabling me to write FindControl(”Name”) - and use it strongly typed.

Comment.ShortDateTime is just a property that returns a string in the business layer. Instead of returning a DateTime Object and having to cast it to a string, its easier to have an additional property in the BLL. Why repeat yourself? :)

I find fault with ASP.NET and nested controls. They should be exposed strongly typed, yet they are not, hence the need for FindControl. If you spend any time at all writing custom controls in ASP.NET you will find that you need to use FindControl. It is a necessary evil.

All that casting in the aspx is quite ugly, strongly typed repeaters would be a really nice thing.

Pity you can’t nicely use generics >?