How do you minimize the pain in your development process when it comes to reporting?
For web frameworks, there is a pretty straightforward way to both produce content as well as graphically design it; content is represented semantically through HTML, and the design is separately specified through CSS. And browsers are fairly consistent with how they render the output (and the inconsistencies are well-known and can be planned for). There are even WYSIWYG editors to help out less-CSS-savvy graphical designers.
But what do we do about print content?
At one company, I created a process that worked like this: A script generated a semantic representation through XML. The XML was passed through XSLT to generate an XML-FO document. Then, this was passed to another tool (Apache FOP, I believe) to generate a PDF. This worked well for that company.
At this company, however, output appearance matters to management, and we have a graphical designer. Currently, we are using a reporting tool (XtraReports from Developer Express, version 8.1). It isn't bad; it outputs to a variety of formats, has a WYSIWYG designer, reports are implemented through C# classes, and it supports data binding to data sets (unfortunately, not POCO's). However, we have some major pain points with this setup:
The reporting framework has major limitations on how you can lay out and group your reporting bands
Presentable elements, especially charts, lack the capabilities we need to fine-tune and achieve the look of our mock-ups.
There is no good way to share styles and layout among reports akin to what we can get through CSS.
Good composability of reusable parts is very hard to implement. So we end up with a lot of copy & paste inheritance of functionality; this is bad news whenever we need to make sweeping changes across all reports.
Now, maybe there's some kick-ass framework out there that can eliminate the pains of reporting frameworks, but I assume that they all have their weaknesses. Do you have a framework or process that works well for you and reduces the pain points inherent in reporting?
Prince XML is a really cool tool which allows you to use HTML or XML styled with CSS (including CSS paged media for printing) and generate PDFs from it.
Option #1 : Adobe Acrobat is really nice. You can design form enabled PDFs and then use something like PDFSharp to manipulate the PDF document. You can create template PDF's that you dump your generated stuff into. I've done this before and it was pretty successful. I also used POCO objects nicely.
Option #2 : You could start creating XPS documents, which is XML based anyways. And they can be easily converted to PDF if necessary.
Option #3 : Run for your life.(might not be an option)
i-net Clear Reports is a nice product. It's based on Java but you can also work with ASP.NET. There is a bridge. The .NET version is in work if you want work with POCO. Because the Java version can work with POJO that the coming .NET version will also work with POCO.
Related
Well in general I am new to BizTalk and maintaining a very old setup, BT 2013 R2
Overall I am well versed in .XSLT and feel more comfortable managing xml directly than I do in the BT IDE ( well the vstudio IDE)
So here are a couple generic architecture questions:
What are the steps to manage the maps manually through notepad? I see a lot of code in the .BTM.CS file, but those don't seem to get picked up. I seem to have to change the .BTM file first, then it generates the .BTM.CS
My Map is Huge, I'm working with X12 and there are thousands of fields, what can I do to make this easier? I have to scroll through 10 layers deep just to make anything visible, then expand the map. BT IDE seems to have a big issue dealing with such big files
Also any books anyone can recommend on the subject would be appreciated
I will say this first, I totally understand where you're coming from, but...
You don't, sorry. The BizTalk Visual Studio Project System is an integral part of BizTalk development and you really, really, really should not even try using a text editor. .odx, .btm, .btp are all meta files managed by their respective designers. The .cs files are generated at Build-time so there is not opportunity to modify them at all.
One way to improve Mapper performance is to areas of function into separate Tabs. The rendering of the design surface is the problem so the less to render at once, the better. Even separating direct links and Functoids helps.
Sandro's book is the current standard: BizTalk Mapping Patterns & Best Practices
Johns-305's answer is good - I'd just add that with XSLT in maps you do have the option of setting "Custom XSLT" for the map in the properties window. That can then be pointed to an external (source controlled) XSLT file which you could then edit using any XML/XSLT editor (Visual Studio or not). Just be aware that this option means you won't be able to us any of the visual mapper functionality, and the .btm file will basically just be a pointer to the compiler to use your custom XSLT rather than the XSLT that would be generated by BizTalk. You should not try to manage BizTalk's generated XSLT in this manner - only for cases where you're certain you want to use custom XSLT rather than the visual designer. To do that, open the map in Visual Studio (1), click the grid area (2), and then set the Custom XSLT Path (3):
(It's possible to do that by directly editing the .btm file, but not recommended - I did write a blog a little while back documenting the .btm format for what it's worth though: https://blog.tallan.com/2015/03/26/biztalk-mapper-file-format-btm-documented/.)
For orchestrations, you're out of luck.
I am using ASP.NET MVC. Sometimes I work with ASP.NET Web Forms too. I can pretty much create my queries using stored procs or LINQ and render my report just using a plain HTML table. With proper styling it should come out decent.
I don't know SSRS but I have some experience working with crystal from before. The only advantage I see from using crystal for my reports against just a simple HTML table is that it can export to PDF. But I could probably get some third-party library that can do that too. Regarding charts like pie and bar graphs there are a lot of javascript tools available out there that does that and they're free.
I guess I'm posting this to see what I'm missing with reporting tools like Crystal and SSRS.
EDIT: With ASP.NET MVC it is not particularly difficult to create the report. Just formulate the correct model, create the controller action and view with scaffolding (Detail) and you will have the code generated for you right away. With ASP.NET Web Forms it is probably easier, just use a GridView and you're done. For both cases all that is left is the CSS. With Crystal you also need to edit the layout you have generated the report, which is work still as well.
The reason we use SSRS for our internal reports is that our database guy can create reports without having any knowledge of how to format output using code.
your points are valid and I have been thinking about such things multiple times.
Personally I used CR in the past and SSRS more recently, but my absolutely best experience was with DevXpress XtraReports, super cool design and royalty free end user designer with or without Ribboned interface.
the difference between using a report engine or plain raw HTML is in the way you design the reports and the overall features.
in XtraReports for example, the lovely thing is that a report is simply a .cs file (C# class) and whatever you design with the UI designer is stored in that file exactly like the windows forms designer does ( or ASP.NET aspx and aspx.cs designer does ). So you see the report you are designing and you Drag & Drop controls and place them where needed. Then you have out of the box formulas, running totals, page breaks, as you mentioned export to pdf, excel, jpg, html, word and so much more.
if I was free to choice again I would go again for XtraReport and forget about plain and raw html table coding, let's focus on the real business of the application we write and not get nuts with page breaks, exporting things and in house implemented formulas or group/running totals... this is my idea and approach at least.
The biggest reason for me to use a reporting engine is for printing and page breaks. You can't always guarantee the way the HTML will format for all the various browsers and it's not great for setting hard page breaks. With a reporting solution, you can group things together to force page breaks to be more predictable.
This is especially important if you're looking for a more professional looking report.
as already stated above using another report generator can have much benefits. I've used very often List & Label. There is a completely different concept behind and depending on your needs it will be easier but still powerfull, especially for .NET reporting. It is worth to do a trial (there is even a free edition available).
I have large documents (HTML or Text) (think legal documents/regulatory documents etc.) that need to made readable i.e. paged, with some rich-text markup, allowing user highlighting and annotation etc.
I was thinking of using a Scribd style rendering or as on Secwatch.com (see here). Any thoughts how I can go about it? We are on ASP.NET.
Found one article that does something similar:
http://www.c-sharpcorner.com/UploadFile/ckrause/Ajax-browser-based06162006015526AM/Ajax-browser-based.aspx?ArticleID=548dfae2-4251-4c9a-b659-bfe88fd55c62
Needs some plugin, am not sure if you are OK to go for a third party control.
EDIT(s):
1) Just realized that Scribd runs of Ruby on the Rails. I guess that could be a starting point if you want to look at developing something on your own. (What does RoR have that ASP.NET doesn't for this particluar case?)
2) Scribd provides an API, but mostly for interfacing your app to sribd.com. However, it might give you ideas.
I've been having a heckuva time with this problem, and there seems to be a lot of noise out there in search engines in getting to the bottom of it, so forgive me if I've missed a silver bullet out there.
The base need is that I have to generate a PDF document that has both static and dynamic elements. I started to do this by having a PDF template with all the static content, and then I wanted to inject various dynamic elements into it. The problem is that PDFs are not meant to be manipulated that way, and depending on the size of the dynamic text I put in there, might overflow text on other pages. I was using iTextSharp but can't get past this problem.
A possible fallback is to generate a DOCX, which I've done before, and then convert it into a PDF on the backend. The only libraries I've found to do this are paid apps (like Aspose). There are examples out there that convert to PDF without these libraries, but they seem to require a client-side application. I'm doing this via IIS.
To make a long story longer...are there free libraries that will convert a DOCX file to a PDF server-side without launching client applications to do so?
There are a few choices here:
build a COM interop class that will perform read and 'Save As' functions on your .docx. The MSDN link you gave doesn't require to be run client-side, but rather have the Office assemblies in the GAC or in your ASP.NET's bin directory.
buy a third party component to do the work for you. Here's just one example with no guarantees.
I'm not familiar with any good free ones, but we used Aspose.Words to achieve something similar to what you describe. We keep Word templates with static text and mail-merge fields. The templates can be regular Word documents, they don't have to be .dot templates. Mail-merge fields can be either single fields or repeatable data in tables so you can easily generate pretty complex documents without doing dynamic document editing. (Which is always an option)
Using Aspose for this was so friction free that I would suggest using Aspose unless the cost (which is significant) is a show-stopper. The support is also good which is always an added bonus.
There are always some caveats...
I would have liked more control over the PDF compatability of the generated PDFs. We had some issues with older clients reading the generated PDFs.
Mail-merge is not fun. Complex mail-merge expressions was time consuming to get right.
I just found very simple solution to convert any files from command-line using LibreOffice:
soffice.exe --headless --convert-to pdf file.xls
(google for the rest)
Recently our newest web designer asked me why we use ASP.NET for our website. Reading through his question to the real one, I started thinking about it myself. Why are we using ASP.NET for web development?
The problem we find so far is colaboration between the design team and developers. Typically our designers create some snazzy cool look crayon laced web pages, then show them off for approval in all their glory. Once approved, the developers rip the HTML out and shove it in to ASP master and detail pages, and huzzah! out comes pretty website.
Since Dreamweaver doesn't play nice with Visual Studio, this is the same process for even small tweaks and changes. I would prefer to just write the backend and let the designers draw the pretty pictures and fancy CSS. Our current websites have plenty of reason to use ASP on nearly every page, so I can't do half in HTML, the other half in ASP.
I have no aversion to doing something else, another language, CMS platform, some other random buzzword, etc...
What are your experiences with this design situation? Are we doing it the hard way? Should we consider alternate platforms and languages? Are there any good, proven ways to allow designers to work on ASP (while still using Dreamweaver)?
Start learning Asp.net MVC as soon as possible. Designers will love you for that. :) And you'll be up to date with new development technologies that will also make your solutions much more robust and less complicated.
But otherwise. Designers should be able to read XHTML fluently. Learning asp.net semantics shouldn't be too hard. Then give then Visual Studio where they can manipulate content. As long as they know how asp.net web forms work things should be fine. They'll probably be able to do majority of things using just CSS. I know I can. Sometimes I do have to check resulting HTML, but it works.
Aside from Wicket (a java web framework), I don't know of any framework or language that would allow designers to continue to work on the design once developers have started to add logic to it.
I would suggest two things though:
Use a MVC framework - ASP.NET MVC, Ruby on Rails, Django, etc since this allows for far more separation of presentation and logic
Keep your presentation layer as stupid as possible and use helpers as much as possible or even better, put the logic in the domain objects. The view should only show or get data with absolutely no logic for processing data, this will keep the pages much more designer friendly.
I find your question very interesting because no matter what kind of technology the project uses the interfaces between the different roles will always cause some friction. I am not sure if there is a technological solution to this communication issue because the designer and developer speak literally different languages.
Depending on the skillset of your designers and developers an additional layer might help you out. I do not know how ASPX works but i am sure there will equivalents to the concepts of other technologies.
In case you have mainly static content which can be expressed in XML than you could provide the backend which delivers the content in XML with a defined Schema and your designers could describe the transformation in XHTML and CSS via XSLT. Given that your designer are capable using XHTML and CSS the addtional effort to learn XML and XSLT is not that huge. I find this solution much powerful than template languages which try to emulate the richness of the serverside scripting language in their own limited constructs. In case you have dynamic elements on the clientside like DHTML, AJAX or you name it you could define your own xml tags which are transformed to richer client side objects after the designer did their work. I guess the designer will understand the usage of these special tags and you provide the proper translation into client side objects.
I used this approach with some coworkes based on PHP. PHP was only the driver for the transformation. The content was assembled into xml with special tags which were transformed into XHTML and CSS via XSLT. Once the objects and the transformation for the different objects is defined you build up a library which can help to shorten the developement cycle of new pages of you webapplication. The benefit of the extra work is, that you designer can change the layout of the page without ever touching you server side code.
Maybe this helps.
Consider using either Expression Web or SharePoint Designer. The latter is now free.
I know you specify dreamweaver, but have you looked at Blend? It plays very nice with Visual Studio and is quite a nice app. to work with.