Document centric application

crs

Newcomer
Joined
Jan 29, 2009
Messages
2
Hi there,

This is my first post here, and I hope I'm posting to the right section of this forum.

I am seeking help for building a document-centric application. More specifically, handling extensions and icons for the different file types the application is going to manage. I know how to register extensions within windows, but I'm just unsure how to do it inside my own application!

My current design is something like this:

Each document has it own class (the documents are actually just the objects serialized, gzipped and stored on the disk). Those can be extended through a plugin system (with external dlls being loaded during runtime), so the number of file types may be extended at will. Each file type should have its own extension and can have its own icon. I'm using multidotted extensions to keep the naming scheme sane.

To define a new document, thus a new file type, one has to implement an interface, lets say, IDocument, which has common properties like Name, Description and Remarks, and then define what his document will contain.

Now, the problem is: Where should I specify which will be the default extension and icon for the particular document class I'm writing? At first I thought about adding static properties to the interface in order to assure its implementation but I know interfaces cant have such things.
I need to be able to, given an extension, return the System.Type of the related document, or given a type, return its extension. I could write a table of extensions and related types, but then how could I enforce every class that inherits from IDocument will register itself into this table?

It should be mandatory for a document to have a extension, but I can not think of a way to enforce this rule. Sorry for the long question, I just hope I could explain what I'm trying to achieve :).

Thanks in advance,
 
Could this information be stored elsewhere and loaded as part of the plugin load process?

#Develop has a system that although complex could be simplified for your needs. Each plugin has an accompanying config file (xml in their case) which contains information regarding file extension etc.
 
Actually, I did download and read some #Develop sources before I started this thread, and even stared on the sources for more than an hour or so before I gave up trying to understand how it works. In fact, the application I'm developing has many other things in common with #Develop but no matter how long I explore its source I always get lost trying to follow its logic.

But you gave me a nice hint. You're right, I don't have to store this information directly on the classes! I think its possible (and probably easier) to just use metadata along the classes and then retrieve them by the use of reflection.

Lets see if this will work. Thanks! :)
 
Back
Top