One if the interesting topics in SharePoint customizations is developing customized list definitions to be integrated later on within you site definitions.During list definitions development you are required to determine two important values "Type" and "Base Type", following is a description for the available types (available in the WSS SDK)
Value Description
100 Generic list
101 Document library
102 Survey
103 Links list
104 Announcements list
105 Contacts list
106 Events list
107 Tasks list
108 Discussion board
109 Picture library
110 Data sources
111 Site template gallery
113 Web Part gallery
114 List template gallery
115 XML Form library
120 Custom grid for a list
200 Meeting Series list
201 Meeting Agenda list
202 Meeting Attendees list
204 Meeting Decisions list
207 Meeting Objectives list
210 Meeting text box
211 Meeting Things To Bring list
212 Meeting Workspace Pages list
300 Portal Sites list.
1100 Issue tracking
2002 Personal document library
2003 Private document library
0 – Custom List
1 – Document Library
2 – Not used
3 – Discussion Forum
4 – Surveys
5 – Issues List
so, if you are developing custom picture library set Type="109" and Base Type="1" (because picture library mainly based on document library)
another example if your are developing custom Calendar list definition set Type="100" Base Type="0".
转自 http://tomblog.insomniacminds.com/2008/01/25/sharepoint-internals-internalname-versus-displayname/
When creating columns (more commonly called fields) in SharePoint through the interface, you have to enter a name for it. This name is used throughout the lists and sites, included internally. Except when you try to change the name, it’ll only reflect on the outside. Internally the old name will be kept. This is because a field has two names: an internal name and a display name. When creating a field, you set both. When renaming it, you only change the display name. (There is actually no way to change the internal name afterwards)
But why is this a concern? Well, in the object model it can become quite vague when to use the internal name and when to use the display name. Here is a short list with some common methods and the name they need.
If I find more relevant functions, I will update this list. On a related note, there also exists a static name. This is a name used by the field type. This is different from the internal name, as the internal name must be unique in its list and could have changed.
Hope this clears up some confusion about field naming in SharePoint.
1: StaticName 编码，转换规则
When you create a column on a list, both its DisplayName and StaticName are set to the same value. However, the StaticName contains converted values for some characters, most notably a space ' ' is converted to '_x0020_'. So if the DisplayName is 'Product Description', then the StaticName will be 'Product_x0020_Description'.
There's another little bugaboo: The StaticName is limited to 32 characters including the translations for special characters. Because of this, if you have more than one column with the same first 20 characters, SharePoint creates StaticNames as follows:
'Product Desciption 1' ---> Product_x0020_Description_x0020_
'Product Desciption 2' ---> Product_x0020_Description_x0020_0
'Product Desciption 3' ---> Product_x0020_Description_x0020_1
etc. Clearly this renumbering can get confusing, too, so a lot of folks will create their columns without spaces in the names (ProductDescription1) and then change the DisplayName.
The easiest trick to see what the StaticName is (to me), to go to List Settings, and then click on the column name in which you are interested. On the Change Column page, the URL will end in something like: /_layouts/FldEdit.aspx?List=%7B37920121%2D19B2%2D4C77%2D92FF%2D8B3E07853114%7D&Field=Product%5Fx0020%5FDescription
The StaticName is the value for the Field parameter in the QueryString. However, there's more encoding to deal with: the underscores ('_') are converted to '%5f'. So Product%5Fx0020%5FDescription means Product_x0020_Description again.
Whenever you change the DisplayName, the StaticName stays, well, static. This often results in DisplayNames and StaticNames that have nothing to do with each other, so as you are prototyping, it's a good practice to delete columns and re-add them if you are changing their purpose and therefore their name.
2：FieldId，PropertyConstant,ListType
Also theres the FieldId and PropertyConstant classes:
FieldId defines constants that you should use to reference SharePoint fields. PropertyConstants is the same deal, but for UserProfile fields.
Theres also lots of enumerations that you should use instead of hardcoding strings or id's. You will need to go scouting the API for a complete list, but one such enum is the ListType enum
3:如何更改displayname，staticName，InternalName
Actually there are three strings involved, as can be easily seen from object model examination (or use of SharePointExplorer).
The StaticName of the site column can be updated by changing it in the feature ("StaticName" attribute) and redeploying. Then if the feature receiver gets the SPSite.SPField and calls Update, that will update the StaticName of all list instances.
The InternalName of the site column can be updated by changing it in the feature ("Name" attribute) and redeploying.
However, the site column InternalName isru not propagated to list instances via SPField.Update, and AFAICT, cannot be changed, updated, or fixed at all.
Perhaps it is possible by twiddling with the underlying rows in the database, but that is obviously unsupported.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。