re-inventing components

i'd love feedback from the community

	http://drawo
hara.tumblr.com/post/2070878

cheers

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



_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

ara.t.howard wrote the following on Fri, May 18, 2007 at
02:16:54PM -0600:
> i'd love feedback from the community


Ara, this stuff looks pretty good.  Like you, I tend to
gravitate towards OOP,
and it's disappointing that with Rails, MVC is only 1/3 OO. 
I'm wondering if
it's time to rethink ActionController and ActionView a bit.


-- 
Peter Jones - 303-669-2637
pmade inc.  - http://pmade.com
_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

Not sure if I am totally following the issue here. I totally
agree  
with the premise that the support for widgetizing our apps
is really  
ugly. And I use components regularly to widgetize various
portions of  
our apps.

Are we talking about syntax or functionality?

We could re-write your example today using
render_component_as_string:

class FooController < ApplicationController
   def bar
     # get a handle on, and parameterize, a bar controller
     bar_controller = component_for(:controller => 'bar')
do
       foo = 42
       bar = 'forty-two'
     end

     # call two actions on the bar controller, potentially
reusing  
the entire model+view+controller stack
     foo = bar_controller.content_for :action => 'foo'
     bar = bar_controller.content_for :action => 'bar'

     render :text => [foo, bar].inspect #=> [42,
"forty-two"]
   end
end


With this:

class FooController < ApplicationController
   def bar
     params_hash = {:foo => 42, :bar => 'forty_two'}

     # call two actions on the bar controller, potentially
