Rails core - Sep 2007 - Render, Redirect, or... allow plugins to add further options?

At present, every action must render or redirect exactly once.

I have an single-page application that displays many panes (currently 8) of
related data,
and when any action is performed in any pane, an arbitrary number of related
panes may
need to be refreshed. Each refresh requires that the data be fetched, and an RJS
replace_html or whatever is performed to update that pane.

My initial solution was to build one "refresh.rjs" with a conditional
to refresh each pane.
Then each action must, for each affected pane:
* fetch the required data
* set the conditional

What I really want is to be able to render multiple individual RJS actions, each
one adding
to the result.

What I currently have implemented is a before_filter that zeroes a @refreshes
array, and
a refresh() method that appends the passed block to @refreshes. At the end of
each action
that has called refresh(), you need to "render :action => refresh",
which iterates through
@refreshes passing "page" to each block.

That works fine, except that I''d like to avoid the call to render at
the end of an action
that''s called refresh. It''s not possible to do the render from
an after_filter, since that
happens after the default render that you get if you don''t call either
render or redirect.

It would be possible to do the render in an alternate "default render"
action, if such a
filter were provided.

So my suggestion is that there be a facility added to
ActionController::Base#performed?
that allows a plugin to replace the default render if neither render nor
redirect has
been called (for example, if refresh has been called).

It could be a very simple lightweight change in the core that would encompass
both render
and redirect and allow addition of further rendering models, such as this one...

  def default_render
    @default_render_chain.each{|renderer| return if renderer.call}\
    render
  end

Then in perform_action:
   default_render unless performed?

... and of course some way to initialize @default_render

Your thoughts, please?

Clifford Heath, Data Constellation.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> So my suggestion is that there be a facility added to
ActionController::Base#performed?
> that allows a plugin to replace the default render if neither render nor
redirect has
> been called (for example, if refresh has been called).
>
> It could be a very simple lightweight change in the core that would
encompass both render
> and redirect and allow addition of further rendering models, such as this
one...
>
>   def default_render
>     @default_render_chain.each{|renderer| return if renderer.call}\
>     render
>   end
>
> Then in perform_action:
>    default_render unless performed?
>
> ... and of course some way to initialize @default_render
>
> Your thoughts, please?

This seems like a reasonable request, if you whip up a patch and get
it looked at, we should be fine.  It would remain an internal
implementation thing, specifically intended to simplify changing
default rendering.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Michael Koziarski wrote:
>> So my suggestion is that there be a facility added to
ActionController::Base#performed?
>> that allows a plugin to replace the default render if neither render
nor redirect has
>> been called (for example, if refresh has been called).
> This seems like a reasonable request, if you whip up a patch and get
> it looked at, we should be fine.  It would remain an internal
> implementation thing, specifically intended to simplify changing
> default rendering.
Patch submitted, TRAC 9953

Clifford Heath, Data Constellation.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> This seems like a reasonable request, if you whip up a patch and get
> it looked at, we should be fine.  It would remain an internal
> implementation thing, specifically intended to simplify changing
> default rendering.
Eh, my initial thought is YAGNI.  I think providing a method to
override would be a cleaner implementation than passing a block too.

-- 
Rick Olson
http://lighthouseapp.com
http://weblog.techno-weenie.net
http://mephistoblog.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> Eh, my initial thought is YAGNI.  I think providing a method to
> override would be a cleaner implementation than passing a block too.
Yeah, I''d also prefer just a method which functions as it does at
present, but provides you with something to override in plugins.  The
chains etc. is just too much software for what''s really just a plugin
api.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Michael Koziarski wrote:
>> Eh, my initial thought is YAGNI.  I think providing a method to
>> override would be a cleaner implementation than passing a block too.
> 
> Yeah, I''d also prefer just a method which functions as it does at
> present, but provides you with something to override in plugins.  The
> chains etc. is just too much software for what''s really just a
plugin
> api.

Fair call. A fresh patch has been uploaded to TRAC that implements it
this way.

Clifford Heath.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Clifford Heath wrote:
> Michael Koziarski wrote:
>>> Eh, my initial thought is YAGNI.  I think providing a method to
>>> override would be a cleaner implementation than passing a block
too.
>> Yeah, I''d also prefer just a method which functions as it does
at
>> present, but provides you with something to override in plugins.  The
>> chains etc. is just too much software for what''s really just a
plugin
>> api.
> 
> 
> Fair call. A fresh patch has been uploaded to TRAC that implements it
> this way.
What''s the next step with this?

Clifford Heath.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

> What''s the next step with this?
Sorry for the delay, I had a bit of a patch backlog.  That''s been
applied now.

-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---