Search This Blog

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.

8 comments:

  1. 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

    ReplyDelete
  2. You can set the FileSystemDataModule.FileSystemStoreLocation property to any location you want.
    Refer 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.

    ReplyDelete
  3. This works great but I would like to do save the file at a location like \\FileData\TypeName\Oid\AttachedFile

    Where 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?

    ReplyDelete
  4. This works great but I would like to do save the file at a location like \\FileData\TypeName\Oid\AttachedFile

    Where 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?

    ReplyDelete
  5. In my BusinessObject that attaches a file I changed the File Property like this

    [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?

    ReplyDelete
    Replies
    1. My comments:
      1. 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.

      Delete
  6. Hi Dennis,
    Is 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?

    ReplyDelete
    Replies
    1. @Павел: Yes, it should appear and function, because it is a standard scenario as far as XAF is concerned.

      Delete