DTD folders in Custom

[douglaswade1]

I now have multiiple versions of Arbortext editor on the network. I
have a custom folder for each version. I want instead to place each
version of the doctypes folder inside the custom folder like
~/custom/doctypes-5.2 and ~/custom/doctypes-5.3 and so on...

I will place in the custom folder all the versions of the doctypes. I
want the ACL init file to read the version of the editor and do
conditionals to set a variable for doctype location. Really the only
difference for each version is the DTD need to be compiled.

I do not know the name of the doctype variable if any. I can figure
out the rest.

[bibach]

I don't think there's any variable or other setting to change which
folder within the custom folder Editor looks in for doctypes. I think
this is handled by some ACL code that walks through each custom
folder, running scripts, changing settings and adding locations to
certain options (like catalog and graphics paths) along the way. You
could attempt to influence or override this code, but perhaps there's
another (simpler) way which may meet your needs.

You can set APTCUSTOM to a list of paths and it will search them all.
So, have one custom folder for the things that are independent of
Editor version, such as certain scripts, menus, key mappings, etc.
Then, add a separate path for each version that holds version-specific
stuff like compiled DTDs.

-Brandon 🙂

[ClayHelberg]

Hi Douglas--

I haven't tried this, so I'm just brainstorming, but I think you'd have
to do this using the catalog path. I'm thinking of something like this:

In your init.acl file, set your catalog path to point to the location
you want, something like this:

$cat_path = get_custom_dir() . $main::PCS . "doctypes-" .
$version_release;
set catalogpath=$cat_path;

Each version-specific doctype directory should then have its own catalog
file, of course. I think that should do the trick.

--Clay

Clay Helberg
Senior Consultant
TerraXML

[AndyEsslinger]

That sounds like a bad idea.

The APTCATPATH variable points to the catalog file which is usually located in the DOCTYPE directory. The catalog can use relative paths to point to each DTD folder so that might be usable also. The problem is that when the user double-clicks on a "doc", AE will search the catalog and the first DTD with a "doc" will be used, regardless of whether it is for 5.2 or 5.3 or 6.0 or ??. Are you prepared to change each DTD to use a different DOCTYPE declaration in the document?




I would think it would be easier to have separate custom folders as there is an ENVIRONMENT variable (APTCUSTOM) that can be changed to point to the desired configuration depending on which version is installed on the machine. If you have two versions on the same machine then you need to start a batch file to set the proper variables.

-Andy

\/ AndyEsslinger LM Aero-TechOrderData
_____-/\-_____ (817) 279-0442 1 Lockheed Blvd,MZ4285
\_\/_/ (817) 777 3047 FortWorth,TX 76108-3916

[douglaswade1]

The only thing problematic thing for me is the size of the custom folders.
They are 317 megs each. It is a minor problem to copy a updated file to
four different custom folders. Our environment is weird. For example, in
our classified area, I use APTCUSTOM because I cannot push files to the
machine (security requirement), but I can push them to the file server, so
APTCUSTOM is set to look there. For laptops I use a sync program to keep
them updated, but that is problematic, because not all laptops are on at
sync time. We use them for telecommuting and few of us are full time. I
want to create a "pull" custom folder code, so the user can run it from the
menu in Epic to get updates, when there machines are on, after I send out
an email (that is another topic, unless some wrote some pull code, that
would save me some time).



d

[ClayHelberg]

Hi Douglas--



If you are interested in pushing updates, at least for newer versions of
Arbortext (5.4+), you could look into using zipped customizations. It's
a way to put your customizations on a server, and have clients grab an
updated copy when it's available (but use a cached copy when the network
isn't available). It's pretty slick, if you have a possibility to
upgrade to at least 5.4.



--Clay





Clay Helberg

Senior Consultant

TerraXML

[douglaswade1]

I would be fine with doing that. 5.4 and 6.0 are Window's 7 versions, and
we have to be all updated by mid year. Can you help me with the zipped
customizations?

d

[ClayHelberg]

There's not that much to it, really. Just create a ZIP file of your
entire custom directory and post it on a network location (or web
server) that your users can normally--or at least periodically--access.
Then set APTCUSTOM for your clients to point to the zip file explicitly,
e.g. "\\myserver\arbortext\custom.zip" or
" That's
it.



The first time a client connects after you set this up, it will download
the zip file and expand it in a local cache folder. From that point on,
every time the client starts up a new session, it will check for the zip
file on the network; if it finds it, then it will check the date and see
if it's newer than the cached version. If so, it will download the new
zip file and replace the cached version. If it can't find the network
copy, or if there has been no change, it just uses the version it
already has in its cache.



You can find documentation on this in the Help Center for 5.4 or 6.0. In
6.0, use "help 17122" for details.



--Clay





Clay Helberg

Senior Consultant

TerraXML

[naglists]

Hi Douglas,

It sounds as if you like Clay's custom zipped folder idea. Hope that works!
For what it is worth, we use a variety of commands to move files around in
a situation similar to yours. They may or may not play nice with the zipped
custom folder feature supported by more recent versions of Arbortext.

We use this set of commands in a batch file (that must be run manually,
outside of Arbortext) to refresh an entire custom folder (and most closely
solves your problem as I understand it):
rmdir "c:\Arbortext\appname\custom" /s /q
mkdir "c:\Arbortext\appname\custom"
xcopy \\servername\custom\appname "c:\Arbortext\appname\custom" /s /y /i


We use this ACL command (it shouldn't break across multiple lines) to
change a single file using a template that is already present on the user's
machine:
menu_add .Tools.* "menupickname" -cmd {execute cp
C:\Arbortext\appname\custom\file.txt
C:\Arbortext\appname\custom\doctypes\appname\file.txt}

I found this in one of our ACLs in editinit. I never use the variable
$batcmd and I can't remember if I couldn't get it to work or if subsequent
changes rendered it obsolete and I simply forgot to remove the line
creating it. Anyhow, it could be used, if it works, to call a batch file
from ACL:
batcmd = get_custom_dir() . '\batch\file.bat';


We use this set of commands to copy a single file from a network
location(including building a directory structure if necessary) if
that file is not
found locally and then open that file:
message "Copying filename.chm from network custom folder. Please be
patient."
if (! access('C:\Arbortext','e')) {mkdir 'C:\Arbortext' }
if (! access('C:\Arbortext\appname','e')) {mkdir 'C:\Arbortext\appname' }
if (! access('C:\Arbortext\appname\custom','e')) {mkdir
'C:\Arbortext\appname\custom' }
if (! access('C:\Arbortext\appname\custom\docs','e')) {mkdir
'C:\Arbortext\appname\custom\docs' }
copy_file "\\vm720dctmsql\custom_dctmsql\appname\docs\filename.chm"
"C:\Arbortext\appname\custom\docs\filename.chm"
message "Opening filename.chm ..."
sh hh $guide &
message " "

Note: The file is found present or absent using this:
if (access($guide,'e')) {}
The code above is the else{} clause.

[thendricks]

We use a batch script as well for customization in IsoDraw. Same basic principle however. I've updated to use a vb script in the start-up folder that points to a server-side batch file. The batch then can be controlled by the admin. Has been working for about three years now with no major issues.