The project depends on the usage of PdfResult. This is nice and simple but forces you to make the decision on the type of output when writing the controller. This is opposed to the idea of being able to swap view engines without touching controller code and makes RazorPDF particularly problematic to use in environments where presentation is bound to the view model in a late manner.
I'm specifically talking about Orchard: http://orchardproject.net/. Orchard builds up dynamic view models but the templates are bound to the view models as a later step; this makes it possible to e.g. use separate view engine side by side, where one engine builds the markup for part of the layout and another for the other part.
The output type can be much loosely coupled to the controller if it depends on the views: you could just return a View("MyView") from your controller. Now if there's a MyView.cshtml, the result will be HTML. If it is (making up the extension) MyView.cspdf the result will be a PDF file.
What do you think?
The project depends on the usage of PdfResult. This is nice and simple but forces you to make the decision on the type of output when writing the controller. This is opposed to the idea of being able to swap view engines without touching controller code and makes RazorPDF particularly problematic to use in environments where presentation is bound to the view model in a late manner.
I'm specifically talking about Orchard: http://orchardproject.net/. Orchard builds up dynamic view models but the templates are bound to the view models as a later step; this makes it possible to e.g. use separate view engine side by side, where one engine builds the markup for part of the layout and another for the other part.
The output type can be much loosely coupled to the controller if it depends on the views: you could just return a View("MyView") from your controller. Now if there's a MyView.cshtml, the result will be HTML. If it is (making up the extension) MyView.cspdf the result will be a PDF file.
What do you think?