I looked the documentation for System.ComponentModel and essentially it seems to me that it is a framework for rules and metadata about how objects and data relate to user interface controls.
It's a great idea that formalises and stores the relationship between your data and your display.
We are seeing from it dynamic controls that could with some work make building at the least 90% of the back end data administration very, very easy.
Probably people will want custom admin but the boiler plate stuff can be made both simple and very easy to change when the data-model changes
it will also look good be customizable, be relational, be validated and have appropriate controls and formatting. (it wont perform as well as custom code but for that 90% of
the stuff we do it really doesnt matter)
One point that comes from this - when programmers create their databases and objects they almost always use PascalCase or underscore_styled_fields.
Why?
With objects: spaces are used to seperate parts of code and cant really be used
With databases: using spaces requires lots of square brackets (depending on your database server) - spaces are horrible
And finally ProgrammersAreHappyToReadLikeThisBecauseHumansCanProcessThisQuiteQuickly dots and spaces are used for other things
However for our users its different - they want to be able to read things as per normal
Therefore in general the relationship between the names of objects, fields and tables and the labels used for these i.e. their display in the UI
will require a conversion from PascalCase or underscore_style to Human Style
For example Matt Beserth writes in his blog that while building my Northwind example last week, I found myself typing in the same type of metadata information for each of the properties I was showing on my screens. I was adding attributes for things like ... Add spaces into the column headers. So ShippedDate would become Shipped Date. (see http://mattberseth.com/blog/2008/08/dynamic_data_and_custom_metada.html)
This will be the lot of programmers until the end of time.
I would suggest therefore that the system.componentmodel could be enhanced with attributes at a table or class level for the application of a default mapping between field/table/object names and the display name and / or description and / or prompt when it comes. This default mapping would be superceded whenever someone specified a particluar DisplayName/Description/Prompt attribute
This would not break the generality or specifitivity or purity of the namespace because it exists to map objects to user interfaces
the attribute might be DisplayNameMapping or DescriptionMapping and might have the attributes
MixedCase / "Friendly Names" / lowercase / Uppercase / Title case / Remove End ID / Remove Prefix / None (* rarely used)
On a per table basis and per project basis
Otherwise we will all be typing a lot of easly generated code and creating very messy matadata classes for a very long time or else adding a kludge
and missing the point of System.ComponentModel
A couple of additional points to this long-winded rant
- it might be useful as part of the testing if a programmer has the job of replicating some live web or application user interfaces
with the dynamic data project and feeds back on requirements to make this simpler
- I do love the dynamic data / system.componetmodel idea I spend half my working life mapping data to user interfaces in one way or another
Mark