Nothing more to say then to watch this video at Channel9 : http://channel9.msdn.com/posts/PDCNews/First-Look-Office-14-for-Web/ ! Looks pretty impressive if you ask me.. real online collaboration, the ability to work on a document at the same time as someone else does. Seeing the changes immediately while working on the document.
Btw.. notice that Antoine Leblond says “.. so that customers can actually run these on their SharePoint servers within their enterprise..” ;)
When querying on them you don’t get the results you were hoping for.. well at least I didn’t. Let me tell you what I was doing and what problems I discovered .. To begin, I created a custom list with some columns that I marked as hidden on the newform and the editform page using this piece code..
Guid listGuid = createdWeb.Lists.Add("AcceptedList", "", SPListTemplateType.GenericList)
SPList list = createdWeb.Lists[listGuid];
customList.Fields.Add("Accepted", SPFieldType.Boolean, false);
list.Update();
SPField field = customList.Fields["Accepted"];
field.ShowInNewForm = false;
field.ShowInViewForms = true;
field.ShowInEditForm = false;
field.Update();
Next thing I wanted to do was having two SPGridView’s, one showing all the items where the custom field was set to ‘true’ and the other one was set to ‘false’. To gather the items I’m using the SPDataSource using a CAML query to retrieve them.
ds = new SPDataSource();
ds.SelectCommand = "<Query><Where><Eq><FieldRef Name='Accepted' /><Value Type='Bool'>0</Value></Eq></Where><OrderBy /></Query>";
ds.List = currentWeb.Lists[listGuid];
ds.DataSourceMode = SPDataSourceMode.List;
ds.EnableViewState = true;
ds.IncludeHidden = true;
ds.Scope = SPViewScope.Recursive;
gridViewAccepted.DataSource = ds;
gridViewAccepted.DataBind();
ds = new SPDataSource();
ds.SelectCommand = "<Query><Where><Eq><FieldRef Name='Accepted' /><Value Type='Bool'>1</Value></Eq></Where><OrderBy /></Query>";
ds.List = currentWeb.Lists[listGuid]; ;
ds.DataSourceMode = SPDataSourceMode.List;
ds.EnableViewState = true;
ds.IncludeHidden = true;
ds.Scope = SPViewScope.Recursive;
gridViewNotAccepted.DataSource = ds;
gridViewNotAccepted.DataBind();
Now when I added new items, nothing appeared in my two Grid’s.. very weird because I specifically queried for both options right? I decided to remove the whole SelectCommand line and all of a sudden the newly added items appeared in both Grid’s! Aargh.. I tried to go through the items using a foreach loop and guess what.. it crashed! It gave the well known ‘"Object reference not set to an instance of an object."’ error. How come? Well.. it seems that when you define a field as hidden in the newform and you didn’t specify a default value for the field, the value of the field is not set.
How to solve this? Just by simply adding the defaultvalue of the field to the code like this :
field.DefaultValue = "0";
field.ShowInNewForm = false;
field.ShowInViewForms = true;
field.ShowInEditForm = false;
field.Update();
Hope this helps someone ;)
2 Comments
|
Posted October 21, 2008 - 09:19
by Robin Meure
in
Updated 2/11/2008
Check out Joel’s post Best Practices for Enterprise User Scalability in SharePoint where he does a deep dive on the User/ALC issue. Really recommended read!!
Please check out the SharePoint Security: Hard limits and recommended practices post by Eli Robillard in which some limits that are described in the TechNet whitepaper are updated. The big thing that surprised me was the following bit that supposedly is still unproven or fixed with SP1 :
Users listed in a Site Collection's User Info Gallery (aka SPWeb.SiteUsers): 1500 to 2000. No evidence can be found to support this guidance, and believe it to be a misinterpretation of the limit on ACL size. If you've been affected, please comment with further detail.
Plus an interesting limit that I didn’t knew of :
Users per SharePoint ACL: Query results must not exceed 64k, or ~1000 users per ACL. When exceeded, the "Parameter is incorrect" error is thrown causing crawling to fail on the item. This issue affects indexing, but does not otherwise affect SharePoint. The limit is noted by Joel Oleson in the comments of a "2003 to 2008 security changes" post and the Best Practices for SharePoint Search article on TechNet. The issue is not SharePoint-specific and will affect any content crawled with large ACLs including file system objects like Network Shares. KB article 885482 describes the cause as "The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB." Resolution: Either exclude the item from indexed content, or remove entries from the ACL. Mitigation: This is a rare issue normally avoided through sound design. However, since AD groups are not expanded when the ACL is read, assigning individuals to AD Groups rather than SharePoint Groups will mitigate the limit.
2 Comments
|
Posted October 20, 2008 - 08:49
by Robin Meure
in
That at the moment, is my biggest feature request for SharePoint vNext. Why you might wonder? Well.. currently I’m working on a project where we use SharePoint as an application platform. The first thing you do when creating an application is to set up an architecture right? One of the key things in SharePoint architecture is the choice for sites and subsites vs. sitecollections. Now just to let you know, this is not going to be a post about the whole sites vs. sitecollections thing but more a post about the things you need to consider when building an application using SharePoint.
For our application we came up with the following architecture :
The main advantages using this architecture are :
Now we also came up with another architecture :
Main advantage of this one is :
- Manageability of contenttypes and sitecolumns (pushing down changes of ContentTypes)
Basically what you want is a mixture of the two architectures.. Since contenttypes and sitecolumns are bound to a sitecollection, they cannot be inherited by ‘child’ sitecollections.
So the main challenge the past few weeks was to come up with an idea or solution to make this happen. The investigation began on what the ideal solution would be. Making use of the Content Deployment functionality or use ‘default’ OM approach. After having a quick chat with Chris and Serge, I was investigating this technique which I’m quite new at (never did much more than creating backup and restores of SPWebs) and my colleague investigated the ‘default OM’ approach.
Things we found or came across while researching for the proper solution :
- When a new sitecollection is being created and is being provisioned by the features, there must be an extra step to check if an update exists on the parent sitecollection to make sure whether or not apply an update on the just provisioned contenttypes and sitecolumns.
- Do we make changes to the feature files on the fileserver to make sure the contenttypes are always up to date? (not supported by MS)
- If we create an extra step/check why bother using .xml files to provision contenttypes and sitecolumns at all? Why not do it all in code?
- How do we handle changes to contenttypes or sitecolumns that are made by an user on a child sitecollection? Do we overwrite the changes next time an user decides on the parent sitecollection to change something?
- When using ContentDeployment only the listcontenttypes are changed and not the ‘master’ siteconttentype. So if we create a new list based on the sitecontenttype, this contenttype will be outdated.
A lot of questions that needed to be answered.. One solution to our problems could be to introduce a whole bunch of custom field controls that would be lookup fields to a list on the parent sitecollection to make sure every contenttype is using the same set of columns and values. But given the fact that we do have a lot of contenttypes and sitecolumns it would mean a lot of work to make this happen. So we decided to come with another architecture that is a mix of the first two :
Using this architecture we introduce the ‘semi-parent’ sitecollections how have subwebs. By doing this we have the ability to make changes to the contenttypes using the OTB mechanism and avoiding the 2000 security principal limit (a bit). The only drawback is that instead of letting the user change the contenttype on one place (the parent sitecollection), the user needs to change the contenttypes on the ‘semi-parent’ sitecollections as well. The reason why opted for this solution was
- We gained more insight in how many users are going to use the system and the need for unique permissions per web was not there. Everyone had the same rights on each web so we could make use of inheritance.
- The solutions we came up with didn’t really feel good enough to take it into production.
So the conclusion of this post is that if we would really like to use SharePoint as an application platform we really would like to have the ability to introduce contenttypes and sitecolumns on a webapplication level to make sure that every child sitecollection can inherit those contenttypes and sitecolumns. And/or make our features upgradeable to make sure if we don’t have webapplication contenttypes and sitecolumns that we can upgrade our manifest files and the existing lists using the contenttypes and sitecolumns are updated.
Update 15/10/2008
If you are wondering about what the OM code looked like, check out the Synchronize Content Types and Site Columns between teamsites post from Sander de Koning (which I discovered today.. a bit too late but good to see that we were on the right track ;)
1 Comments
|
Posted October 12, 2008 - 15:13
by Robin Meure
in
I received the following error while trying to retrieve listitems from a list that didn’t have the columns that I’d expect in my code..
I had a direct association with Underworld which, in my opinion, is one of the best bands ever! Karl Hyde (who is the front man of Underworld) has an obsession with the word ‘dirty’.. Maybe one of the developers of the product team is also a fan? ;)
0 Comments
|
Posted October 8, 2008 - 21:47
by Robin Meure
in