File naming convention

Jeff Massung massung at gmail.com
Tue Jan 25 15:10:03 EST 2011


On Tue, Jan 25, 2011 at 6:11 AM, David Bovill <david at vaudevillecourt.tv>wrote:

> I have the need for an ugly file name hack. I need to store documentation
> about arbitrary files (.html, .png, .livecode etc files) in a separate
> folder (called "docs"). These files will be served by a web server - and
> map
> directly to the original source code files so that a file "hello.txt" with
> correspond to a file named something like:
>
>   1. docs/hello.txt.html
>   2. docs/hello.txt/index.html
>   3. docs/hello_txt/index.html
>
>
Just tossing out some other possible solutions (not that your suggestions
are bad or any of these are better, just trying to think outside the box a
little)... Also, it's hard to know from your email whether or not these will
be options for you if a customer's requests are driving this work or not.

- Use a database to map from source file -> documentation. This way no hack
is needed and it mitigates future problems, like what happens when someone
goes back and renames hello.txt to hello_world.txt?

- Don't have a "docs" folder, but instead make the documentation file sit
right next to the source file. This will get more cluttered, but what do you
do when someone has /source/hello.txt as well as /source/world/hello.txt?
Your docs/ folder will have to somehow understand there are two files with
the same name that are different.

- Create a documentation file per folder instead of per file. For example
/source/docs.html, while handles the documentation for all files in /source/
and /source/world/ will have a docs.html file for everything within it.

- Depending on what types of files you are dealing with, you may be able to
read/write metadata to the files detailing documentation - or linking to the
documentation so that it isn't algorithm-based.

Every solution will have its pros and cons. I think it would help
considerably to identify your biggest concerns/issues and then pick the
solution that best solves those. Enumerating things from above and just
random thoughts:

- Multiple files w/ the same name in different locations
- Renaming source files (documentation "link" now broken)
- Moving of source files to a new location ("link" broken)
- Ease/difficulty of editing documentation files
- Potential filename limitations of documentation (length limit)

Jeff M.



More information about the Use-livecode mailing list