Or at least describe about.aspx
For .aspx I assumed it stands for:
Active Server Page eXtended format
Though another opinion is that:
these files typically contain static (X)HTML markup, as well as markup defining server-side Web Controls and User Controls
Apparently it was the cool thing to do at time (the quote actually talks about the original name XSP, but doesn't rule it out as an option):
The initial prototype was called "XSP"; Guthrie explained in a 2007 interview that, "People would always ask what the X stood for. At the time it really didn't stand for anything. XML started with that; XSLT started with that. Everything cool seemed to start with an X, so that's what we originally named it."
For the office documents, since they are in XML format, it stands for XML.
I guess it stands for XML.
Since XML was used heavily in .NET Framework and later on in Open XML formats for Excel, Word.
If I was correctly informed, it stands for 'XML' - these files are renamed, zipped XML documents. That goes for .docx, .xlsx etc.; don't know about .aspx since that's web stuff.
They usually contain static XHTML
This is to indicate that it is a page contains (X)HTML and the rest of the code is in the code behind (e.g. about.aspx.cs or about.aspx.vb)
Related
I need to create a service to convert a series of QuickReport _(.QRP)_ files into something more parsable such as Text or HTML.
What is the best way of doing that?
qrp files are definition files for the Delphi/Quick Reports engine.
It is not immediately clear from the question whether you want to completely do away with the delphi/quickreports engine or just get the results in a browser.
If it is the former, then you may have a complete rewrite on your hands. But if it is the latter then you probably need to adapt a delphi app to export pdf files, say.
The Delphi app approach is likely only viable if you have full control of the security of your web-server.
Re-reading the question, you specifically want to parse the reports (presumably for data extraction).
As quick reports uses a relational db as a source, the only reason I can think of doing this is because you don't have access to the Delphi source or the database.
This may imply a one-off data migration away from an ex-supplier. So maybe just print to a pdf-print driver, then convert the pdfs to text and parse away.
I hope this helps.
I would recommend you to check Gnostice eDocEngine which will allow you to export .QPR to many formats including Excel.
https://www.gnostice.com/nl_article.asp?id=248&t=Export_From_Quickreport_To_PDF_And_Other_Formats
eDocEngine VCL has several interesting components:
TQRPQuickrep, TgtQRExportInterface and for export to Excel TgtExcelEngine. QPR-to-Excel rendering is performed with 4 lines of code (assuming the components are initialized) :
gtPDFEngine1.FileName := 'eDoc_QuickReport_Demo.pdf';
gtPDFEngine1.Preferences.ShowSetupDialog := false;
gtQRExportInterface1.Engine := gtPDFEngine1;
gtQRExportInterface1.RenderDocument('eDoc_QuickReport.QRP');
It is fairly priced and is provided with the source code. The only limitation is that it is Delphi and C++ Builder complaint, but if you feel comfortable with any of these languages you can easily create CLI utility or service and call it from your code.
Short background - I'm exporting an Excel file using Classic ASP, in which I generate a table which is originated at an MS SQL database.
One of the columns I retrieve holds paths to images I have on my server. I use the following code to define an "Excel-targeted" response:
Response.ContentType="Application/vnd.ms-excel"
Response.AddHeader "content-disposition", "attachment; filename=""Sales_Report-"& Month(Date())&"-"& Day(Date())&"-"& Year(Date()) &"-"& ".xls"""
The problem - I've been googling for a solution and came to realize (correct me if I'm wrong here) that embedding it as "contents" of a single page is impossible.
However, it is possible to either placing the image in one cell's remark (I'd like to avoid that), or alternatively just set the image as a cell's background.
Important note - my goal is to have the images sort and filter with the rest of the row they're located in. I did manage to place the images exactly where they should be to begin with, but they just float as regular images in the spreadsheet.
I'm using plain HTML elements and not XML - but an XML solution (if exists) would also be awesome.
Thanks.
OK, so after some research I've come to discover the research I was lacking to begin with. It obviously depends on the MS Excel version which eventually opens the generated file.
Generating XLS files with advanced cell settings is quite doable and intuitive when one acquires better understanding of the XML structures which help generating files through the code, with either Classic ASP & ASP.NET code behind.
At the moment, we use MS WORD and MS EXCEL to mail merge documents that needs to be sent to multiple recepients.
For example, say there is a complaint form where the complainant needs to fill in his/her name, address, etc. So we have a .doc file set up with the content and the dynamic entities set up for mail merging, with the name and address details put in an excel file, from where we can happily mail merge to generate all or just the necessary forms/documents.
However, I would like to automate this process, like a form in a website where the complainant can fill in his/her name, address and other details, and we could use that to generate the complaint form automatically and offer it to be downloaded (preferrably as a pdf).
Now, the only solution that comes to mind, is Latex, so that I can just replace the needed entities and just compile to PDF. However, that bit has to be negotiated with the webhost, if they are offering Latex or not.
Is there any other solution? Any other way we could get this done, with something that shouldn't be a problem for most webhosting solutions to offer?
EDIT: I would prefer a non .NET or rather non microsoft solution since, the servers are running linux and while mono might be capable of getting the job done, none of our devs know any .NET languages. However, if required we might have to dwelve into it.
Generating PDF using an XSL. Check the following: Apoc XSL-FO
You will need to create an XML file with the required fields and transform that with this tool.
If you wish to avoid .NET then XSL-FO is worth a look. Try the FOray project.
XSLT can be a steep learn if you do not have experience already. Also users will not be able to change the templates without asking the XSLT guru to do it.
If your templates are already in MS Word and MS Excel then I would stick with generating MS docs on the server. These are now easy to work with from code since OpenXML - check out OfficeOpenXML and OpenXMLDeveloper
Apache FOP : http://xmlgraphics.apache.org/fop/
I suggest generating rtf on the server: it's easy enough to automatically generate using cpan's RTF::Writer, has converters generating good pdf, can be edited by hand in word, oo-writer & TextEdit, doesn't have any really bad compatibility issues between the main editing applications, and has decent text & resource extraction tools, with text extraction being rather better than pdf.
There's some support for moving between rtf & latex, although the best rtf -> latex converter, docx2tex, depends on the System.IO.Packaging .net module, whose mono implementation isn't yet rock solid.
Postscript — Not a recommendation: it's too much of an unwieldy sledgehammer for this job, but iText will generate the pdf directly from the form data. If you wanted to do fancy things like signed pdf, that would be the way to go.
Postscript #2 — If you break up the Word document into individual files using word's master document representation, then you can clobber one of the parts with hand-generated content. This makes it easy to do something approximating form-filling on word .doc files using just standard file-utils and some trivial rtf->doc tweaking.
I have a method which downloads sharepoint documents to the local disk. I use SPFile.OpenBinary() method to get physical file, but it contains all fields of a parent DocumentLibrary. Does anybody know how to clear file (doc file) from these fields? I found only way to do it using Word interop library (method described here http://maxim-dikhtyaruk.blogspot.com/2009/05/trim-sharepoints-documents.html), but it doesn't fit my requirements cause it works only when Microsoft Office is installed on the machine...
You may want to read this to understand whats going on.
I do not know if this can be turned off or not, but it happens only with Word 2007 documents (docx).
You could do any of the following to turn this off:
Create a new content type and associate it with a document library. Use this document library from now on.
Look into some Open XML library or the Open XML SDK published by Microsoft.
This isn't a bug, it's supposed to be a feature! :-) Seriously though, you need to edit the Word document programmatically to remove these additional fields completely (I think even a content type will leave some behind).
For documents prior to Word 2007, you could use a toolkit like Aspose. I almost needed to do a similar thing once and would have used this product to do it. I'm sure there are other options out there.
For Word 2007 and higher, as SharePoint Newbie says, you should be able to use the Office Open XML formats to edit the document. Here's an MSDN intro article.
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?