DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Thursday, October 25, 2012
Working with links to files instead of storing their contents in the database
If you read my previous post about a reusable File System Data module I created some time ago, you might remember that it included a custom IFileData implementation (this simple interface/contract is used by our buit-in File Attachments module that provides a generic solution for working with files in both desktop and Web apps). My solution was designed to work with links to real files instead of storing their contents in the database. Before today, it had a small issue that does not allowed you to keep changes to files opened from these links (e.g., you opened a *.docx file in Word, edited it and then saved), because a temporary copy of the file was created by default. I discovered this issue with the help of a customer (thanks, Will!) and updated the E965 example accordingly. The fix was in handling the CustomOpenFileWithDefaultProgram event and using the Process.Start method. Now, everything operates as expected:
View on screencast.com »
This is just yet another example on how our eXpressApp Framework is flexible as well as on how the community feedback is important to run our mutual progress.
Hi Gary,how do i use this module and set the path to store the file? Which part of the XAF code can i use to set the path? I am still new to XAF
ReplyDeleteYou can set the FileSystemDataModule.FileSystemStoreLocation property to any location you want.
ReplyDeleteRefer to the module's source code at http://www.devexpress.com/Support/Center/e/E965.aspx for more details.
If you experience any further difficulties, please contact our Support Team (www.devexpress.com/sc).
PS
My name is Dennis, not Gary.
This works great but I would like to do save the file at a location like \\FileData\TypeName\Oid\AttachedFile
ReplyDeleteWhere TypeName is the name of the type that contains the attached file
This way I do not mangle the original filename with a guid just to make it unique.
Any suggestions?
This works great but I would like to do save the file at a location like \\FileData\TypeName\Oid\AttachedFile
ReplyDeleteWhere TypeName is the name of the type that contains the attached file
This way I do not mangle the original filename with a guid just to make it unique.
Any suggestions?
In my BusinessObject that attaches a file I changed the File Property like this
ReplyDelete[Aggregated, ExpandObjectMembers(ExpandObjectMembers.Never), ImmediatePostData]
public FileSystemStoreObject File
{
get { return GetPropertyValue("File"); }
set
{
FileSystemStoreObject fileSystemStoreObject = value;
fileSystemStoreObject.DocumentType = "Supporting Document";
SetPropertyValue("File", fileSystemStoreObject);
}
}
Then I stuck a DocumentType Property onto the FileSystemStoreObject like so
public string DocumentType { get; set; }
and then
Changed RealFileName to
realFileName = Path.Combine(FileSystemDataModule.FileSystemStoreLocation, DocumentType, Oid.ToString(), FileName);
What do you think?
My comments:
Delete1. If you guarantee uniqueness, this approach looks fine.
2. It's better to implement the DocumentType property (as any other persistent property) with change notifications.
3. You may also want to handle future DocumentType property updates.
Hi Dennis,
ReplyDeleteIs it works with inheritance?
For example, there is BaseDocument abstract class and PersonDocument is descedant of BaseDocument. If I define FileSystemStoreObject type property in BaseDocument, does this property appear in PersonDocument detailview?
@Павел: Yes, it should appear and function, because it is a standard scenario as far as XAF is concerned.
Delete