Hi Kore, Thanks for your feedback, i agree about error-handling.
Kore Nordmann wrote: > As said earlier I still got issues with two sections. My suggestions: > > View-management > --------------- > > The controller returns an abstract output object, which then should be > displayed by the view manager. The view manager receives the output > object and the abstract request object an can decide on the base of both > of them which view handler to use. > > Example > ^^^^^^^ > > 1. The user requests "/some/file.pdf" > > 2. The controller generated the data for this. > > 3. The view manager receives a OutputObject with the data, and knows > from the request structure, that a PDF file has been requested. The > view manager now select the PDF generator as the view handler and > calls the right template for the generated output object. Why shouldn't the view-handler be selected by the router ? Do we want to make input-object fixtures in addition to output-object fixtures to test a view-manager ? I think that the router should select the view-handler, allowing it to not use input-objects. This also seems more natural to me because the view-handler definitively needs the output-object, but could be totaly abstracted from input. Example : 1. The user requests "/some/file.pdf" 2.1 The router filters input and makes the input-object 2.2 The router selects the controller 2.3 The router selects the view-handler 3. The selected controller runs with the input-object 4. The selected view-handler runs with the resulting output-object In brief, can you elaborate the reasons why you think that input-to-view-handler-selection should not be done by another router please ? Regards, James -- James Pic -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
