IFilter on relevant actions.

imo ViewComponents must not do any out-of-process calls.

On Thu, Mar 12, 2009 at 2:12 AM, Andre Loker <[email protected]> wrote:

>  Hi Ken,
>
> Thanks for your response. What if you have a column on the web page that
> for example shows the headlines of the lastest X news items or a random
> collection of photos. This logic has nothing to do with the actual action
> that is being invoked, so loading this view data from each and every action
> where it might be needed seems pretty awkward and breaks separation of
> concerns.
>
> Wrapping this in a view component that loads the data autonomously seems to
> be a way to encapsulate this feature and make it easily reusable. But this
> requires DB access during view rendering. Those items are more or less pure
> view related features, that's why I found this solution reasonable.
>
> But of course I'm willing to learn - how can I better handle this
> situation?
>
> Regards,
> Andre
>
> 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
>
>
>
>
> >
>


-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to