I just read about this
alternative gui for nunit over at
Roy Osherove's.
I just downloaded it and it looks pretty sweet! Haven't had a chance to use it much yet, but I'm excited to see all the statistics that it produces....
I have wondered about this for a long time, but have also long since accepted the circumstances.
Why, when I place form elements on a user control, does it have to append "UserControlId_" to the id
of the element and "UserControlId:" to the name of the element? This is really annoying for custom javascript that is written for these elements and form submissions. Once you realize that
this happens, its not that difficult to define a javascript variable and append it to the beginning of all the elements that
you are using, or parse the form collection on the codebehind before you use the posted data, but it can still be frustrating. I was hoping that this behavior would be removed when master pages came out
with asp.net 2.0, but alas, after working on a side project using master pages, I see that this still occurs.
Does anyone know why this is neccesary?
I recently discovered the radio shows over at DotNetRocks hosted by Carl
Franklin. These shows are pretty good, I love that
you can download the full mp3 show, I'm downloading all of them and I put them
on my Dell DJ and listen to them in the car; it
makes the drive to work much more appealing.
I'm in the middle of the show with Mark Pollack, Ted
Neward, and Don
Box, which is especially interesting because these
guys are not afraid to push each other's buttons. They talked about
generics in java, and how Sun just put it into jdk 1.5 because of
all the hype that C# was getting for putting generics into Whidbey. While
java supports generics now, you don't get the total benefits of generics like
you do in C# because all the java compiler does is convert all the generic types
into objects, so you still have the performance overhead of the boxing
operations, whereas in C# if you define a List<string>, it really is a
List of strings.
The part of the conversation that I'm at right now is where
they are all discussing object relational mapping, and the problems with current
attempts to transpose relational data into language objects. This topic is
particularly interesting to me, because we use some custom o/r mapping objects
at work, in C#.
They used a Person object as an example, so suppose you have
a person table in your database, and a corresponding Person class in your
application. When you are accessing the Person instance, you would supply
the primary key, say 1, of the person that you want to access. So your
application needs to go to the database and retrieve the fields of the person
table, and populate your Person instance. The problem is what fields
should the application retrieve? Do you grab all the fields, even if you
just want that person's email address? Thats a waste of database overhead.
But you cannot just load every field on demand because the situation will arise
where you need all or most of the fields, and its silly to query the database
separately for each field. So what to do? In our implementation at
work, I load all the fields at once. I find the performance is not an
issue, even for the case of one table that has > 100 fields. So IMO,
loading all at once is not a problem. But Carl made a suggestion that I
thought was really clever. He suggested using custom attributes to specify
which fields are loaded by default, and which fields are "lazy loaded." So for
our Person class, maybe FirstName, LastName, Email, and Address are always
loaded, and then Phone, Company, Fax, City, State, Zip, Country are only loaded
when we explicitly access those fields. This scheme would work very well
with that table I mentioned with many fields, and I think the benefits would
certainly be seen if you had a table that was storing blobs, so you could load
all the fields besides the blob, and just grab the blob when you actually needed
the binary data.
This show is compelling so far, I'm looking forward to the
rest of it on my way to work Monday.
I know
this was posted awhile ago but, I have to say, code generation is a very good thing.
I wasn't sure how to go about doing it the right way, but finally ended up using the same technique described in the article. You publish a class file, Foo_Generated.cs, which contains all published code. You then hand code a file Foo.cs, that inherits Foo_Generated.cs. You can put anything you want into Foo.cs, and still have all the power of republishing the generated file. I'm using this technique in our current project at work, and one file that I created in a matter of minutes has over 2000 lines of code in it!!! If I had to do all that by hand, it would've taken sooooo much longer, and there would have undoubtedly been many many typos and mistakes. So, hand typing all the nasty plumbing code = 5 hours, generating the code so you can start beer friday a little earlier.........priceless.