reusing  
the entire model+view+controller stack
     foo = render_component_as_string(
params_hash.merge(:controller  
=> "bar", :action => "foo" )

     bar = render_component_as_string(
params_hash.merge(:controller  
=> "bar", :action => "bar" )

     render :text => [foo, bar].inspect #=> [42,
"forty-two"]
   end
end


Not sure if I am missing something,  as I didn't here
Bruce's talk  
last week,

Dave




On May 18, 2007, at 4:41 PM, Peter Jones wrote:

ara.t.howard wrote the following on Fri, May 18, 2007 at
02:16:54PM  
-0600:
> i'd love feedback from the community


Ara, this stuff looks pretty good.  Like you, I tend to
gravitate  
towards OOP,
and it's disappointing that with Rails, MVC is only 1/3 OO. 
I'm  
wondering if
it's time to rethink ActionController and ActionView a bit.






-- 
Peter Jones - 303-669-2637
pmade inc.  - http://pmade.com
_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

On May 18, 2007, at 7:24 PM, David Clements wrote:

> Not sure if I am totally following the issue here. I
totally agree
> with the premise that the support for widgetizing our
apps is really
> ugly. And I use components regularly to widgetize
various portions of
> our apps.
>
> Are we talking about syntax or functionality?

both.

>
> We could re-write your example today using
render_component_as_string:
>
> class FooController < ApplicationController
>    def bar
>      # get a handle on, and parameterize, a bar
controller
>      bar_controller = component_for(:controller =>
'bar') do
>        foo = 42
>        bar = 'forty-two'
>      end
>
>      # call two actions on the bar controller,
potentially reusing
> the entire model+view+controller stack
>      foo = bar_controller.content_for :action =>
'foo'
>      bar = bar_controller.content_for :action =>
'bar'
>
>      render :text => [foo, bar].inspect #=> [42,
"forty-two"]
>    end
> end
>
>
> With this:
>
> class FooController < ApplicationController
>    def bar
>      params_hash = {:foo => 42, :bar =>
'forty_two'}
>
>      # call two actions on the bar controller,
potentially reusing
> the entire model+view+controller stack
>      foo = render_component_as_string(
params_hash.merge(:controller
> => "bar", :action => "foo" )
>
>      bar = render_component_as_string(
params_hash.merge(:controller
> => "bar", :action => "bar" )
>
>      render :text => [foo, bar].inspect #=> [42,
"forty-two"]
>    end
> end
>


the main difference in the above is that, using
'component_for' is  
constructing an object *once*.  using
'render_component_as_string' is  
making two objects.  in the case of components these can be
very  
expensive objects to create

class SpreadSheetController < ApplicationController
   def initialize
     rows = select_100_100_rows
   end

   def foo
     something_with_100_000_rows
   end

   def bar
     something_with_100_000_rows
   end
end

of course there's nothing on 'component_for' which adds some
measure  
of turning completeness to ruby/rails - nothing truely new
is gained  
- it's simply the difference between creating objects which
can be  
manipulated and combined vs. setting up a bunch of
parameters and  
calling a bunch of methods.  i personally just happen to map
most  
problems to objects in my mind and find it a useful
abstraction to be  
able to do this with rails' views - it's certainly not a
panacea  
though! 

anyhow, i'm happy to hear you are using components - people
claim  
that they are much slower, but my tests haven't managed to
show  
this.  can you comment on that?

hope you are having fun at the jupiter!

cheers.


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



_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

On May 20, 2007, at 7:19 AM, ara.t.howard wrote:

>
> On May 18, 2007, at 7:24 PM, David Clements wrote:
>
>> Not sure if I am totally following the issue here.
I totally agree
>> with the premise that the support for widgetizing
our apps is really
>> ugly. And I use components regularly to widgetize
various portions of
>> our apps.
>>
>> Are we talking about syntax or functionality?
>
> both.
>
>>
>> We could re-write your example today using  
>> render_component_as_string:
>>
>> class FooController < ApplicationController
>>    def bar
>>      # get a handle on, and parameterize, a bar
controller
>>      bar_controller = component_for(:controller
=> 'bar') do
>>        foo = 42
>>        bar = 'forty-two'
>>      end
>>
>>      # call two actions on the bar controller,
potentially reusing
>> the entire model+view+controller stack
>>      foo = bar_controller.content_for :action =>
'foo'
>>      bar = bar_controller.content_for :action =>
'bar'
>>
>>      render :text => [foo, bar].inspect #=>
[42, "forty-two"]
>>    end
>> end
>>
>>
>> With this:
>>
>> class FooController < ApplicationController
>>    def bar
>>      params_hash = {:foo => 42, :bar =>
'forty_two'}
>>
>>      # call two actions on the bar controller,
potentially reusing
>> the entire model+view+controller stack
>>      foo = render_component_as_string(
params_hash.merge(:controller
>> => "bar", :action =>
"foo" )
>>
>>      bar = render_component_as_string(
params_hash.merge(:controller
>> => "bar", :action =>
"bar" )
>>
>>      render :text => [foo, bar].inspect #=>
[42, "forty-two"]
>>    end
>> end
>>
>
>
> the main difference in the above is that, using
'component_for' is  
> constructing an object *once*.  using
'render_component_as_string'  
> is making two objects.  in the case of components these
can be very  
> expensive objects to create
>
> class SpreadSheetController < ApplicationController
>   def initialize
>     rows = select_100_100_rows
>   end
>
>   def foo
>     something_with_100_000_rows
>   end
>
>   def bar
>     something_with_100_000_rows
>   end
> end
>
> of course there's nothing on 'component_for' which adds
some  
> measure of turning completeness to ruby/rails - nothing
truely new  
> is gained - it's simply the difference between creating
objects  
> which can be manipulated and combined vs. setting up a
bunch of  
> parameters and calling a bunch of methods.  i
personally just  
> happen to map most problems to objects in my mind and
find it a  
> useful abstraction to be able to do this with rails'
views - it's  
> certainly not a panacea though! 
>
> anyhow, i'm happy to hear you are using components -
people claim  
> that they are much slower, but my tests haven't managed
to show  
> this.  can you comment on that?

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.

So I guess my question here is that if components are going
to be  
deprecated then how do you separate the concerns of the Foo
and Bar  
controllers?  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 , 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.


Dave


>
> hope you are having fun at the jupiter!
>
> cheers.
>
>
> -a
> --
> we can deny everything, except that we have the
possibility of  
> being better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>

_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

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/br
owse_thread/ 
thread/6f923c6483914c27/3ff503c1f4b0dcc0?lnk=gst&q=compo
nents 
+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



_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

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/br
owse_thread/ 
>
thread/6f923c6483914c27/3ff503c1f4b0dcc0?lnk=gst&q=compo
nents 
> +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
>
>
>

_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

On May 21, 2007, at 10:51 AM, David Clements wrote:

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

ok good.  that really supports this

	http://drawo
hara.tumblr.com/post/2184032

>
> Didn't talk to anyone about it.
>

ok.  did any other ideas about where view patterns where
heading emerge?

actually - those of us who didn't go would really appreciate
a run  
down of the proceedings from you and others who went - maybe
next  
ruby group?  marty?


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

ok - i understand that.  it makes sense.  i'd love to see
more examples.

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

yes!  wednesday  the cup - 8 am?  anyone else care to
join?

>



> -a

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



_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

> actually - those of us who didn't go would really
appreciate a run
> down of the proceedings from you and others who went -
maybe next
> ruby group?  marty?

Sounds like a good idea.  I'd be happy to do a review of
RailsConf
along with the others that went.  Let's see how many of
those on the
list that did attend can make the June meeting (June 20th).

Cheers,
Marty
_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members

On Mon, May 21, 2007 at 11:25:17AM -0600, ara.t.howard
wrote:
> >
> > 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?
> >
> 
> yes!  wednesday  the cup - 8 am?  anyone else care to
join?

Ping... I'm in.

Hmm... I have this large chunk of whiteboard at my house...


enjoy,

-jeremy

-- 
============================================================
============
 Jeremy Hinegardner                              jeremyhinegardner.org 

_______________________________________________
Bdrg-members mailing list
Bdrg-membersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/bdrg-members