How can I best create a SharePoint list view that shows only root folder contents? - sharepoint

I have a custom SharePoint list definition that is based on the Document content type. My library instance that I create from this contains many HTML documents, and each of those documents has some images saved into a subfolder inside this library. What's the best way to create a view that will show all of those top-level HTML documents without showing all of the image accessory files? I'd prefer to define this within the schema.xml file for my list definition.

I believe adding Scope="FilesOnly" to the View tag in your list definition should do the trick.

Related

SharePoint - Document Filtering (Tags/Metadata?)

I'm creating a SharePoint site which will be used to dynamically store and display documents on various pages, among other things. Is the following possible?
My view is to have one central Document Library which will include all files. Files with have 'tags' or 'metadata' attached to them. On pages, i will add a document library (or similar) webpart and then call only those documents with a certain tag/metadata.
For example.
Document Library ('Folder') - Contains ('Project Document.xls' and 'Training Document.ppt')
On 'index.html' i will add 'Folder' to the page, but i only want to display 'Project Document.xls' not 'Training Document.ppt'.
I'm aware that you can set up target audiences but that requires a lot of user management.
Thanks for any advice.
If I understand you correctly, this sounds like something you could accomplish using a filter. The name of the file is stored as a column. Try editing the web part on that page and edit the current view. That view will be cached for that page without changing the view across the site. If you want to be able to dynamically choose the document you display then one option is to add an HTML Form web part (which contains a text box and submit button), connect it to the doc library web part and filter the name column based on the HTML Form web part.

How to configure multicolumn header in sharepoint list?

I am having a sharepoint list. I want to group the columns.
For a clear understanding of my requirement, please see the image below:
Is this possible in sharepoint list? I am using version 2010.
It is possible to render List View for XSLTListViewWebPart (XLV) with custom columns header layout including the specified grouping. It is XSLT based solution that does not requires any custom coding.
This could be accomplished with SharePoint Designer, see for example Create a custom list view using SharePoint Designer
Below is described similar solution, but instead of modifying XSLT inside List View page, we will create separate XSLT file for it.
Steps
Create Custom View for List.
Create custom XSLT style sheet for rendering custom header layout in that view. Source code for this example is located here.
Save it for convenience in the same location where List pages are resides as shown on picture below
Open Custom View page in SPD and specify in XLV properties XSLink property as shown below on picture
Save changes.
List with custom View is shown below

SharePoint: Site Collection Images vs Images vs Style Library Images

Something I've been wondering. Is there a best practice or rule of thumb on how to store your images? I see 3 ways currently:
Site Collection Images
Images library
Style Library/Images
My rule of thumb has been: if you have only 1 site collection for your project, then use the Site Collection Images. Otherwise, create a folder structure like: /Style Library//images.
What is the difference between Site Collection images and the Images library?
Images lib provides a thumb view by default while the Style lib/images just treat images as files.
Site collection images? I think it's just another name of the Style lib/images of the top site.
Site Collection Images is a carry-over document library from the 2007 Publishing Feature. It's a document library but with multiple content types assigned to it (Image, Audio, Video). There's a thumbnail view associated with some of the content types so you get a nice preview of an image.
Images is a new library called and Asset library but in reality and behind the scenes, it's exactly the same as the old Site Collection Images document library with the three custom content types assigned to it. The only difference I can see is the icon used for the library.
Style Library is just a regular document library with no content types associated with it. It's created as part of the Publishing feature and pre-populated with some basic images, css files, and xsl style sheets (that are used with the DataView Web Part).
My standard (if you want to call it that is this).
A new folder for your site in the Style Library (sitename) with subfolders of "css", "js", and "img". The reason for this naming is that some libraries, plugins, and other addons will look for this type of structure (with CSS doing a relative path to an "img" folder to look for images). So it keeps things compact and identifable.
I choose to put CSS, JavaScript and Images here rather than creating separate libraries for it all. CSS is for (obviously) style sheets. JS is for javascript. This would include jquery (in the root js folder) or jQuery plugins (in a separate folder for each plugin). IMG is for CSS icons, system icons (e.g. twitter badges, etc.). I find this layout just handy and doesn't hurt anything keeping it all together.
I put regular photo content into Site Collection Images since a) it gets automatically populated when you create a publishing site or activate the feature and b) it's easy to find when inserting pictures into a rich content field. I'll just hide or tell the users to ignore the Images library (it can't be deleted because it's part of the Publishing Feature).
Hope that helps. YMMV.
I'd add that the style library is also different in that it's contents are readable by all users even if you have removed their permissions to the library or an item within the library.

Sharepoint 2007 Custom List Templates

Hi I am wanting to create a little tutorial on how to create a webpart that I have added to one of the website's I have created.
I know that there is the List Templates gallery in which I could use to give this part as a file however I am using Site Columns.
Due to this will this cause errors when importing to a new Site?
Will the user need to create the Site Columns previously and will they automatically be used once importing my Custom List file?
or will when it is imported the column appear?
I don't currently have another site to test this on as yet so was wondering if anyone here already knew the answer for this?
Any light that can be shed on this question is very much appreciated and thanks in advance as well =]
I am totally confused by your question. How are List Templates gallery and a custom webpart related ?
Probably you meant site Template Gallery ?
What you need to do is :
- Create a solution package
- Create two features - one for your custom columns and custom webpart
- Optionally create a list template feature to define the columns in the list.
If this is truly a list template (you created it by going into List Settings and selecting Save As Template), then the site columns, content type, and list schema should all be contained in the manifest.xml file inside the stp file. You should not need to create anything manually to generate a list based on a template uploaded to the List Templates Gallery.
If this is a list definition feature, then you should create features that define the site columns, content type, and the list definition. The users can manually create site columns that match on name, type, and just about every other attribute, except the one that matters most - ID. Each time a site column is created in the browser, it will be assigned a different ID. That ID will not match what you have defined in your list definition.

Global Customized View for Document Libraries in Sharepoint

In Sharepoint document library, when we create a new document library, the default view is 'All Document'. This one:
We can make a custom view from View > Create View (at the upper right corner of document library view). I created a new standard view and named it 'Chromed View'. I edited it, then I saw that this view only applied on current document library:
The other document libraries cannot use this view.
I develop a system that triggers document library creation from CRM (the document library's view from CRM Iframe is using that chromed view). The creation itself went well, I can create document library using Sharepoint web services. But I still cannot apply a custom view automatically for that newly created doc lib.
My question is, can we make a view that is global (not in one document library only) so that we can use that global view for any document library.
Thanks b4 for any opinion :)
You could also create a new custom document library type, with the view embedded in it. Whenever a new library is created from the new doc lib type, it will get the new view.
This is still a not truly "global" view, and you may have the same problems if the view gets changed (the view won't be updated on document libraries that have been created with previous versions of the view).
One way to do this is to create a feature with an event receiver. When a user creates a list, you can check if the list is of the proper type (101), and then add new views to it. The feature could also add this view to existing document libraries on activation. Shouldn't be too much of an effort.
The view is not truly global. As list definitions are duplicated for each instance, there are no such thing as a global view (afaik) in WSS. We could all hope that views are a part of content type in the next version.
To globally change all document libraries and to change all existing libraries you need to edit the XSLT file that is in the XSL folder in layours/templates
There are a couple of them in there but these are how all the libraries are generated with this u can basically specify how a default"" library would look. Make sure to make a backup for these files though. Also creating a new content type and copying these xlts to a different file name and then linking your content type to these instead could also be a solution so when a user creates a new library using ur content type you can make sure that they are created in a way that you want.

Resources