Re^2: export to excel in CGI

Why use open source to export to proprietary closed format?

Because the client demands it?

MS clearly dominates the office suite market since at least Win95, and millons of people are trained to use MS Office. They don't say or think spreadsheet, they say and think Excel. They don't say or think presentation software, they say and think Powerpoint. Not database, Access (or sometimes Excel). Not text processor, Word. Not mail user agent or groupware, Outlook.

I don't like this situation either, but there is a difference between consulting and preaching. Good consulting ensures the next job at the client, preaching can cost you the current and all following jobs.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re^2: export to excel in CGI

Replies are listed 'Best First'.
Re^3: export to excel in CGI by leocharre (Priest) on Sep 04, 2009 at 14:54 UTC
I can understand from my post that it would appear that I preach and it stops there. I also deal with clients. Mostly groups of people, not individuals. In this specific case, the truth is, it can't be done. Sure, it looks like it's being done- but there's no way to truly guarantee it. The only people that could really guarantee that the output is correct are the people with access to 100% of whatever a excel file is supposed to be. And unless you're working for M$, you cannot honestly assure the client that not only does it look like it works, but it works. Dealing with weird transformations of proprietary format and junk like this- opens your company/institution to possible danger. There is are a couple of ways to do this properly. Either manually via the gui that M$ provides- or via some M$ development java or c++ dev lib they provide (they must have something). Anything else, and you can't guarantee your client that you are outputting true xxx files. Now, I work with proprietary format junk from time to time. But I do not output proprietary format. I can guarantee the client that the output is what it is. It doesn't just look like it works, it works. When faced with situations like these, I've found ways around it- to still solve the problem. It's been good so far. If users assimilate 'Word' with a text file, it's the fault of people like you and me that just want to take a paycheck and not educate users. put an end to word attachments	[reply]

Replies are listed 'Best First'.

Re^3: export to excel in CGI
by leocharre (Priest) on Sep 04, 2009 at 14:54 UTC

I can understand from my post that it would appear that I preach and it stops there.

I also deal with clients. Mostly groups of people, not individuals.

In this specific case, the truth is, it can't be done. Sure, it *looks* like it's being done- but there's no way to truly guarantee it. The only people that could really guarantee that the output is correct are the people with access to 100% of whatever a excel file is *supposed* to be.
And unless you're working for M$, you cannot honestly assure the client that not only does it *look* like it works, but it *works*.

Dealing with weird transformations of proprietary format and junk like this- opens your company/institution to possible danger.

There is are a couple of ways to do this properly. Either manually via the gui that M$ provides- or via some M$ development java or c++ dev lib they provide (they must have something).

Anything else, and you can't guarantee your client that you are outputting true xxx files.

Now, I work with proprietary format junk from time to time. But I do not output proprietary format. I can guarantee the client that the output is what it is.
It doesn't just look like it works, it works.

When faced with situations like these, I've found ways around it- to still solve the problem. It's been good so far.

If users assimilate 'Word' with a text file, it's the fault of people like you and me that just want to take a paycheck and not educate users.

put an end to word attachments

[reply]