Sorry bitches, you've been very lackadaisical about supporting Microsoft SQL Reports in your framework, and that is going to get you fired from my project.
Users of your technology have pointed me at 3rd party solutions. I wasted most of the day fiddle-faddling with their online demos and mocking one up for myself. It is my considered opinion that these solutions, as presented in the demos, suck on stinky cat-shit.
Why, you ask? How about the fact that control must re-render for a simple drill-down into hierarchical data. This gives a nasty progress bar whilst the Silverlight applications waits for results. It's not an instant progress bar either. It takes 5 to 10 seconds each time. There is no way I can present that to the end user and say "Here is your new system." They want interactive drill-down. That performance-level is far less than interactive.
The take-home message is pretty simple: If you would like us corporate programmer types to do CRUD apps with your technology, give us full access to SQL Reports. So take a deep breath, and realize that this is me, tell you, that you have been fired from my project.
Although my soul is full of dread at the thought of it, I may need to pursue this application in plain-vanilla WinForms. I shouldn't call WinForms vanilla. That would be an insult to both Mexican and Madagascar vanilla beans, which are delicious. WinForms ain't delicious.
Why not WPF? There is no direct SQL Reports support for WPF either. There is a way to host a winform inside of a WPF form, but this is a very ugly cudgel. I am not willing to go down that route.
I have no idea what is going on at Redmond but somebody seriously dropped the football here. Corporate types like me cannot be bothered with a serious challenge regarding something as fundamental as report integration. This issue is not a question of technical proficiency, it is a question of your failure to provide tooling and a toolkit for your frameworks.
If I wanted too, I could get down and dirty and design a full document model all by myself. It wouldn't be as sophisticated as the SQL Reports RDL, but I could deliver about 75% of that sophistication in about a year. I can roll up an interpretor that will read that RDL and crank out a high-res bitmap that would be printable.
But the question is: Why should I bother? Why make my company wait? Why make them pay for such a project? Frankly, it would be an immoral rip-off if I did that too them. Just do the WinForm thing and get it done in a month or two.
The guys in Redmond are sitting around, scratching their heads and asking questions like "Ghee whiz... why haven't the corporate types moved over to WPF for all their data apps?"
Have you considered the need for fully integrated reports?
Ah! But you should do a report website.
But what if my official directive is a single all-inclusive application?
Well... talk them into a website for reports.
Why should I do that?
Because you want to use WPF and Silverlight.
Not necessarily. If it is going to make the firm wait, change goals, or create problems, I don't want to use WPF or Silverlight.
Well... then you will be left out of the future.
Is that so? I thought we began this conversation with you lamenting the fact that we aren't adopting your XAML technologies?
That is true.
So in what sense are you the future if we don't adopt your technology?
[Silence speaks volumes.]
So now you have your mission directive: Go back to the drawing board and deliver a full WPF solution for SQL Reports. Reports are the absolute value of these database applications. We all know that the value of these databases is almost never realized by the firm until they draw up a automatic reports, and see how things are going. That is the money shot that makes it all worthwhile.
This is too fundamental a piece for you to have left it out of the framework. I don't have any idea why you think Silverlight, WPF or XAML are corporate technologies sans a reporting solution.
