I am trying to extract the field names from a list, but only those that are normally displayed in the edit/view-form. However, it is turning out to be more difficult than first assumed.
Filtering fields by simply not taking those with SPField.Hidden == true still yields a lot of fields that are not relevant in this context. A standard document library yields this result as example:
FileLeafRef, Title, CaseID, DocID, Finalized, Related, RegistrationDate, ItemSelectField,
ExtendedDocIcon, CaseRecordNumber, Local_x0020_Attachment, ID, ContentType, Created,
Author, Modified, Editor, _CopySource, CheckoutUser, _CheckinComment, LinkFilenameNoMenu,
LinkFilename, FileSizeDisplay, Edit, _UIVersionString, ParentVersionString, ParentLeafName
I have taken the internal names because I have a danish localized version of Sharepoint, but you get the idea. In the above Title, CaseID, DocID and LinkFilename and perhaps some more fields will be relevant - one thing is for sure, less than half of these fields are displayed when you view the item or insert a new one.
I tried the SPField.ShowIn* (DisplayForm, EditForm, etc.) but they're all set to null or false for all the fields.
Try this:
Custom Fields Only From Sharepoint List
In addition to Hidden, try taking out Fields where:
ReadOnly is true.
Type is Computed
Group is _Hidden
Related
In a JSF page I have to display the data from an entity.
This entity has some int fields which cannot be displayed directly but need to be translated into a descriptive string.
Between them some can have a limited number of values, others have lots of possible values (such as a wordlwide Country_ID) and deserve a table on the Db with the association (ID, description).
This latter case can easily be solved navigating via relationship from the original entity to the entity corresponding to the dictionary table (ID, description) but I don't want to introduce new entities just to solve translations form ID to description.
Besides another integer field has special needs: the hundred thousand number should be changed with a letter according to a rule such as 100015 -> A00015, 301023 -> C01023.
Initially I put the translation code inside the entity itself but I know the great limits and drawbacks of this solution.
Then I created a singletone (EntityTranslator) with all the methods to translate the different fields. For cases where the field values are a lot I put them inside a table which is loaded from the singletone and transformed in a TreeMap, otherwise the descriptions are in arrays inside the class.
In the ManagedBean I wrote a getter for EntityTranslator and inside the jsf I use quite long el statements like the following:
#{myManagedBean.entityTranslator.translateCountryID(myManagedBean.selectedEntity.countryID)}
I think the problem is quite general and I'm looking for a standard way to solve it but, as already stated, I don't want to create new 'stupid' entities only to associate an ID to a description, I think it is overkill.
Another possibility is the use of converters Object(Integer) <-> String but I'm more comfortable in having all the translation needs for an Entity inside the same class.
Your question boils down to the following simple line:
How can I display a field different from id of my entity in my view and how can I morph an integer field into something more meaningful.
The answer is that it depends on a situation.
If you solely want to input/output data, you don't need id at all apart from the possible view parameter like ?id=12345. In this case you can input/output anything you want in your view: the id is always there.
If you want to create a new entity most possibly you have a way of generating ids via JPA, or database, or elsehow besides the direct input from the user. In this situation you don't need to mess with ids as well.
If you want to use information on other entities like show user a dropdown box with e.g. a list of countries, you always have the option to separate label (let it be name) and value (let it be id), or even have a unique not null column containing the country name in your database table that will serve as a natural identifier. If you'd like to get data from the user using an input text field you always can create a converter that will do the job of transforming user input strings to actual entity objects.
Regarding the transformation of your integers, you've actually got several choices: the first one is to attach a converter for these fields that will roughly do 301023 -> C01023 and C01023 -> 301023 transformations, the second one is to write a custom EL function and the third one is to prepare the right model beforehand / do the transformations on-the-fly.
EDIT: Rephrased issue
I think there is either a bug or I am doing something wrong.
I add a field to the type Blogpost. This field is of type
Contentpicker. I call it Related Page.
Then I create to regular pages (ContentType Page).
I create 4 blogposts. Two blogposts get PageOne as selected value in the RelatedPage field. The other two posts get PageTwo as selected value in the RelatedPage.
Now I create a query with filter ContentType is BlogPost. And a filter with Blog Post.Related Page equals {21} (that is the Id of PageOne).
I would expect to get results BlogPostOne and BlogPostTwo. Instead I don't get results. Actually I wanted the pageid to be retrieved from the page the widget is placed on but couldn't get it to work, so I reduced back to a predefined value instead of dynamic for the filter. But like I said no results.
So is the query wrong and how should I do it then. Or is there a bug with filters for ContentPicker fields.
P.S. I will also submit an issue in Codeplex.
UPDATE
In Tokenizer all the values that contain { } are being seen as tokens and therefore are replaced. The problem is that the Ids of content items in a contentpicker field are stored with accolades. So when having {21} as the value for the filter, 21 gets tokenized and since there is no value for this token the value becomes empty. When skipping the tokenizer it works (while debugging). But one cannot skip the tokenizer, because it is very legitimate that there is a token present.
So I believe there is a bug with either the tokenizer, or the way the ids are stored in the contentitem field for contentpicker. I think it can be solved by changing the contentpicker to store numbers separated with comma's but without the accolades.
have you tried using the alias of the page instead of content id as the identifier? e.g. "/about-us", like you do in the layer rules.
I'm using Sharepoint 2010's web services interface to try to get the columns for a given list. I've got not problem with getting all of the columns using a GetList() call, but the issue is that I need to only get the columns that the user can see in the List Settings view of the Sharepoint UI.
The code that I'm currently using is as follows:
rootNode = serviceReference.GetList(List_id.ToString());
Element element = XElement.Parse(rootNode.OuterXml);
var fields = from e in element.Descendants()
where e.Name.LocalName == "Field" && e.Attribute("ID") != null &&
!(e.Attribute("Name").Value.StartsWith("_") && e.Attribute("SourceID").Value == "http://schemas.microsoft.com/sharepoint/v3")
select e;
Where serviceReference is an instance of the Sharepoint Lists Service and List_id is the GUID representing the list internally to Sharepoint.
This does filter out some of the columns that I don't want, but it doesn't get rid of everything.
Does anybody know what attributes I'm looking for to narrow it down just to the ones that the user can select to be added to a view? Or am I going about this entirely the wrong way?
Many thanks for any help.
The answer to this was that I was indeed looking in the wrong place for the information I needed. As user823959 pointed out, I needed to get the content type definition and use the fields in there rather than the list itself.
To do this was a two stage process, firstly we need to get the list of content types using the Lists.GetListContentTypes method (although this takes a content type id parameter, it doesn't actually seem to matter what we put here)
XmlNode rootNode = serviceReference.GetListContentTypes(List_id.ToString(), "0×01");
The CAML returned contains the definitions for each of the content types that are available in the list - with the first content type returned being the default one (in my case, the one I was after)
String contentType = rootNode.ChildNodes[0].Attributes["ID"].Value;
Once we've got the content type that we're after we can make a call to GetListContentType with the appropriate list content type id to get the full definition of the content type:
XmlNode contentTypeNode = serviceReference.GetListContentType(List_id.ToString(), contentType);
The CAML returned from this call will contain a list of field elements that correctly show the fields that are available in the SharePoint UI's view configuration. They can be selected in a LINQ query like this:
XElement contentTypesElement = XElement.Parse(contentTypeNode.OuterXml);
var fields = from e in contentTypesElement.Descendants()
where e.Name.LocalName == "Field"
select e;
At this point, we've got a list of Field XML elements that contain information about display names, static names, content types and a whole lot more. See Microsoft's documentation on the Lists.GetListContentType page for more information on the range of information returned about each field.
Many Thanks to user823959 for pointing me in the right direction.
My indexed documents have a field containing a pipe-delimited set of ids:
a845497737704e8ab439dd410e7f1328|
0a2d7192f75148cca89b6df58fcf2e54|
204fce58c936434598f7bd7eccf11771
(ignore line breaks)
This field represents a list of tags. The list may contain 0 to n tag Ids.
When users of my site view a particular document, I want to display a list of related documents.
This list of related document must be determined by tags:
Only documents with at least one matching tag should appear in the "related documents" list.
Document with the most matching tags should appear at the top of the "related documents" list.
I was thinking of using a WildcardQuery for this but queries starting with '*' are not allowed.
Any suggestions?
Setting aside for a minute the possible uses of Lucene for this task (which I am not overly familiar with) - consider checking out the LinkDatabase.
Sitecore will, behind the scenes, track all your references to and from items. And since your multiple tags are indeed (I assume) selected from a meta hierarchy of tags represented as Sitecore Items somewhere - the LinkDatabase would be able to tell you all items referencing it.
In some sort of pseudo code mockup, this would then become
for each ID in tags
get all documents referencing this tag
for each document found
if master-list contains document; increase usage-count
else; add document to master list
sort master-list by usage-count descending
Forgive me that I am not more precise, but am unavailable to mock up a fully working example right at this stage.
You can find an article about the LinkDatabase here http://larsnielsen.blogspirit.com/tag/XSLT. Be aware that if you're tagging documents using a TreeListEx field, there is a known flaw in earlier versions of Sitecore. Documented here: http://www.cassidy.dk/blog/sitecore/2008/12/treelistex-not-registering-links-in.html
Your pipe-delimited set of ids should really have been separated into individual fields when the documents were indexed. This way, you could simply do a query for the desired tag, sorting by relevance descending.
You can have the same field multiple times in a document. In this case, you would add multiple "tag" fields at index time by splitting on |. Then, when you search, you just have to search on the "tag" field.
Try this query on the tag field.
+(tag1 OR tag2 OR ... tagN)
where tag1, .. tagN are the tags of a document.
This query will return documents with at least one tag match. The scoring automatically will take care to bring up the documents with highest number of matches as the final score is sum of individual scores.
Also, you need to realizes that if you want to find documents similar to tags of Doc1, you will find Doc1 coming at the top of the search results. So, handle this case accordingly.
How do you create a lookup column to a Document Library that uses the 'Name' of the document as the lookup value?
I found a blog post that recommends adding another custom field like "FileName" and then using a item reciever to populate the custom field with the value from the Name field but that seems cheesy.
Link to the blog in case people are interested:
http://blogs.msdn.com/pranab/archive/2008/01/08/sharepoint-2007-moss-wss-issue-with-lookup-column-to-doc-lib-name-field.aspx
I've got a bunch of custom document content types that I dont want to clutter with a work around that should really work anyway.
I created a one step workflow to set the title from the name, fired on modify and created. Seems to work and took seconds to create.
One way you can do this (although not the easiest way) is by creating a custom field type that extends the SPFieldLookup class. SharePoint's field editor for Lookup fields purposefully hides any columns types that aren't supported by Lookup fields, but you can create a field editor for your custom field type that shows them.
However, I have created a Lookup column that points to a Name column in a Document Library before, and it probably doesn't work like you'd expect. While the value stored in the lookup column is valid, it doesn't show up right in List view or on the View Properties form.
The solution you posted may actually be the best way to handle this. Lookup fields require some kludges if you want to handle more complex scenarios, but that's because they're not meant to provide the same functionality as a foreign key relationship in a database.
Coding in any form always scares me. So Here's what I did: I simply renamed the Stupid "Title" Field to something else, say "Keywords", since you cant do anything with that field: cant even make it mandatory.
Then I created another Single line field called "Title" and used this field for the Lookups
Well there is a simple solution to that and in might work in some case.
In the nutshell if you make the Title field Mandatory, this will force the user to enter a title. In that manner we can use title field as a lookup field.
Now How to do that?
One you are done create a document library go to the library setting. Select Advance Setting and Select Yes for the option "Allow management of content types?".
Then go back to the Library setting and Under content types select the "Document" Content type. THen Select Title Column and then Select "Required (Must contain information)" and say OK.
Now try uploading a document to this document library. You will see Title field in the form.
Hope this helps
Cheers
Vaqar
You have to add the field as XML with the ShowField as 'FileLeafRef'
var XmlFieldDefinition = "<Field DisplayName='myLookupColumn' Type='LookupMulti' StaticName='myLookupColumn' Name='myLookupColumn' Required='FALSE' List='THE LOOKUP ID HERE' WebId='THE WEB ID HERE' UnlimitedLengthInDocumentLibrary='TRUE' Mult='TRUE' Sortable='FALSE' ShowField='FileLeafRef' />"
Field fld = fieldCollection.AddFieldAsXml(XmlFieldDefinition, true, AddFieldOptions.DefaultValue);
ClientContext.Load(fld);
ClientContext.ExecuteQuery();