but the controller is the one that is in-charge on the decision making - whether to show that view component or not. so putiing that DB read there actually makes more encapsulated sense.
it aslo helps with batching etc. and imagine someone will use your component in a #for# loop, then you might end up with multiple calls. your solution would be to make the Viewcomponent smart enough as to know how it's going to be called. on the other hand, a controller doing a smart db read action, passing all needed data to the controller, then the view-component is left with changing raw data to markup. I see it as a much better approach On Thu, Mar 12, 2009 at 10:46 AM, Andre Loker <[email protected]> wrote: > > IFilter on relevant actions. > > Wouldn't that be a nightmare to maintain? Anytime I add or remove such a > view component on any view I would have to modify a bunch of actions and > need to recompile the application. > > > imo ViewComponents must not do any out-of-process calls. > > I agree that it does not really feel right, but frankly at the moment I > don't know of any better way to handle this. Maybe I can think of a solution > using interceptors but still I need to somehow determine when which data is > required in the view. > > > 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 > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
