[Boulder-Denver Ruby Group] re-inventing components

[David Clements]

On May 20, 2007, at 1:54 PM, ara.t.howard wrote:

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

The only thing I have heard is that the duping is expensive, that  
never made sense to me.  I don't have anything measurable and concur  
that I don't se anything in the code that dive me concern.  The only  
response I ever see is that you should be able to chuck your  
component and use helpers and partials.


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

Didn't talk to anyone about it.

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

Maybe I am off the deep end but I can see any trivial examples where  
the main content of a page does not have anything to do with sidebar  
content.   One example that i have is a logout header at the top of  
many my layouts.   There is information in the logout header that I  
don't want my main pages to care/know  about at all.  I guess I could  
code around this in someway right and have a  
LogoutHelper.init_instances and then render :partial =>  
'logout_header'.  That just seems ugly and heavy to me.  So I like  
the direction you are going and have other examples I can show you to  
help flesh out your use cases.





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

Yes,  but your approach might make more sense in these cases.  If you  
could grab ahold of a Bar instance and initialize it with the data  
for all the calls of render_component, then that would make my life  
easier and I think it would be much cleaner.   Which makes me  
think........   Why wouldn't you handle the main target controller in  
the same way?  Every thing is a widget!

Coffee and a whiteboard?

Dave

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