I have a requirement from a client to modify the treelistex field to include a search box on top of the left content tree list box. This will allow searching of items instead of the user having to click through the content tree. This Sitecore installation has pages numbering in the thousands hence clicking through takes time and knowing where the page item exists.
How can I achieve this functionality? I will use the _system Lucene index from Sitecore to search the various items. The items need to be search based on item name, title field, content field and date fields.
Thanks
Interestingly, something just like this was posted to Shared Source the other day! Check out the Specialized Treelist from Shared Source.
Search using the built in Sitecore Lucene indexes
I am using Visual Studio 2010, SharePoint 2010 with custom document content types and forms. And plan to also use jquery to build the document add/edit/view forms.
I am developing a solution where I want to have a document library where each document uploaded also has a number of external data elements added as metadata.
The tricky part I'm trying to figure out is I want the user to be able to specify and add a multiple number of those same external data elements.
I'm trying to figure out how I represent the data internally in SharePoint. My initial thought is to programmaticly add hidden external fields as the users adds those external selections. But then I also think of simply storing those external elements as non-external text fields but have my own code which performs the external data lookup and validation.
I'm not adverse to significant custom coding, as I'm probably going to need to do a lot anyway since even the user interface is going to be a jquery tabbed form to enable all the external data the user will be able to associate with each SP document.
I've made an attempt to hopefully further explain what I'm trying to do and included that image. Essentially I'm wanting to add 1+ external data relationships to each document, as desired by the user.
It uses just example data. I'll actually have 4-7 different complex relationships much like the example. And the user is permitted to drilldown and select 1, 2 or all 3 of the dropdowns.
Think of it as similar to how here on Experts-Exchange we can add multiple zones to a question.
An example illustration is here: http://flic.kr/p/aFUSJn
Could you simply add a multi-line text column and have the user input the metadata with comma's, then use your code to seperate the data and do what you want with it?
You said you were not adverse to significant custom coding :)
One solution is to use SharePoint content types. The trick is that not all items in a list need to have the same content type.
Therefore, you can do the following:
As the user is selecting the fields he wants to use you generate or select a content type that matchs those fields.
You then add your document to the document list using the content template
You then have all your information strongly typed in SharePoint lists.
We have previously built a system where we generate content types based on xsd files, this worked very well.
I am writing a custom Sharepoint solution and I have to fulfill a requirement that an item in 1 document library must be visiable in another document library, e.g. maintaining global company document which should display in all other librarys
I need to sync properties, e.g. name so that when it changes in the source list it should also change in the destination lists. The items created in the destination list should not be able to have workflows or other options in the ECB Menu (exception for maybe going to source document).
Does anyone have a realistic solution on how to accomplish this ?
I have been trying to use CopyIntoItems of the copy web service to create linked copies with no luck, it always just creates a new copy of the source item (see: http://platinumdogs.wordpress.com/2009/01/14/sharepoint-moss-creating-document-library-items-uploading-files-to-a-document-library/)
Creating a custom content type has also entered my mind (since the source properties is contained in a content type) but then how do I filter the ECB menu ?
If the destination document library is a replica of the source document library, can't you solve this by displaying the items on the destination side using a content query web part instead of duplicating the items?
In the process for googling for something else I might have come across the solution to your problem.
Apparently Sharepoint has a built in 'linked document' type. You can just use that to link the documents, instead of copying.
More info here.
I'm developing a customized document library in the SharePoint 2007 environment. What I'm doing is creating a content type with multiple columns of information related to the document. Users will use this content type to upload new documents rather than the standard new document functionality. One of my columns in this content type is proving to be more difficult than I can handle.
The column is essentially supposed to be a sort of 'related documents' column, where it offers the user the option to select another document that is related to this document. So I thought I'll create a lookup column that displays the titles of all other documents in the library and allows the user to choose one. Simple enough, but I need much more functionality than this...and here is where I need help.
I need the related document column to actually link to the related document, not just display the title...not in edit mode while a user is adding a document, just in the standard document library view after the document has been added.
I also need the link to include a url variable that is stored in another column named 'Document Number'.
I assume this will require custom coding which is fine. Please not that I can't use SharePoint Designer. I use Visual Studio and code must be C#. This will be packaged and released as a feature.
Can anyone help me acheive this? Example code, suggestions, etc...? Thanks!
I would suggest using a multi-column field as your base value type - this article on MSDN should get you started. For rendering the field in document library views, you will need to use a rendering pattern. Conveniently, MSDN has an example of a multi-column RenderPattern.
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.