[Boulder-Denver Ruby Group] re-inventing components

[ara.t.howard]

On May 20, 2007, at 11:50 AM, David Clements wrote:

>
> I think that the perf issue people speak about comes from assumption
> that the Bar controller could more efficiently setup the data needed
> for the Foo controller rather that running through the whole stack
> again.  I have setup up my component partials in a way that I can use
> them without calling into the component when I need to make separate
> calls.
>

ok.  that makes sense - but reading the component code it doesn't  
actually look like much work - mostly dups....  my real concern is if  
anyone has ever seen *measurable* differences.  have you had any  
issues with speed?  iff so, can you quantify to give me an idea of  
what i'm up against?


> So I guess my question here is that if components are going to be
> deprecated

are they?  i've heard that, but then

   http://groups.google.com/group/rubyonrails-core/browse_thread/ 
thread/6f923c6483914c27/3ff503c1f4b0dcc0?lnk=gst&q=components 
+deprecated&rnum=1#3ff503c1f4b0dcc0

so, since you are there - what's the current thinking?  are they or  
are aren't they?


> then how do you separate the concerns of the Foo and Bar
> controllers?

i'm not following you - they are completely different objects - any  
other controller could construct and parameterize a bar object too -  
it seems like the separation is the same as this code

	a = []
	h = { :key => a }


>   Even in your example, Ara,  I don't like the fact that
> Foo controller has to know anything at all about Bar.  I want the
> view to make the decision that ,

hmmm.  don't you normally consider the controller as responsible for  
contructing all data for the view?  in any case you certainly could  
construct that bar widget in the view or a helper method....

> in this context ,we are going to
> draw the Bar widget somewhere on the page.  I have situations where I
> don't want Foo to know anything about Bar.   And currently , in
> rails,  I do need to do this for performance reasons when I can't
> afford to render the same component more than once.

just to clarify - are you saying that you do not want to go through  
the whole 'render' stack (request, response...) and that you are not  
using render_component_to_string in that context because of  
performance reasons?  if so that certainly makes sense.

it's obvious that some imagined widget would not always need to go  
through the whole rendering stack but, be things how the are, the  
tight coupling of the request, controller, and the virtual mating of  
the view and controller in rails make this hard to accomplish any  
other way...

did anyone have novel ideas on this at the conf?

kind regards.

-a
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama