I think that I see your point and I have an idea how to handle my
scenario. I'll let you know what I did.
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
|
