About 3 years ago, I was looking for a way to allow a web app user to download table results to an Excel file. I knew that I didn't want to put Office on the web server and that I probably wanted to create the XLS file in XML format. The question was: what was the best way?
Now I am writing my resume and I am trying to recap the things that I did and I am concerned that I didn't take the best approach and I am wondering if somebody can tell me whether my suspicions are true.
Basically, I saved an Excel file as XML and then looked at the contents of the saved file and reverse engineered what I thought was a pretty cool SDK to create an Excel file in XML format. It was fairly robust with options , nice object model, etc.
But did such a library already exist? One that I could have used? I want to know if I will need to defend this "accomplishment"
Also, could anyone recommend me a good place where I can see actual resumes of people with .NET / SQL Server or general developer skills?
You can try SmartXLS (for Java or .Net), it supports most features of Excel (cell formatting, Charts, formulas, pivot tables etc), and can read/write both the Excel97-2003 xls format and the Excel2007 openxml format.
These people wrote a perfectly good one that you probably couldn't implement yourself for as cheaply.
Related
I have a tricky requirement to be able to merge PPT files on-the-fly in ASP.NET.
I'd like to avoid interop as I know it's not a good idea from ASP.NET.
I came across Aspose.Slides which looks like it would do the job - quite pricey though.
http://www.aspose.com/categories/.net-components/aspose.slides-for-.net/default.aspx
Cheaper / simpler suggestions much appreciated!
If you're certain that you'll only need to work with the newer XML format files (PPTX/PPSX/etc), you may be able to do what you need to by working with the file contents directly. They're actually zips that contain XML and other related resource files. Possibly relevant example:
http://msdn.microsoft.com/en-us/library/cc850834.aspx
#Robert Morgan,
I suggest you to please consider using cloud based version of Aspose.Slides for .NET SDK API in pay as you go mode. This will allow performing some number of operations completely free including merging presentations. I suggest you to please visit Aspose.Slides for Cloud pricing options for your convenience.
I shall try and keep my scenario as brief as possible and to the point.
The office I’m currently working for uses Lotus Smartsuite on Windows 98 / XP, using lots of Lotus Script to tie together Lotus 123 and Lotus Word Pro documents. They also make heavy use of the Lotus Object Linking functions. I shall describe its behaviour below:
You can fill rows and columns in a 123 Spreadsheet with data galore, style it and format it any way you like and define it as a range (nothing unique here). However, you can then copy that range and paste it as a link in a Lotus Word Pro document. This link is then categorised by its range name, so expanding the range back in the 123 file causes the table in the Word Pro Document to expand. This link also carries with it all the formatting and styling of the cells in the 123 Spreadsheet. As I imagine you are now aware, this link is completely live, you can double click anywhere in the object and it opens up the 123 file for editing, and all changes go backward and forward between the two documents. Most of the data retrieved from testing equipment is stored in these 123 spreadsheets and then parts of that are linked into a final Lotus Word Pro report document sent to the customer.
Note: Just to be clear, this is NOT the same as a DDE link in Open Office, which seems to allow for copying of a non-defined range of cells to be imported into a document where all formatting is lost and editing back and forth is not straight forward. It also behaves differently to an OLE object, which seems to only import the entire Spreadsheet rather than a small subsection of it.
However, in recent years, support this older software (Lotus) is becoming more difficult, especially with regards to sending customers documents (Lotus word Pro files are generally unsupported by more modern Office Tools) and technical support for Lotus Smartsuite seems to be practically non-existent these days. Also, with the fear of on going development in a scripting language no-longer being practised by mainstream IT technicians, on-going development and support seems futile. Once the guys who wrote it move on to other things, we will be left with spaghetti script in a language nobody can help us with.
So, we have this goal of "modernising" our IT system by the end of the year. Linux is becoming a very viable option too (No doubt Debian or a derivative), but Open Office doesn't seem to have the linking capability mentioned above. The reason this linking is so important is because the veterans of the office are so used to working this way - storing data in the spreadsheet, linking back to it later in their Word Pro documents, etc. I think they are more than keen to keep this practice going and we have found no equivalent of it in modern office tools (as was requested of me). I can see, as a software engineer (fluent in many languages), how this practice is not the safest or best way of using and storing data (databases spring to mind), but I was wondering if someone could give me a few other good reasons as to why this is bad practice in the work place (I was always in the belief that you should keep your data away from your reporting and formatting, the two should never be entwined - this looks like spreadsheet hell to me) ... or why this is a good thing to keep doing!?
So, for those of you still with me, I guess what I am asking is:
Is this practice of storing data, formatting it in spreadsheets and importing that directly back and forth between word documents good or bad, and what can be done about it? I guess I'll need to prove my point in case either way for this.
Are there ANY modern alternatives to this linking method (regardless of weather it is good or bad practice or not) out there for Linux or Windows? This link MUST carry formatting as well as dynamic range sizes (DDE links don't seem to be the answer).
What would your solution be if you had to start from scratch? Store everything in databases and use SQL to simply ask for the data you need in your word documents? How would you do this? What software would you use?
Any help with this scenario would be more than helpful, or if you know anywhere I should go to ask for advice, that would be appreciated too.
Thank-you for reading!
My suggestion is to first take a step back. What is the benefit to the way things are done now? Is it just a habit that is tough to break? Is there any reason the documents and spreadsheets need to be maintained and linked the way they are, or is it just a requirement because 'that's how it was done before'?
If you can remove that requirement, you have a lot more options and you're building a system that's easier to understand and maintain.
Regarding question 1, I believe there's nothing wrong with storing data in spreadsheets, especially if the end-users need to create and maintain them and development staff is limited. Some questions are whether that data needs to be secured, is related between spreadsheets, is duplicated across the company, or should be shared in a better way across the company. If any of those are true then a centralized database would make more sense. Personally I'd want any valuable data safely stored in a database where it can be managed, access to it can be controlled, it can be easily backed-up, etc.
Regarding question 2, you can do the same thing in Microsoft Office. You can either link the documents, so that the data stays in the source excel doc but appears in the word doc, or you can embed the excel spreadsheet within the word doc.
You might want to look at Microsoft Access for storing the data and generating reports. Or you could build an application using a relational database back-end and reporting front-end. The possibilities are wide-open. It really depends on where the expertise lies within the company.
If it were me I'd probably use a SQL Express back-end (it's free) and a custom ASP.NET MVC application for generating the reports, but that's just where my expertise lies.
The last time I produced a catalog I used a software called EasyCatalog that worked with Adobe InDesign to merge data from a spreadsheet with graphics. I wouldn’t say it was completely successful. I know of one other catalog building software called Catalog Builder by Computer Pundits. I'm just looking for any suggestions from someone who might have gone through this process on what software I should use.
InDesign can create a really beautiful output from XML. Depending on the catalog content's complexity, you can either have a straightforward mapping of the elements in your catalog to the paragraph and character styles of the IDD file, or you may need to preprocess the XML with XSLT.
For example, if your data source can output the content as XML, but it doesn't map easily to InDesign tables, XSLT can be used to make the XML more "IDD-friendly" before you import it.
IDML is another way to handle XML content; instead of importing the XML content manually or with a script into your catalog template, you generate the IDML directly from your XML. (IDML files are a package of XML files that describe the page/spreads, fonts, swatches, text, images, etc. of the InDesign file.) You're probably going to need XSLT consulting help if this is not a skill you already have.
Take a look at the InDesign documentation for XML for the version you use. IDML is for CS4 or CS5.
Have a look at xCS.press by a company in Belgium. XML markup that is parsed to InDesign. Great for product catalogs.
I wouldn't use Catalog Builder by Computer Pundits again. I've used it in the past (mostly their website builder) and it is completely outdated in my opinion. Their templates are not easily customized and it was pretty slow for me. As for their website builder,(in case you're wondering) it's all tables and very little css IDs or Classes throughout the html.
I haven't used InDesign, but it seems there are lot of scripting features.
Easiest thing that comes to mind is creating an XML Schema with IDML to
get data from Excel into an InDesign document.
XML schema basically is a template for XML documents, and they're called XML Maps in Microsoft Office.
Am not familiar with catalog tools, try superuser.com as well for 3rd party tools & tips.
John. have you come across additional solutions since posting this? I wonder if you have considered CatBase or EM Software solutions.
InDesign works wonderfully with XML and XSLT. You can export the data from Windows Excel only to XML, but only when you create an XML-compatible worksheet. Don't save the file as an XML spreadsheet, that file is useless in InDesign.
What I do is either create a schema file (xsd) for the data that you want to use and import that into Excel on Windows (Mac version doesn't support XML) Once the schema is imported you can create an XML worksheet based on this schema and then copy and paste the data from the non-XML worksheet into the XML sheet. Once the data is in the spreadsheet you can export to an XML file and import it into InDesign.
As mentioned above you can map XML tags to Paragraph and character styles and create dynamic layout directly in InDesign or by using an XSLT to structure the data before you import it.
MS Access allows you to export directly to XML. If you move your data to InDesign you can save the time needed to build the XML spreadsheet. Image references have to be built properly before you export to XML or build an XSLT that will do it on the fly as you import the data in to your layout.
The entire process is described in detail in the book A Designer's Guide to Adobe InDesign and XML.
If the data is in MS Access Woodwing has a product that allows you to interface and import data for a catalog. I have not used it personally but I know people who have. Also, another product called In-Data also interfaces with InDesign, but I have no experience with that either. I usually just use XML and XSLT myself.
I've used EasyCatalog very successfully for a number of years now, even for really large catalogs (35,000+ articles). In the meantime, I offer EC consulting and hands-on user training as well.
I'd need many more details of what went wrong with your specific catalog in order to be able to point your attention to a different solution that may better fit your needs.
I personally would not recommend Jim Maivalds solution because a) Excel and Unicode are not friends b) working with Excel and XML really is a pain c) the process is relatively complicated d) you need a lot of specialized skills regarding XML, XSLT programming and so on e) it's not bi-directional f) when updating you'll do the whole process again.
With EasyCatalog, you just import your data into a panel and place them from there into your document, from manually up to fully automatically. It's really easy, and it's bi-directional - so you can update your document from the database at any time and - if you need to - your database from your document. By the way, you can import your data directly from Excel into an EasyCatalog panel as well.
However, EasyCatalog might not be the best solution if graphics are included in you spreadsheet as well - but who would ever include the real graphics in a spreadsheet instead of the name (and maybe path) to the actual graphic files?
I need to manuplate an excel sheet workbook (add sheets/ add data/ hide columns / protect cells with password / change fields contents/ etc etc)
should I use the COM objects provided by microsoft (but then i think they have few problems being used in asp.NET)
or is there a good (commurcial or free) library / plug in to be used for doing this kind of activity.
please help
try spread Sheet Gear third party component
http://www.spreadsheetgear.com/
The easiest way I've found is to use the Excel XML format. That way you can edit an Excel sheet like any other XML file. To see how Excel hides columns or protects them with a password, do those things manually and see how Excel saves them as XML. This is a breeze to code up, it's rock stable, and it's fast.
Manipulating native Excel files is harder: you can use the COM objects with the primary interop assemblies. In my experience this is very hard to get right. In the best case, Excel leaves old copies of itself around, which you can mitigate with a scheduled nightly server reset. In the worst case, Excel will randomly hang, making your web site unresponsive.
Another way to work with native Excel files is Visual Studio Tools for Office. It's certainly easier to use than COM interop, and works best from Visual Basic:
Application.Workbooks.Open("Workbook.xls")
C# lacks optional parameters, and opening a workbook becomes something of a bad joke:
Application.Workbooks.Open(#"Workbook.xls",
missing, missing, missing, missing, missing, missing, missing,
missing, missing, missing, missing, missing,missing, missing);
I didn't dive very far into VSTO because XML manipulation worked so well for me. Maybe other people can comment on how it works out in an ASP.NET website.
With SpreadsheetGear you have complete access to the Excel doc and all of the macro capability including the ability to protect and un-protect cells, columns, etc. We have the same thing you are describing except in WinForms.
We have used the COM objects and I cannot recommend it. On big problem is that the objects never get released...
We now use the component from Gembox software. Have used it for two years and works OK, it's a little cheaper that the one metioned above, which I didn't know before seeing it here.
A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.