Well, its been a long time since I blogged something and it was just that I thought I had a legitimate reason for not to blog. I am attending this training at my work which is kick-ass (when it comes to learning) and wierd when it comes to knowledge being graded with quiz and exams. Anyway, I love the learning part and the exams – not much. But it is my full time job and I got to learn what they throw at me, which is fun though. Anyway, that training itself keeps me busy most of the day and most of the week. The time that I am left with, I spend it watching tv (did i mention I am actually following 7 different TV series and I am a huge fan of HOUSE). Anyway, I have once again began thinking about developing a reporting engine using Silverlight and WCF. We use LogiXML internally and it does a pretty good job with its flexible approach when it comes to integrating reports with existing software systems, but personally (this does not represent the opinion of my employer in any way) I feel it is too complex and we use only 10% of what the engine provides. Moreover it is darn-slow since it uses a lot of Datasets and writes whole bunch of XML files. I wish to revamp this, as a challenge to come up with a great Silverlight-based report front-end driven by WCF on the server. Apart from this pet project, I am working with a friend on a super cool application which is still in its infancy but hopefully things would be improved as I graduate from the training camp.
Lets talk about the reporting suite
1. Reports can be created simply by adding a query or a method from a .NET plugin.
2. Drill-Down reports can be developed by simply mapping the reports using a column pulled from the parent report.
3. Reports can be styled using standard silverlight styles.
4. Overall look would initially be fixed and as the application evolves, a designer can be used to restructure the components. Fine-grain design might not be supported yet, since it is complex to implement.
5. Reports can have input-data which should be easy to set up.
6. The reporting engine would support scheduling reports off the shelf.
7. Events would be raised on the server and plugins would be invoked for those events passing appropriate data. For example, BeforeReportLoads event would be fired as the report is being loaded and this would invoke IAsReportLoaded.ReportLoading(ReportInputData) would be called. So we can create a plugin which would be injected into the server and which provides implementation for the interface and in the implemented method, we could save the ReportInputData to a database. This is what we call “saving the user favorites”.
8. The report viewer would support generating graphs/charts on-the-fly and in the future, one would be able to save the chart parameters as a favorite and apply when required.
9. The report grid would be fancy one with support for grouping, sorting, filters and should be one like the Intersft Webgrid.
Cut the crap and talk about technical details
I may be wrong but I think the application should be using PRISM since it supports dynamic loading of XAP files (modules) which makes the application faster to load and better to use. Remember, not all users would use the entire application at once which makes dynamic injection of modules a great catch. PRISM also automatically makes my application to have a great design (I know it is not true but at least it makes me know what is the right way to do some things, if not all).
What else?
I am using FeedDaemon and let me tell you this – it is a great tool for avid blog reader like me and you. http://www.newsgator.com is the place that you should visit and download FeedDaemon and use it, you would not repent. By the way, I figured out how to make datagrid (in WPF) display drill-down data. (drill-down reports using WPF datagrid, I would post more on this later).