In answer to question 2, a quick and easy way to transmit the data as a CSV file (comma seperated database format). This can be transmitted as text and Excel sets up CSV as one of it's own file types.

Thinking about it, this will probably preclude the need for using CGI... you can generate the data from your asp page.

Of course, not knowing what type of information you wish to send, this is only a guess ;)

$japh->{'Caillte'} = $me;

Of course, not knowing what type of information you wish to send, this is only a guess ;)

That would preclude any formatting to the data, fonts, bold, etc

Anyway, what "Content-Type" and "Content-Disposition" would your solution entail ?

Yes, it would preclude fonts etc for it is a data only format. The content-type: text/plain

$japh->{'Caillte'} = $me;

I've done this in the past using Apache::ASP.

Choice 1 is highly non-portable, due to the vairous ways of storing session data.

I would recommend choice 2, there's no need to use $Response->BinaryWrite, but you must set the correct Content-type. Thus you could say:

$Response->{ContentType} = 'application/vnd.ms-excel';
# Generate your sheet and store it in $sheet
print $sheet; # Or $Response->Write($sheet);
[download]

-- TMTOWTDI

I can't vouch for how portable this solution is, since I believe that it requires certain versions of IE and Excel (and Windows, of course) However, if you want to stay entirely within ASP in order to meet your authorization requirements, try this out. If you know that your users will be using at least IE 5.01 and that they have at least Excel 2000 on their machines, then you can change $Response->{Content-Type} to 'application/vnd.ms-excel' as suggested above and simply $Response->Write the content as normal HTML tables.

IE and Excel should cooperate via OLE/ActiveX and display the content as an Excel spreadsheet within IE itself, and if the users want to save the file out, they can just select File->Save As from the IE menu, and it will default to saving as an Excel .xls file. As I mentioned, I believe that this requires minimum versions of IE and Excel, although I haven't personally tested it on other versions.

Also, for formatting purposes, you can use CSS within the various table tags via the "style" attribute. Unfortunately, using a separate CSS stylesheet (whether linked or elsewhere in the HTML) and "class" attributes doesn't seem to be reliable.

Granted, this is a narrow subset of user requirements, and you're essentially limited to non-dynamic Excel content, i.e. pure data, no formulas or other such things. However, we use a solution like this at my company to provide web-based reports to our marketing department. This allows us to use the same basic presentation code for both the HTML and Excel versions of the reports. The only modifications required to make the reports Excel-friendly are to strip out any sort of UI widgets or other unnecessary sections and then change the Content-Type.

Now, if we could just wean the marketing department off of Excel, that would be a MUCH better solution. But, alas ...

-jehuni

The Session object I'm talking about is the $Server-object, that has already been modified by the PerlScripts(ASP) which handles the login/auth stuff.

As PerlScript(TM) itself is able to interface with this IIS stuff it shouldn't be impossible to read the wanted properties but then on the other hand, right, PerlScript is not pure perl.

Having two different Sessionhandlers for the site would be a bad thing, perhaps I will have to resort to passing encrypted parameters in the form?.

This being my first writeup, I didn't notice that my original title "$Session from cgi || BinaryWrite from PerlScript" was changed to something less than intelligeble, however TIMTOWTDI in perl.

CGI::State doesn't do sessions. It's a way of grouping CGI params I think. On the other hand, CGI::Persistent and CGI::SecureState do handle sessions.

Simon Flack ($code or die)
$,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
=~y'_"' ';eval"die";print $_,lc substr$@,0,3;