> Hi Matthias, > > IMO it is not useful, because this needs a lot of memory. > If you are streaming data from a database, a file system or something > else and get an error from the storage, then you also can not send > status 500 because the transmission is already startet. > > best regards > Stephan
Thanks Stephan for your comment. Okay, that makes sense for streaming large representations. However, for my use case correct HTTP status codes are a necessity, so i had to reimplement that. At least the loading of the template file can be done earlier. But I guess it would clutter up the API if a preprocess option would be incorporated, so i suppose it's better to leave it untouched - extending it to match my needs wasn't a big deal. regards, Matthias > > Matthias Wauer schrieb: >> Hi, >> >> my first post here, so first of all, thanks guys for working on & >> releasing Restlet, fine thing. >> >> Until now i was able to solve my issues on my own, but i think this one >> might need to be discussed. >> >> Issue: >> I use the FreeMarker extension to generate representations. >> Unfortunately, >> the processing of the template (with the supplied model) is done in >> TemplateRepresentation.write(), which is called after >> Resource.getRepresentation(), and even after the response header is >> written in HttpServerCall.sendResponse. >> >> Specific problem: >> So, after creating a subclass of TemplateRepresentation and moving my >> error handling from Resource.getRepresentation to >> MyTemplateRepresentation.write(), i was faced with the issue that >> obviously i cannot send a Status.SERVER_ERROR_INTERNAL if the processing >> fails completely - i can only alter the reponse body (= the entity). >> >> Possible solution: >> A solution _might_ be to process the template in the constructor of >> MyTemplateRepresentation or in a separate method, storing the result in >> a >> StringBuffer or ByteArray, which is then copied to OutputStream in the >> write() method. I suspect performance would suffer, but at least we had >> all options for exception handling. >> >> What do you think? Did i miss some point? Is there some better way? >> >> Regards, >> Matthias >> >
