I want a file download on my page where I look up the attachemnts to be displayed from another document based on the value of a field.
I tried a couple of things including returning the value obtained from NotesRichTextItem.GetEmbeddedObject but everyting I try I get the error java.util.Vector incompatible with [Lcom.ibm.xsp.model.FileRowData
What do I need to call to return a proper value to my file download control?
I realize I could proably display the attachment links using a repeat control but was hoping there was an easier way.
The FileDownload control requires a NotesDocumentDataSource. There's no way around that. So you could add a panel to you page, add a Notes Document DataSource to that panel that computes the UNID of that document, add a file download control bound to that panel and you are good to go. The FileDownload control will show all files in that document.
Keep in mind: an XPage is not bound to a (one) document and can contain as many data sources as needed.
If you want to construct the URLs yourself, check the cheatsheet
Related
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.
I need to be able to download a file out of SharePoint (to send externally) that has the version number in the file name.
Is there any way to do this without custom code? If not, how would I code this?
File in SharePoint -> Specifications.doc
Downloaded file -> Specifications V99.doc
I use SharePoint 2007, but I am also interested in a 2010 solution.
Don't think it's possible out of the box. As for manual implementation I see two ways:
1) If you can use some external application (or, for example, webpart or page) to do that, just get sharepoint file as binary stream and save it with the name you want.
2) If you need it to look like standard downloading, add a new custom button to document context menu (Ribbon in SP2010) and again do whatever you want with that document when user clicks the button.
This is about as close as I think we can come at this time:
http://spversionindocs.codeplex.com/
It allows you to have a version number field in your document that is automatically updated with the version number from sharepoint.
I know that a Document Library in SharePoint 2007 has a multi-file uploader (an ActiveX control that -- and only if you have Office 2003+ installed) but how would I use this same feature with a normal (non-document-library) List item?
Uploading files to a normal List item involves clicking the "upload" link and browsing/uploading files one by one. Is there a better way than this? Surely there must be.
Jake
There is an approach I use, but there is no UI support for it. You may find it a bit tedious for onsey-twosey uploads, but it saved me hours once for serious bulk uploads.
The same WebDAV functionality that we get when using "Open with Windows Explorer" on a document library is available for a list.
Say I have a list at http://myorg.com/sites/Widgets/Lists/MyList.
I can open the list in Windows Explorer by going to the address \\myorg.com\sites\Widgets\Lists\MyList.
Attachments are stored in the sub-folder Attachments, which contains folders with numeric names (1, 2, 3, ... and so on). The numbers correspond to the item ID of the list item. Pick (or create) a folder with the ID corresponding to the item you want to upload to, and it's drag-and-drop from there.
Short of writing your own mulit-file upload web part I think you are going to be stuck with either one at a time (i.e. an attachment to the list item) or switch to a document library. Don't forget that you can customise your library to behave much like a list.
Why is it a problem to use a document library?
I seem to be making a habit of answering my own questions. Not sure if that's a good thing or not.
What I ended up doing was adding an "Upload Multiple Files" button to the toolbar which pointed to a custom ASPX page in the _layouts folder. This page displayed the ActiveX component used by a Document Library and the "post to" URL for it was the ASPX page itself. When posted to it looked for files uploaded and attached them all to the List Item referenced via URL parameters passed to it from the toolbar button.
It's discussed here:
http://weblogs.asp.net/nathanyorke/archive/2007/12/05/uploading-multiple-files-via-the-web.aspx
If I get round to blogging and fuller explanation on my own site I'll try and remember to post a link back here.
Jake
I'm trying to build a form for WSS 3.0 which has the following two characteristics:
Have several sub-records in each records which contains few specific fields.
Can export to HTML or something similar which can be viewed in every browser.
I realize (unless I'm mistaken) I can achieve 1 only by using InfoPath and RepeatingSection/RepeatingTable/etc.
As for 2, I see InfoPath is only capable for exporting to MHT/PDF/XLS, none ideal for me, since the goal is to create a something that can be published to the web.
Any hints about better way to achieve this?
Correction for 2: I meant that the InfoPath form should be editable within our intranet, but exported as a read-only-web-page for our web site. So I meant "exporting" and not "publishing".
One way to do this would be to use a database as the primary data source for your forms, so that all form data is saved there. You could then build a website that queries the database for all info.
Another alternative would be to take the infopath form data (saved as an xml file) and publish it on a web server with an XML Style Sheet to define its format. You could do this via an XML control in ASP.net.
These solutions might require more elbow grease than some other solution, but I believe either would work.
Perhaps creating a custom fieldtype is a possiblity. Create a fieldtype that has some kind of collection as value.
As for 2, I see InfoPath is only
capable for exporting to MHT/PDF/XLS,
none ideal for me, since the goal is
to create a something that can be
published to the web
That's not right, InfoPath forms can be published to the web. When publishing the form to the SharePoint via the InfoPath client, you can select an option saying that this form should be editable within a browser. But beware that some form features of InfoPath are not available when you do that.
Or do you have a different understanding of "can be published to the web"? For me it means, creating a new item in the library to which the InfoPath form is attached to --> Form is opened in the browser --> user fills in the form --> user klicks the save button --> info path document is saved to the library and closed.
Just an idea:
If InfoPath (along with MOSS) is not an option, then perhaps you could mimic its behaviour through a custom edit form, if you want the data to be outputted into a SP list. I'm thinking about a custom edit form with dynamic html controls (for the sub-records), and you can achieve this by dynamically inserting objects into the DOM as your tree structure requires. Then, on form submit, an event handler on the list would parse the data submitted by the form and store it as you see fit (in an xml serialized in a custom field, for example).
If it's not going the be a custom edit form for a list, then the same functionality above can be stored in a site page with code-behind (beware of customizations) and use a hidden SP list as your data storage.
As for the exporting section, perhaps an application page linked in the ECB menu of that list would get the above mentioned xml and display it nicely.
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.