Results 1 to 10 of 10

Thread: Template Design

  1. #1
    3 Star Lounger
    Join Date
    Jan 2001
    Location
    Christchurch, New Zealand
    Posts
    250
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Template Design

    This is a fairly general question, however, I am trying to work out the pros and cons of the different ways of developing template sets.

    Currently I have a master template that sits in the Startup folder and contains all the code that is used to populate the files created from the Workgroup templates. The workgroup templates are layout templates only and don

  2. #2
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Template Design

    Karen,

    We've recently moved to a somewhat similar setup, where global code sits in a global template in the startup directory, and code specific to individual templates sits in the individual templates. In each of the individual templates, we set a reference to the global template. This seems to be working fine, and developing with it is not really harder once you get used to a few working practices:

    The directory structure in your development environment should parallel the directory structure in your live environment - that is, global template in the startup directory, and workgroup templates in the assigned workgroup directory. This is one way to help ensure that the conditions you're developing in are going to be the same as the conditions the templates are run in.

    This doesn't mean you're stuck with only one directory structure in your development environment; for instance, since we still support both Word 97 and Word 2000, I've got two different development directory structures, and I swap the settings in Tools>Options>FileLocations to either the 97 or 2000 locations as needed (this switching can also be effected via a macro, but you'll need to store this in your Normal.dot so that you can run it from either environment).

    As far as being able to see the code in your global template if it's in the Startup directory, that's not really a problem - just open the global template while you are working on your workgroup template - if you are for instance stepping through code in the workgroup template and a call is made to a procedure in the global template, you should be able to see the code run in both open templates. To make it easier to open the global template in your startup directory (that is, to spare you having to browse to it all the time), just put a button on a toolbar, that runs a macro to open the global template. In fact you can create your own custom development toolbar with buttons for shortcuts to do all of the above - put it in your Startup directory, and you'll always have it available.

    Application.Run is a less desirable solution, because it is very difficult if not impossible to pass parameters.

    Just a few tips from having been there (recently <g>). If you have any specific issues that arise in setting up your template environment, I'm sure they'd be of interest if you post them here.

    Gary

  3. #3
    Silver Lounger Charles Kenyon's Avatar
    Join Date
    Jan 2001
    Location
    Sun Prairie, Wisconsin, Wisconsin, USA
    Posts
    2,049
    Thanks
    124
    Thanked 119 Times in 116 Posts

    Re: Template Design

    Hi Karen,

    My preference is to have shared code in the master global template and to have templates that have their own specific coding as needed. I use application run.

    If I have code that is common to one (large) class of documents (pleadings?) I may have a separate global template for that which is loaded as needed by the pleading templates. I generally don't have it unloaded by the template because I haven't worked out the code to be sure it isn't being used by another template.

    I open the globals when I need to reference their code when working with other templates. I'll be using Gary's suggestion to develop a separate template development add-in with toolbars & macros.
    Charles Kyle Kenyon
    Madison, Wisconsin

  4. #4
    3 Star Lounger
    Join Date
    Jan 2001
    Location
    Christchurch, New Zealand
    Posts
    250
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: Template Design

    Hi Gary, I see the logic in what you're saying. I'm still reluctant to commit to that design environment - I work on templates for many different legal firms and other organisations and don't want to use *my* Startup directory to store client files. I have in the past set up a client folder with subfolders for Startup and Templates, but I still have to change my File Locations and that means I can't then use my own templates when I need to create a document for our company. This can happen while I am in the middle of development of a set of client templates.

    Life was very simple when I didn't know I had options ....

  5. #5
    Super Moderator
    Join Date
    Jan 2001
    Location
    Melbourne, Victoria, Australia
    Posts
    3,852
    Thanks
    4
    Thanked 259 Times in 239 Posts

    Re: Template Design

    Karen

    I suggest you examine the reason you need so many templates?

    I avoid the creation of a huge number of templates by combining multiple autotext entries all in the same .dot file. This means that the same set of related macros, toolbars, styles etc are available when you open the template and the user just has to pick which boilerplate text they want added to start the new file. You can use a macro to pull the list of available autotexts into a userform that is called with AutoNew so that non-programmers can add boilerplate as they need to.

    With this method I only need
    * one template for various reports as they all use the same layout, styles, cover page etc
    * one template for forms
    * one for correspondence (letters, memos, faxes)
    * various other bit player templates.
    Andrew Lockton, Chrysalis Design, Melbourne Australia

  6. #6
    3 Star Lounger
    Join Date
    Jan 2001
    Location
    Christchurch, New Zealand
    Posts
    250
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: Template Design

    Oh dear, that opens up a whole new can of worms!! The templates are all highly automated, for instance a letter does different things than a settlement statement (this one has many calculations). My users fill in information into a dialog box for the specific template and the template and code creates, names and saves the document.

    Your idea has merit, although personally I hate autotext and would rather use insert file to put in boiler plate text as I find separate files easier to maintain, especially when it has to be maintained by the users. However, with a massive rethink I could restructure the template design.

    I think a need a *month* to think about the options, pros and cons, and then start from scratch!!

    Thanks for your input - it's certainly given me more to think about.

  7. #7
    Silver Lounger Charles Kenyon's Avatar
    Join Date
    Jan 2001
    Location
    Sun Prairie, Wisconsin, Wisconsin, USA
    Posts
    2,049
    Thanks
    124
    Thanked 119 Times in 116 Posts

    Re: Template Design

    Hi Karen,

    Instead of putting them in your startup folder, why not use macros to switch Add-Ins in and out. That way you can have the client's setup when working on their documents and switch back to your own environment at the click of a button. Simply add a folder and a button on your development toolbar for each new client.

    For simplicity's sake, I would suggest that one macro unload all Add-Ins and then load all Add-Ins in a particular folder. You would want to have a shortcut to your development add-in in each of the client folders or add that as a separate command at the end of your switch to the client environment.
    Charles Kyle Kenyon
    Madison, Wisconsin

  8. #8
    3 Star Lounger
    Join Date
    Jan 2001
    Location
    Christchurch, New Zealand
    Posts
    250
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Re: Template Design

    Hi Chas,
    I think that is probably the best way of doing it. Once I have some free time (whatever that is?) I am going to redesign my template systems and design environments

    Thanks.

  9. #9
    Platinum Lounger
    Join Date
    Dec 2000
    Location
    Queanbeyan, New South Wales, Australia
    Posts
    3,730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Template Design

    <hr>Application.Run is a less desirable solution, because it is very difficult if not impossible to pass parameters.<hr>

    A slight disagree. I can pass parameters; but (I think) it's equivalent to a "byvalue"- ie, I can pass them to a routine, but I can't get values back. (I haven't needed to get a value back, a function might be able to do it).

    I can do 'Application.Run "myRoutine", "parm1", "Parm2"' quite OK.
    Subway Belconnen- home of the Signboard to make you smile. Get (almost) daily updates- follow SubwayBelconnen on Twitter.

  10. #10
    Platinum Lounger
    Join Date
    Dec 2000
    Location
    Queanbeyan, New South Wales, Australia
    Posts
    3,730
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Template Design

    Karen,

    We've gone for an approach similar to Gary's- but with an approach which might suit your environment.

    We have templates in a directory structure completely outside the user/workgroup templates environment. But we have a custom button which calls up a user dialog allowing the choice of a new form.

    The button is made available via an add-in. It is easily changed for different customers (the file location could be via an ini file). Several hundred templates are made available, organised into major categories and sub categories. The user can add to a favourites list within the "mini-application", or can search through all folders for a template.

    Just another approach.
    Subway Belconnen- home of the Signboard to make you smile. Get (almost) daily updates- follow SubwayBelconnen on Twitter.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •