At 04:32 PM 3/8/01 -0500, Dom Lachowicz wrote:
>Well, considering that we can't save to .doc yet, I'm viewing this as a
>non-issue for the time being. We can re-evaluate it when the time comes.
Sure, but it implicitly becomes an issue right away because when you open a
.dot via file/open, you have to decide what that *means* to the user.
Specifically, are you in category #1 or #3 below? It makes a difference.
In any event, it certainly becomes an issue as soon as we *do* start adding
template support, which is what? Saturday? ;-)
As mentioned in the earlier message, once you have templates at all, you
need to distinguish in your UI between:
1. using a template,
2. using the default template,
3. changing a template, and
4. creating a template.
To use the vocabulary from your post, my assertion is that the design we
probably want is as follows.
#1 gets triggered by a brand new dialog, which lets the user choose from
templates preloaded in a directory off the lib dir as you describe. Once
that template is chosen, you open it via loadFileAsTemplate() or whatever,
which sets a tricky flag in the same place as the dirty bit which undo
modifies. This is pretty easy.
#2 gets triggered by file new. Instead of getting all of our default
document properties and style definitions from the hardwired defaults, we
copy them out of a specific existing template. (Good old Normal.awt,
right?) This isn't likely to be much code, but getting the beahviors to
Just Work is probably the hardest part of any template design.
related issue
-------------
Currently, all style definitions cascade back to the hardwired defaults,
so we only persist style definitions which were modified by the user.
By introducing templates into the cascading chain, we probably need to
change this to also export styles explicitly defined in the template.
If so, we'll probably want to flag which styles were user-modified, so
that we can (a) filter the styles dialog display appropriately and
(b) *update* the underlying styles when the associated template
definitions change.
Note that I'm not sure what the UI trigger for (b) should be. Also,
to implement this properly, we'll need a soft link back to that template
by name. URL-style syntax for relative links would probably be
appropriate here.
#3 gets triggered by opening that template file (in whatever format -- .awt
or .dot or whatever) directly via the usual file open dialog. From there
you can change the template by just editing and saving it.
#4 gets triggered by saving any file *as* a template. At minimum, this
means subclassing the .abw exporter to also save things with .awt suffixes.
related issue
-------------
There are folks who insist that AbiWord should *not* rely on suffixes.
Does this mean that we should internally set a property in the file format
to indicate that a particular document is a template? If so, which wins
when there's a conflict? (I suspect that something similar
Am I missing any issues here?
Paul
