On Tue, 18 May 1999, Carlos Amengual wrote:
.......
> I have one interface that is implemented by classes providing PDF and
> HTML. Of course the functionality is minimal. Four years ago I wrote a
> medium-sized system that used ole to manipulate content of Word
> documents (this wasn't Java).
....
If I'll need sometime to generate Word docs (.rtf not accepted by
customers even with Word being able to save it as .doc)
then
I will gladly use your or other similar tool (based on OLE and perhaps
with some scripting like VBasic) but rather on the client side:
- Let servlet generate only pure XML (wich is better to describe a
a document's content/structure)
- and send it back with a ContentType that fires your OLE tool on client
side
- wich will fill Word templates (or docs) that reside on some central
http server, with the content parsed from the XML.
- and present resulting .doc to the user.
This way I'll be able to handle such oddities as Word documents in a
manner that:
1- Protects servlet application from being changed at each Word's new
version.
2- Avoid performance penalties on servlet engine, by using it
to generate only simple textual structure. Only when
I'm thinking how much CPU and RAM takes for Word by itself for one
singel user, I fear that I'll be in much trouble when trying
to generate .doc-s for lots of concurent users.
3- Let users (deployers more exactly, those who maintain the application)
maintain/change the look and formatting of resulting .doc files,
without forcing them to learn Java and document generator API, but using
the tool they like instead (Word in this case).
4. Offers you the chance to use the same, untouched servlet/app when a
similar OLE or other client-side-binary will be able to fill up
.PDF docs with servlet-generated XML.
If you want to make such a tool that programatically creates
.PDF, how difficult will be to add to it XML+XSL parsing resulting in
PDF generating capability?
And how such a new tool (XML->PDF converter, based on XSL info) can
be better qualified than just another template engine?
--------------------------
I believe document formatting/conversion is more a client-side job.
That from previous technical considerations, rather than religious.
(XSL for instance was meant to be interpreted by browsers)
> Often, documents live longer than small
> non-standard template scripts, and that's another reason against
> templates.
?? Cant follow... eventually documents will live longer than big
non-standard APIs too, who will care in the next millenium HOW a
document was generated?
What's wrong with template-files being non-standard, you mean an API is
standard by just being an API?
Then what about a standard template-engine-interaction-API that states not
how a template is represented externally, but how java programs can
generate data using any template engine, this way allowing developers
to switch from one template-engine-and-its-syntax to another..?
Then someone will make the .pdf-generating template-engine too, another
.word-generating engine, and all being inter-changeable
(apologize if this sounds a little religious...)
Such an API will be much smaller (easier to adopt and spread)
than one generic document-generator API because it won't make
assumptions on what formatting capabilities (headers/footers for example)
will have the resulting format.
That's why I've asked a while ago on this list if there is a
will from template-engine designers to open a specific java-template
generating list.
I agree this thread is already annoying for a servlet-interest mailing
list and apologize again for that..
Cezar
> ....
> You can programmatically manipulate a document from more than one
> application.
I can. My customers can't. I'd try stop them changing/adding .class
files to a delivered app, just because they will not be able to blame me
when things go wrong or slow.
> ....
> > don't forget that now most web designers handle well
> > at least one of interpreted languages like
> > javascript, perl, php or other - tag-oriented style.
>
> You may want to share these designers with me ;)
Sure, look for <META AUTHOR=... > tag on any web page containing
javascript, or its URL ends with .php, .pl, .asp, .jsp and who knows
what other extentions
>.....
> Hi, Cezar, I think you're confused with your Outlook taskbar ;-)
Can't follow again, what an "Outlook" is?
Look at full message headers before acusing someone of that. ;-)
Regards,
Cezar
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
