This message may well apply to any app developer, who realize that his
app will access one or more "internal" files.
When creating a well-designed app, you are likely basing your code on
the Framework GW provides you, through the Framework app. Or, you may
alternatively produce similar coding. Whichever way, most cases your app
holds the main file with the code, along with an ini and an XML file.
Let's face it, these are the three "elementary" files of a fully
functional app. And due to the way GW has decided to build their
scripting environment, these three files basically need to be in the
User Profile folder, for any user who will need access to the app's
functionality.
Once in a while, your app will produce some temporary files. These could
be used for temporary storage of any information, or simply as clear-cut
dumps for information that has to be handled for a given moment in your
code. Whatever the purpose, they are only meant for rather short-lived
usage, and may not need to be stored for eternity. Good coding, of
course, would demand that you clear out any such files, once the code is
done with the contents. But there well enough could be times, when you
determine it will be best to keep this kind of files for a little while.
Next, we have the Log files. These also are meant to only store
information relevant to your app, and extremely rarely will be of any
benefit to any of the rest of apps installed on the end-user's computer.
Finally, we have what we best may name the "Assisting" files. This could
be any kind of extra material, that your app relies on for its
functionality and features. It may eventually be some kind of .exe
files, or it could be sound clips. Sometimes it could be different kinds
of text files. Let's also here include any kind of documentation files -
be it .chm, .html, .doc or plain .txt files. Again most cases, only your
app, will be the user of these files. Other apps may not have access to
the information here stored, or even have any interest of it. For
instance, the sound clips of your app are meant to be clearly distinct
from the sound clips used by any other apps. The documentation of your
app, does have nothing whatsoever to do with the apps constructed by me
or anyone else. Hence, let's face this fact as well, these ar internal
files, that only has a relevance and meaning to your app.
Looking at my User Profile folder, under Window-Eyes, I find a true mess
of files. There would be numerous set files and .we files, all connected
to the immediate behavior of my screen reader in different work
environments. Great, we won't bother about these, as they are there for
their clear purpose.
Next, i find a good chunk of .vbs files - or .vbs.wepm.crypt files (for
encrypted versions - all being the main code files of apps currently
installed on the machine, for the active user. Along with these, I find
the expected ini and XML files. GW did - at an earlier state - indicate
that they had some sort of idea on the slate, for a more tidy way of
installing apps. Leave that on the slate for the moment, as there is
little you and I as app developers can do about it, until GW releases an
updated environment for us to organize our apps in more tidy manners.
Consequently, these files will have to populate my User Profile folder,
and I can deal with that well enough. Typically, they will hold names
that clearly link them with the app they are representing, and if each
app only holds three files or so, it still won't disturb the
transparency of my folder.
But then, what do I find more in the User Profile folder? No less than a
ton of internal files, for whatever app it may happen to be. An app like
the ProgressIndicator, which comes standard as part of the modern
installation of Window-Eyes, has something like a hundred sound clips.
Clips that are meant to only be used inside this app, and which
extremely seldom will have any meaning for any other app on the machine.
Other apps, are loading down the folder with their sound clips, log
files, extra third-party software snip-its, documentation files - and
who knows what else. Sorry to say, but I do see little benefit in them
sitting here, and they sure are in my way when attempting to refind a
given file in my folder.
Try for instance, to look up a file that starts with cs, if you happen
to have the Hourly Chime app installed. You first will press C, and then
start arrowing down the list. Soon enough, you will arrive at CR, and
here you will have to scroll pass numerous files named something with
"Crystal" followed by a number. These are all files meant only for the
Hourly Chime app. Yet, there is no indication of that relationship. For
an end-user, it seems to be files that has no real value. And what if
she now decided to delete these files? Next time the Hourly chime goes,
the app will fail, and the user won't have a clue why. Then they
complain about the app's malfunctioning, you end up doing a ton of
error-tracing; all only to realize the cause of the trouble experienced.
Or, try to find a file starting with the letter P, and see how many
sound clips, you will have to scroll by before you hit your final
choice. We could go on with several examples, samplifying the anoyance
of all kind of internal stuff, for different apps. It is truly messy,
gives a lot of extra work in finding needed files, and may only serve to
confuse less educated users.
The Solution
Although GW has not yet released an environment that lets us organize
all our app content into corresponding subfolders, there still exists no
limitation as to where your app stores its internal stuff. It is totally
and fully possible for your app, once running, to pull its information
from internal files that are stored in a distinct and corresponding
subfolder. Or, for that matter, a folder anywhere else on the computer.
Basically, even your Ini and XML files, could easily be transfered to
reside inside an app-related subfolder. You just need to modify a
handful lines, in the code produced by the Framework script. Same goes,
whenever your personal code attempts to derive information from any
file, or base its functionality on such internal files. They can be
accessed, no matter where they are stored. And what's the real good
news, it does take very little extra effort for you as the developer, to
have this happen. Let me show you one simple example, which you can
modify right into any of your app codes, this very afternoon, smile.
Imagine, you are developing an app, which we call MyNewApp. It will base
some of its activity, on two files - a sound clip named MySound.wav, and
a documentation file named MyDoc.txt. Typically, your current code,
would look something like this:
Set FSO= CreateObject( "Scripting.FileSystemObject")
PlaySound( "MySound.wav")
MsgBox FSO.OpenTextFile( "MyDoc.Txt", 1 ).ReadAll()
Note: I have cooked the sample code here, down to a minimum - only
dealing with the actual lines of interest for the example. Your code may
likely hold several more lines, to ensure error-free execution.
Now, we want to do things in a more tidy way, moving all our internal
stuff into a subfolder, related distinctly to our app. We could have a
subfolder named the same as the app - MyNewApp, or MyNewAppFolder. For
the clarity of the sample code, I suppose you have named it
MyNewAppFolder. The two last lines of the above sample code, now will
look like this:
PlaySound( FSO.BuildPath( ClientInformation.ScriptPath,
"MyNewAppFolder\MySound.wav"))
DocFileName = FSO.BuildPath( ClientInformation.ScriptPath,
"MyNewAppFolder\MyDoc.txt")
MsgBox FSO.OpenTextFile( DocFileName, 1 ).ReadAll()
Not too different from the above, is it?
We use the ClientInformation.ScriptPath function, to retrieve the full
path string of the current User profile folder. You likely already do
so, in all your file requests, to ensure you will find stuff stored in
that folder and nowhere else. Then, we make use of the
FileSystemObject's method of BuildPath. This only to make sure that a
proper complete path string is produced, when we combine the app-related
subfoldername, with the current ScriptPath string. For instance, it will
automatically insert the needed backslash between the two strings. Then,
we quickly request the file from the produced pathstring, which means,
we pull the file from the app-related subfolder. You now can store all
your internal stuff directly inside this subfolder, clearing up the
transparency and user-friendliness of the user Profile folder itself.
'''Updating Your Code'
Then how about all your existing apps? Will you have to do a ton of
modification to have them go more tidy? As shown above, only minor
modifications may be needed, in your internal file requests from inside
the code. And, you can easily enough have your app sort its stuff into
the app-related subfolder as well, through the installation process. For
new packages, i do suggest that you could have all the internal stuff
packed up in an executable file (.exe), and simply run this as part of
the installation process. This is what I do in the Extended Dictionary
package. It does take a bit of coding, and you will need a means of
packing the needed files into an executable, but it all can be done.
Another - and perhaps just as effecient - way of handling things, would
be to let all the files be unpacked into the User Profile folder, and
then let your app have a sub-routine that moves all the stuff into the
app-related subfolder. This routine could be constructed the way, that
it will create the subfolder should it not already exist, and then
simply just move any of the internal files over there, one by one. If
now, you let your app always run this "moving" routine at the very
startup, you need not worry if people just updated to your new version.
Any of the files that exists from the previous version of your app,
would then be moved into the app-related subfolder, and hereafter be
accessed from there.
One Single Drawback
It would be greatly encouraged to do this kind of tidy app organizing.
Look at any of the professional software you buy and install, and most
of them will have their stuff sorted into a software-related subfolder -
somewhere on your system. Not really aware of any other software, that
so consequently installs all its mess and internals, in one big hive.
Yet, there does exist one tiny drawback to this approach of app
developing, long as GW has not updated their scripting environment. To
what extend they can do so shortly, or if this will have to be dealt
with at a later state, I do not know.
The drawback is, that if the user decides to uninstall your app, the
current environment will only uninstall what is stored directly in the
User Profile folder, and was originally included in the .WEPM package of
your software. That means, if you put things into the app-related
subfolder, it will not be automatically removed as part of the
uninstalling process. The user will have to remove the stuff manually.
Not a big deal, your documentation could give instructions. And since it
all is stored in one subfolder, all the user has to do, is to go to his
User Profile folder, locate the app-related subfolder, and hit Delete.
On the other hand, since the stuff does not get removed through
uninstallation, you could use the approach to make sure the user does
not loose settings, or other important data, if he temporarily removes
the app from the computer. It even makes it a breze for the user, to
transfer all the internal things, to another computer, and your app
could even offer this kind of features. Compared with the rather small
extra step needed through uninstallation, the organizing of app-related
subfolders, really holds that many benefits for both you and the
end-user, that I do stress its importance once again.
Friendly reminding you,
--
David
