none
Site content types Vs List content types RRS feed

  • Question

  • Hello all,

    While creating my first SP site using visual studio 2010; following the best practices guidelines from Microsoft I created a content type for each data entity and of course a site column for every and each field in those entities -can't describe how tedious this was-. Anyway, when I started creating List definitions based on those content types I noticed that the CAML xml code is literally copied to the schema.xml rather than referencing it. If I made any changes to the original content type it's not reflected in those lists. On the other hand when I make changes to the list content type -in contrast to the site content type- things are reflected on the site properly. Why the redundancy?

    I mean I even tried to use <ContentTypeRef> in the schema.xml to reference my site content type and get rid of the redundancy with no luck!!! Content Types and even fields must be defined int the schema.xml with no direct relation to the site content type already defined in the project!! Fields must be defined in the <fields> element in schema.xml and referenced in the <contentType> element of schema.xml too, regardless that they're already defined at the site level!!

    So, if I have to define content types/fields at the level of the list, and visual studio can't automatically track changes made to site content types, why bother defining site columns/content types at all? Where is the re-usability in cutting/pasting code?

    I'm I missing something here?

    EDIT:

    One more question, in SharePoint UI I can define in version setting how many versions to retain of the item. How can I do the same using CAML in VS 2010?

    Thanks

    Tuesday, November 16, 2010 12:14 AM

Answers

  • You're just going to have to live with it I'm afraid - in VS2010 if you create your list instance from a content type that you've already created then the schema.xml is built for you, but any changes to the content type or referenced fields then need reflecting in the schema.xml. Effectively the list schema is a data store for one or more well-defined item schemas - copying the item schemas into the list schema ensures the data store itself is well-defined, and not dependent on field/content type changes throughout the site. Sometimes this works in our favour, sometimes it's frustrating, unfortunately there's no way round it. I agree with you though, given the requirement for copying item schemas into list schemas it would be good to have a 'List Schema builder' in VS2010 that allows you to move fields and content types in without having to read and understand thousands of lines of XML where every identifier is a godforsaken GUID!

    Not sure about how to answer your additional question re CAML, but there is another way to do it. Create a feature receiver for the feature that provisions the list instance - in the FeatureActivated method you can get the SPList object (SPList list = web.Lists["List Name"]) and then set either the MajorVersionLimit or the MajorWithMinorVersionsLimit property. Don't forget to list.Update() when you're done!

    Sam

    Tuesday, November 16, 2010 1:36 AM

All replies

  • You're just going to have to live with it I'm afraid - in VS2010 if you create your list instance from a content type that you've already created then the schema.xml is built for you, but any changes to the content type or referenced fields then need reflecting in the schema.xml. Effectively the list schema is a data store for one or more well-defined item schemas - copying the item schemas into the list schema ensures the data store itself is well-defined, and not dependent on field/content type changes throughout the site. Sometimes this works in our favour, sometimes it's frustrating, unfortunately there's no way round it. I agree with you though, given the requirement for copying item schemas into list schemas it would be good to have a 'List Schema builder' in VS2010 that allows you to move fields and content types in without having to read and understand thousands of lines of XML where every identifier is a godforsaken GUID!

    Not sure about how to answer your additional question re CAML, but there is another way to do it. Create a feature receiver for the feature that provisions the list instance - in the FeatureActivated method you can get the SPList object (SPList list = web.Lists["List Name"]) and then set either the MajorVersionLimit or the MajorWithMinorVersionsLimit property. Don't forget to list.Update() when you're done!

    Sam

    Tuesday, November 16, 2010 1:36 AM
  • Great!!

    The idea of re-usability of site content types and inheritance completely contradict with this loosely coupling of site-list content types!! If this is the case then site content types are defined only to push changes at the level of code and SP UI?!!

    Also what about <ContentTypeRef>? Why is it not working? When I put only reference to my content type and remove all columns I get an empty item with the Title/Created By/Modified By default columns only!! ARGHHHH!!!

    You mentioned "List Schema builder" in VS 2010. What is it? I tried to Google it but I didn't find something relevant! Anything to make my life with SP easier would be appreciated.

    As for my other question, I Googled a bit -By the way information about SP are scarce and not well organized!!- finally I discovered an attribute in the List definition item called MajorVersionLimit which was not covered by the IntelliSense. VS 2010 gives me MajorVersionLimit is not declared error but it works fine!!! What's wrong Microsoft?

    I moved to SP thinking that it would save me time but here I am staring for hours at XML code just to do the simplest things!!

    Thank you for your time! I hope more people would have additions to this thread before it's closed.
    Tuesday, November 16, 2010 6:43 AM
  • I see what you mean regarding reuse and inheritance, but when your feature has been deployed the API will persist content type changes to the list schema if you want it to, so this issue only occurs in a relatively small set of circumstances - it's just annoying that CAML development isn't very convenient. That said, you're very lucky to be joining with SP2010 - back in the days of WSS3 you had to write and edit all CAML by hand. Absolute nightmare.

    To my knowledge there is no 'List Schema builder' - but from my experience (and yours and that of many others I suspect) it would be a really useful tool! If I had the time I'd write one. However I still haven't had time to write anything in my blog about the last 3 months development, so I doubt SPListSchemaBuilder will be coming from my fair hands!

    SharePoint documentation is scarce on a lot of topics (especially when you really need it), but the development community are very active regarding posting solutions to common or tricky problems in their blogs and on discussion forums like this.

    SharePoint is quite an ideosyncratic development platform - there are days when you'll tear your hair out, and days when you'll get down on your knees and give thanks to SPGod for some OOB features that can be activated at the click of a button (the ones that make you look to your boss like you've just completed 2 months development work in an afternoon).

    Best advise I can give is to stick at it, keep clambering up the steep learning curve and keep posting your questions (and innovative solutions) where everyone can see them!

    Tuesday, November 16, 2010 7:07 AM
  • Thanks man, you've been a good support.

    I know SP has a good future. If this platform continues to grow like this we'll see days where entire LOB applications are literally built in an afternoon. It's just I'm not used to the lousy intellisense, no compile errors, have to go to the log and search by correlation for every error!!! Sheesh!

    Anyway, you're right. SharePoint community is one of the most active Microsoft technology based communities out there. I hope one day I'd be as helpful as you were to me today.

    Thanks again.

    Tuesday, November 16, 2010 7:20 AM