The whole idea behind the MR/Rails MVC flavour, is that once the controller has finished it's thing, the request handling is regarded as *done*. so your scenario is not valid anyway. opening a transaction in AfterAction should be avoided, and closing one AfterRendering even more.
I personally think that AfterRendering won't make sense if no rendering has actually taken place. If anything, stuff that happen after the controller has finished and processing moved to the ViewEngine, should ne be the concern of an IFilter at all, and I considered removing this ExecuteWhen altogether. *maybe* it could make sense to add at the IViewEngine level. On Wed, Mar 11, 2009 at 11:11 PM, Andre Loker <[email protected]> wrote: > Hello group, > > I just realized that the ExecuteWhen.AfterRendering phase of a filter is > not executed if no view is rendered using a view engine. That is, if > - CancelView is called -or- > - RenderText is used > no filters that listen to ExecuteWhen.AfterRendering are executed. > > If this is intentional behaviour I think it should be documented. One might > be tempted to e.g. open a transaction in AfterAction and close it in > AfterRendering, which can cause strange effects if no view is rendered. > > Maybe we could add an extra ExecuteWhen phase that is invoked at the end of > the request, regardless of a view being rendered or not. What do you think? > > Kind regards , > Andre > > > > > -- Ken Egozi. http://www.kenegozi.com/blog http://www.delver.com http://www.musicglue.com http://www.castleproject.org http://www.gotfriends.co.il --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
