Hi Jan,
I'm going to take this in the order of "shortest reply"...
What I've found and discovered today is, that I could use my http handler to
get and save the documents, if it would be Distributed Authoring and
Versioning compatible... what do you think about this idea? Where can I find
some help if I'd like to implement it? (eg. what should I response to
OPTIONS http method at least in order to get this working)
I'm afraid you're WAY outside may knowledge area on this one
An IIS
group, perhaps?
The client is downloading the file at the moment because I didn't find any
easier way how to send it to it, moreover when I need to save the template
to the disk anyway to make it accessible to the Word in order to fill it. I
wish I could call Word with System.IO.Stream for open...and save
I don't need to add any UI elements to the document, since I can handle it
all in the document close event, however what to do in this time? How to
store it to the server?
My inclination would be to store the documents in Word's XML format. This
way you can stream them when building, versioning, etc. Just use automation
to open the result and save back to doc/xml Format for the last step. Yes,
this will mean saving the stream result to disk, but this way it can be
"temp". And this way, you'll have some elements in-place for an eventual
migration when Word 2007 roles out and the converter becomes available.
Okay, so I'll try to point out my case. The "target audience" is government
offices. So I have one big requirement - do not install anything on the
clients.
That makes it extremely tough, in all respects.
Be sure I'd love to have VSTO solution, but I am not allowed to
install the framework
Odd, that the framework wouldn't already be there. Given the security
requirements, I'd think that would be the "first thing..."
(I don't know what is needed to deploy add-ins)
Depends on what kind we're discussing
A template Addin would "merely"
need to be copied into the user's Word Startup folder. A COM-Addin would
need to be registered on the machine, but it would be a single file. A
managed COM Add-in is more than one file, but still needs to be registered
on the machine.
Personal question - what is SmartDocument?
Word 2003 only. Implements the SmartDocument interface of the SmartTags
"thingy". It lets you present the user with a customized task pane for
performing actions (such as data entry, providing lists from
databanks/webservices, sending the document back). The taskpane is based on
XML tags inserted in the document (but generally not visible to the user);
requires a schema that defines the XML tags. Setup/installation/update is
controlled by a manifest. Can be COM or managed code.
To summarize:
The whole lifecycle is:
1) The ASP.net application generates data.
2) The document template is taken from database blob and filled with that
data on the server
3) Client can modify this and complete the document
4) These changes are saved to the database with versioning.
As mentioned above, I'd go with XML for 1 & 2, just opening it in Word 2003
and saving as a "regular" *.doc file as a last step, before providing the
user with the document.
Given that you can't install anything on the user's machines: Sending back
just isn't going to be something you can build into this, short of a
"mailto" hyperlink, unless macro code (in conjunction with a toolbar saved
in the document or an ActiveX control, such as a button) can be included in
the document.
If you go the XML route, you can include any macro code and toolbars in a
transform, so that processing client-generated templates shouldn't be a big
problem. Save them in Word 2003 as XML, then run the transform before
popping them into the database.
Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister
http://www.word.mvps.org
This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail
