Usually, I try to present information in a clear, organized manner. However, that's not the way I work on a day to day basis. My thoughts are usually organized in brain dumps. Basically it's a bunch of idea fragments loosely tied around a central concept.
As the Vault API matures, certain patterns emerge on how add-ins should work. I've been making notes on these patterns, but I don't have anything well organized yet. So here is my current brain dump. This is a bit of an experiment. Maybe some people will find this useful. Or maybe not, in which case I'll abandon the format in future posts.
What are the common patterns in Vault customizations?
Admin-specific vs user-specific features:
- Customizations usually have a mix of commands, some for the Vault administrator and some for the end user.
- Admin commands are usually related to configuration.
- User commands are usually the things that do the real work.
- Admin steps are sometimes needed before user features are available.
For example, Vault Web View can't be used until the Vault admin designates a URL property.
- Admin settings are best stored in the vault. Vault Options are a good way of doing this.
- User settings are best stored on the local computer.
- Custom tabs are always shown for a given object type. This aspect limits it's use. For example, a tab that shows layer information about a DWG is useless for every other file type, resulting in UI clutter.
- Custom jobs are usually what you use when you want an operation to happen "on the server"
- Job processor extensions are usually double sided. You have the customization that adds the job to the queue and you have the job handler that executes the job. These two components will almost always have code to share.
- It doesn't matter how cool your blog is or how many emails you send out, you still have to keep reminding people that you already wrote an app for that.
Got more to add? Drop me a comment.