Their issue is refactoring, when changing the type names, string's won't be part of refactoring.
I have put them in the markup whenever possible, however there are instances, where I have to do it int he code behind, as the third party control, requires me to hook into an event to retrieve this dynamically created comboxbox for example. On Wed, May 26, 2010 at 9:55 AM, Bec Carter <bec.usern...@gmail.com> wrote: > not answering your questions directly but another option is to define > the datasource in the markup and link it to the combobox which lets > you change the property names without needing to regenerate the > assembly. > > On Wed, May 26, 2010 at 8:35 AM, Winston Pang <winstonp...@gmail.com> > wrote: > > Hi guys, > > > > > > This is more of a question of whether or not this sounds feasible and has > > anyone seen anyone do this: > > > > > > Typically with most ASP.NET controls, lets take the ComboBox for an > example, > > it'll be like > > > > this.comboBox.DataSource = someList; > > this.comboBox.DisplayMember = "Property1"; > > this.comboBox.ValueMember = "Property2"; > > > > The client we're dealing with, has specifically told us to not > "hard-code" > > these property names, and to use reflection, through lambda expressions > to > > derive the property name. > > > > Firstly, do you think this will add a lot of overhead? I'm guessing it'll > be > > ok-ish, considering ASP.NET MVC uses it a lot. > > > > Also, has anyone seen people do it this way? > > > > It this a stupid thing to do? I think it has it's merits to an extent, > but > > it sure doesn't seem common to me. > > > > > > Cheers, > > > > > > Winston > > >
