Nice! That's exactly how simple I always thought it ought to be, but I didn't know it was actually possible.
Thursday, February 12, 2009 4:41:00 PM
Anonymous said...
Thanks for the tip, Oskar. I wish I had found out about this about two months ago, when I could have used it! I'll have to remember to pass this on to the next person I know who runs into this issue.
I've spent a lot of time on this stuff when writing the SPSource tool which reverse engineers a list much like Solution Generator does but a little smarter ...it doesn't use the RPC call technique.
I thought i'd ask you as you've found a cracker there!
Where do I have to look to ensure that the fields turn up in the New/Edit for. I konw there are attributes on the fields themselves in the schema.xml...but even forcing that there doesn't seem to do it! Where else needs to be set?
@Jeremy: Hmmm. I would make sure that the ContentType's FieldRef element also has the ShowInEditForm and ShowInNewForm attributes both set to true.
Theoretically the List's Field element should override the ContentType's FieldRef, but as with all things SharePoint it isn't entirely clear.... Best of luck. I'll have to check out SPSource.
SPM = Wouldn't leave home without it ;-) +1 for WSPBuilder too ;-)
Also, have you seen the survey I've put together on how people work with SharePoint Dev? http://wss.made4the.net/archive/2009/04/22/sharepoint-implementation-environment-survey-%E2%80%93-please-complete-it.aspx
Great Post wanna just to mention that you can makethe list section even simpler by replacing it by the following : List xmlns:ows="Microsoft SharePoint" Title="Basic List" Type="11501" FolderCreation="FALSE" Direction="$Resources:Direction;" Url="Lists/Basic List" BaseType="0" DisableAttachments="TRUE"
Cheers
Thursday, September 10, 2009 1:15:00 PM
Anonymous said...
Great article, saves a lot of time. Thank you very much.
Saturday, July 24, 2010 11:30:00 AM
Ed said...
Life saver that's what this is. It worked pretty well!!!
Thanks Oskar.
Tuesday, August 10, 2010 3:59:00 PM
Anonymous said...
It is a nice trick for a basic view but can you create a group by elements like the ones you create using the web interface??
The List element at the top should not be immediately closed -- all the subsequent content should be within it.
The opening List element should merely end with ">", not with "/>".
Saturday, October 01, 2011 10:52:00 AM
Anonymous said...
Perry, thanks. I blame that on copy/ paste between Visual Studio and Bloger - it translated the namespace link and removed the quotes. Sorry about that - I will fix that attribute.
Saturday, October 01, 2011 1:15:00 PM
Perry said...
We're seeing problems with "Failed to cache schema".
See, e.g., http://manojsharepointfindings.blogspot.com/2010/02/failed-to-cache-schema-for-3.html
The comment that View 0 is used for schema caching, down near the bottom of the following article, seems relevant: http://msdn.microsoft.com/en-us/library/ms438338%28v=office.12%29.aspx
Tuesday, February 07, 2012 2:42:00 PM
Perry said...
Our issues were due to a field schema in the 12-hive changing underneath an existing list using that field schema. This doesn't seem to be the fault of using an abbreviated schema after all.
Perry, thanks for the followup. As evident from my more recent posts, I've since moved on from SharePoint, but I'm happy this old post is still useful to you!
Tuesday, February 14, 2012 8:15:00 AM
My colleague Tad sent me a link to Andrew Connell’s post: A Quicker Way to Create Custom SharePoint List Templates with the comment - ‘I guess “quicker” is relative.’ Tad’s right – this seems to be going too far for a simple schema.xml file.
Much of Andrew’s post is valid – there’s not much doing getting around the Content Types and the List Template (if you need them), and using the OOTB list interface plus Keutmann’s excellent SharePoint Manager tool to build queries is a simple workaround, but I’m balking on his approach for creating the the List’s schema. If you take Andrew’s approach, you’re gonna end up with a MINIMUM of 1600 lines of xml in your schema: my approach is far simpler; below is a fully functioning schema that’s only 30+ lines – see if you can spot the magic bullet…:
<?xml version="1.0" encoding="utf-8"?>
<List xmlns:ows="Microsoft SharePoint" Id="{AB426CDE-98F2-432A-B296-880C7931DEF3}"
Title="Setting" Url="Lists/Setting" BaseType="0"
FolderCreation="FALSE" DisableAttachments="TRUE" VersioningEnabled="FALSE"
Direction="$Resources:Direction;"
xmlns="http://schemas.microsoft.com/sharepoint/">
<MetaData>
<Fields>
<Field Type="Text" Name="Title" DisplayName="Name" Required="TRUE" />
<Field Type="Text" Name="Value" DisplayName="Value" Required="TRUE" />
</Fields>
<Views>
<View BaseViewID="0" Type="HTML" WebPartZoneID="Main" DisplayName="All Items" DefaultView="TRUE"
MobileView="True" MobileDefaultView="False" SetupPath="pages\viewpage.aspx"
ImageUrl="/_layouts/images/issues.png" Url="AllItems.aspx">
<ViewStyle ID="17"/>
<RowLimit Paged="TRUE">100</RowLimit>
<Toolbar Type="Standard" />
<ViewFields>
<FieldRef Name="Edit" />
<FieldRef Name="Title"/>
<FieldRef Name="Value"/>
</ViewFields>
<Query>
<OrderBy>
<FieldRef Name="Title"/>
</OrderBy>
</Query>
</View>
</Views>
<Forms>
<Form Type="DisplayForm" Url="DispForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
<Form Type="EditForm" Url="EditForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
<Form Type="NewForm" Url="NewForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" />
</Forms>
<DefaultDescription>Settings used in the application.</DefaultDescription>
</MetaData>
</List>
Yep, it’s the ViewStyle tag I wrote about back in 2007. It eliminates that 90% of the schema file that Andrew suggests you ignore, leaving a fairly terse xml that can actually be digested and debugged (sort of).
posted by Oskar Austegard at 1:31 PM on Feb 10, 2009
"MOSS: The dreaded schema.xml"
18 Comments -
i myself thought the article was a little behind the times... but, i guess it's good for somebody new to the whole concept of custom list templates.
Tuesday, February 10, 2009 3:18:00 PM
Nice! That's exactly how simple I always thought it ought to be, but I didn't know it was actually possible.
Thursday, February 12, 2009 4:41:00 PM
Thanks for the tip, Oskar. I wish I had found out about this about two months ago, when I could have used it! I'll have to remember to pass this on to the next person I know who runs into this issue.
Thursday, February 26, 2009 3:04:00 PM
Great find mate.
I've spent a lot of time on this stuff when writing the SPSource tool which reverse engineers a list much like Solution Generator does but a little smarter ...it doesn't use the RPC call technique.
I thought i'd ask you as you've found a cracker there!
Where do I have to look to ensure that the fields turn up in the New/Edit for. I konw there are attributes on the fields themselves in the schema.xml...but even forcing that there doesn't seem to do it! Where else needs to be set?
Thursday, April 23, 2009 1:26:00 AM
@Jeremy:
Hmmm. I would make sure that the ContentType's FieldRef element also has the ShowInEditForm and ShowInNewForm attributes both set to true.
Theoretically the List's Field element should override the ContentType's FieldRef, but as with all things SharePoint it isn't entirely clear.... Best of luck. I'll have to check out SPSource.
Do you use Keutmann's excellent SPM by the way?
Thursday, April 23, 2009 10:18:00 AM
SPM = Wouldn't leave home without it ;-)
+1 for WSPBuilder too ;-)
Also, have you seen the survey I've put together on how people work with SharePoint Dev?
http://wss.made4the.net/archive/2009/04/22/sharepoint-implementation-environment-survey-%E2%80%93-please-complete-it.aspx
Thursday, April 23, 2009 8:34:00 PM
THANK YOU for posting this! schema.xml is now approachable and manageable!!
Friday, September 04, 2009 11:53:00 AM
@michhes - no problem, happy to make someone's day... Just curious that no more people know about this.
Friday, September 04, 2009 4:35:00 PM
Great Post wanna just to mention that you can makethe list section even simpler by replacing it by the following :
List xmlns:ows="Microsoft SharePoint" Title="Basic List" Type="11501" FolderCreation="FALSE" Direction="$Resources:Direction;" Url="Lists/Basic List" BaseType="0" DisableAttachments="TRUE"
Cheers
Thursday, September 10, 2009 1:15:00 PM
Great article, saves a lot of time. Thank you very much.
Saturday, July 24, 2010 11:30:00 AM
Life saver that's what this is. It worked pretty well!!!
Thanks Oskar.
Tuesday, August 10, 2010 3:59:00 PM
It is a nice trick for a basic view but can you create a group by elements like the ones you create using the web interface??
Thursday, August 19, 2010 9:08:00 AM
Anonymous,
Yes,
Query
...
...
GroupBy
FieldRef ...... /
/GroupBy
..
/Query
Thursday, November 04, 2010 10:23:00 AM
The posted code is wrong.
The List element at the top should not be immediately closed -- all the subsequent content should be within it.
The opening List element should merely end with ">", not with "/>".
Saturday, October 01, 2011 10:52:00 AM
Perry, thanks. I blame that on copy/ paste between Visual Studio and Bloger - it translated the namespace link and removed the quotes. Sorry about that - I will fix that attribute.
Saturday, October 01, 2011 1:15:00 PM
We're seeing problems with "Failed to cache schema".
See, e.g., http://manojsharepointfindings.blogspot.com/2010/02/failed-to-cache-schema-for-3.html
The comment that View 0 is used for schema caching, down near the bottom of the following article, seems relevant: http://msdn.microsoft.com/en-us/library/ms438338%28v=office.12%29.aspx
Tuesday, February 07, 2012 2:42:00 PM
Our issues were due to a field schema in the 12-hive changing underneath an existing list using that field schema. This doesn't seem to be the fault of using an abbreviated schema after all.
Thursday, February 09, 2012 7:36:00 PM
Perry, thanks for the followup. As evident from my more recent posts, I've since moved on from SharePoint, but I'm happy this old post is still useful to you!
Tuesday, February 14, 2012 8:15:00 AM