Activex compliant.

[vishravars]

HI All,

I am trying write a .csv file in a web application. I use javascript and Internet explorer for the above.
I would like to know if i can perform the following.

1. Create an Actiex object (considering there is no m$ spreadsheet appln installed) and openoffice 2.0 is installed and working.
2. if above is possible, is it possible to create workbooks and write data into it (through api's) and launch the oo-calc (so that i can save the file later)

In short i am trying something like this,

var theSpreadsheet = new ActiveXObject(\"Excel.Application\")");
var theBook = theSpreadsheet.Workbooks.Open(tempstr)");
theSpreadsheet.visible=true;");

But i guess the above code works only in case of m$ Excel installed in the client m/c. i gave me the error .. Automation server cannot create object (given that i have enabled all activex security levels)

Regards,
Vish

[TerryE]

Read section 3.4.3.5 "Automation Bridge" of the SDK Developers Guide. If you google "automation Bridge" site:openoffice.org then this will take to you to the online version. However, if you are going into such depths then you will really need to download and read (the relevant bits of) the SDK.

But lets just talk about what you are really trying to do here. Where are you trying to have your smarts? Is this web app one for enabling a defined business community or a wider end-user community? The reason that I ask is because of issues to do with at which end of the client server relationship do you want to pace your smarts: fat client functionality or thin?

You need to think about the precursors and requirements for your end user? What packages must be installed on the users PC? What security must be enabled? This is particularly relevant if you are dealing with a general user population. In general if you want to minimise these requirements then you need to stick to javascript only, possibly using Web 2.0 call-back functionality. This means that you need to move things like CSV generation back server side.

[vishravars]

Thank you for the reply. I shall look in to the google "key to search" you gave. Within 2 days, the idea has changed. I am just going to keep the processing at the server side. I wish to write it as a csv first and then if there is a demand, i shall go for ODT with relavent libs (SDK) or mono .net with m$ stack of the same.

As you rightly pointed out i must consider the client setup issues too. I dont wish to make the user enable activex scripts. And regarding the s/w at client side, it's just a webbrowser and M$ IE as the case now. And jboss server on the other side.

Thank you for the help.

[vishravars]

I decided to render the data in a seperate window through a jsp program. When i tried to do

response.setContentType("application/vnd.oasis.opendocument.spreadsheet");
out.write("column1","column2"); // render. I assume that calc will take it as a csv type. But i am sure it sounds less logical though.

i had the data rendered in OpenOffice.writer application instead of calc. I have also associated the filetype to the calc application in client. What am i missing here. I am not sure Any help is highly welcome.

I use m$ windows as client OS and IE 6.x.

[TerryE]

With most Qers, I would have had a play myself before answering, but I feel that your Expertise level is rather higher than the norm, so if you don't mind I'll leave you to do the play yourself.

The first thing to note is that in fact Calc, Writer, etc. are all the same executable (Calc is synonymous with Soffice. bin -calc). The selector switch is advisory, and Soffice in fact checks the file type and opens the appropriate UI. So calc test.odt will still start writer. I suspect that invoking a "application/vnd.oasis.opendocument.spreadsheet" with a CSV has the same effect. However one of the nice things about the OASIS ODF is that it is open and it is easy to create spreadsheets on the server side as long as you have a ZIP library. Import your CSV, format the headings etc and have a look. Its just a zip file and the content is in content.xml. For fixed layout this is also pretty fixed but each cell would be something like

<table:table-cell office:value-type="float" office:value="123"><text:p>123</text:p></table:table-cell>

So it would be easy to write a program to create a content.xml by copying a std prologue, writing a of load lines, then the epilogue and adding it to a zip file which you can then fire up as your "application/vnd.oasis.opendocument.spreadsheet"

[vishravars]

Oh. Ya absolutely right. I think i need the zip utility(content.xml and meta\ ) for .sxc, .odt etc. csv looks like a text mime. I am stuck in that sense, I have also set the filetype association etc.. in m$ windows settings. Still it's not able to when i open through internet explorer (i mean when it is rendered)... I shall try content.xml zipped as you said.

I am feeling odd to select .sxc/.odt for the fact that .sxc does not work with m$ win env and .odt is still not sure to be fully trustable on m$ windows office suite(since openxml is on the way). So just thought of going for .csv and then going for ODT at a later stage.

[TerryE]

.odt is still not sure to be fully trustable on m$ windows office suite(since openxml is on the way)

I don't think that this line of reasoning is sound. The EU and 3rd world is a sufficiently large market sector to stop MS acting in totally unacceptable anti-competition modes. The world is separating into MS and 'the rest', the rest being the Linux and OSS camps. But to play MS must continue to offer a level of compatibility to the open world, an even then it occasionally bows to the inevitable (how many out there remember that 15 years ago NetBEUI was the MS stack and they didn't offer an MS TCP/IP stack?).

OpenXML is not a true Open stack. What MS has done here is to XML encode its proprietary formats and Zip them. Yes, it has published these, but they are not complete (e.g. you have a tag which says implement an end-paragraph using Word6 rules, but these are not defined anywhere in the public domain). ODF is fundamentally different. First, it is being taken up by many if not most of the non-MS Office product suppliers as the encoding system of choice, so not only does OOo use it, but also now the IBM Lotus suite. Second, to do what you want you can go to OASIS, download and read it (as 600 odd pages, it is less than a 10th of the size of the OOXML spec); it is complete so you can use it alone to work out how to code your spreadsheet, knowing that OOo, Lotus, AbiSuite can all open it natively. Its only going the be a matter of time before MS themselves reluctantly support ODF as a secondary format.

[vishravars]

Ya ya. Very much. All that said is very true. I am very much aware of the file format war. I support ODT and definatly not openxml. Even filed the petition. If business demands certain stuffs, we are forced to take certain stands . Any way, my problem is still not solved.

[TerryE]

You still haven't explained what your underlying requirement is:

• If the end-user is Joe Public then I'd stay with CSV format, though as I said you can generate ODS files directly on the server in something like php or one of the Java environments. You can also run soffice.bin headless server-side to act as a PDF / XLS / ODT generation engine, but I've seen mixed reports on this, as you need to keep bouncing the process because of resource leaks.
• If your end-user is a business user where you have more control over the configuration and software configuration of the PC, then you might also look at client side scripting through a COM interface. You can add some macros to your default client template to do things like Import from a URL, and then trigger this activation + import from a button on web page. But again you need to set up the security also.

If you do manage to come up with a satisfactory approach, I would be interested if you posted a synopsis, when you've got it working.

[vishravars]

Ya sure.

I managed to make openoffice.org open my rendered text/csv(jsp server) with some native m$ windows registry settings in MIME/Database/contenttype/ ..
The requirement was to export grid data as a document (what i have done now) and then import it back(later) to the grid after the changes are over. Both are .csv's

What kills me is if there is a m$ office suite also installed with the openoffice.org, even with openoffice calc associated with text/csv, still it gets open in m$ office excel. This is quite irritating, But settled with it and continuing with other important parts of the work.

I am happy to try ODT very soon with jsp/java oo libs and i am really thankful for your great support. Will be back when i get issues at the ODT part.

Thanks for your patience TerryE