From kjvarga at gmail.com  Thu Dec  3 05:36:45 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Thu, 3 Dec 2009 18:36:45 +0800
Subject: [Cells-talk] view/partial rendering
Message-ID: <9042dfb30912030236s40a850acm5d7e59066881aa9@mail.gmail.com>

Hi guys,

I've tried to wade through the ActionView code to figure this out with
no luck.  I'm wondering how many times a view file is read?  If I
render a view 100 times is that expensive?  I think it would cache the
contents of the view file...but I don't know for sure.  The views are
quite small so I'm considering inlining them if it's expensive.

THanks,
Karl

-- 
Karl Varga
kjvarga at gmail.com
Cell: +61 (0)4 2075 1356
Skype: kjvarga

From apotonick at gmail.com  Thu Dec  3 08:42:05 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Thu, 3 Dec 2009 14:42:05 +0100
Subject: [Cells-talk] view/partial rendering
In-Reply-To: <9042dfb30912030236s40a850acm5d7e59066881aa9@mail.gmail.com>
References: <9042dfb30912030236s40a850acm5d7e59066881aa9@mail.gmail.com>
Message-ID: <e2cf7aef0912030542j7c8e120bsfd35fc9bda742964@mail.gmail.com>

hey karl-
are you sure the view file is physically opened 100 times? i thought
ActionView does cache the files as soon as they were discovered. There
is something in ViewPaths, as far as i remember. sounds like an
interesting task. i will investigate on that this weekend.

btw, we also have a similar post from [yury] concerning caching of
view file names.

cheers, anybody already drinking?
nick

On Thu, Dec 3, 2009 at 11:36 AM, Karl Varga <kjvarga at gmail.com> wrote:
> Hi guys,
>
> I've tried to wade through the ActionView code to figure this out with
> no luck. ?I'm wondering how many times a view file is read? ?If I
> render a view 100 times is that expensive? ?I think it would cache the
> contents of the view file...but I don't know for sure. ?The views are
> quite small so I'm considering inlining them if it's expensive.
>
> THanks,
> Karl
>
> --
> Karl Varga
> kjvarga at gmail.com
> Cell: +61 (0)4 2075 1356
> Skype: kjvarga
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>

From apotonick at gmail.com  Wed Dec  9 16:49:03 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Wed, 9 Dec 2009 22:49:03 +0100
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <1248282045.11331.16.camel@wyjec>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248210042.24919.10.camel@wyjec>
	<a9d2d0fd0907211417m63b3deb2n69621f022e50ab4d@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
Message-ID: <e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>

2009/7/22 Micha? ?omnicki <michal.lomnicki at gmail.com>:
>
>> > What about a block defining global scope?
>> >
>> > <% with_global_scope do %>
>> > ? ? ? ?<% content_for :head do %>
>> > ? ? ? ? ? ? ? ?<%= "foobar" %>
>> > ? ? ? ?<% end %>
>> > <% end %>
>> >
>>

hey micha?,
i found out why your #with_global_scope experiment worked. you didn't
pass a block to #content_for, i bet you did like

<% with_global_scope do |view| %>
  <% view.content_for :global_block, "against globalization!" %>
<% end %>

passing strings works! however, the block argument doesn't.

<% with_global_scope do |view|
   view.content_for :global_block do %>
    <%= "global block that does not work" %>
  <% end
end %>

the problem here seems to be the block passed to #content_for. it is
bound to the Cell::View instance, and not to the global controller
template. of course, that sucks.

anyway, after spending hours of debugging in the ActionView code i
consider myself sick of rails 2.3 and i'm not sure how to solve it.
maybe just document #with_global_scope will be working with string arguments?

any ideas? anyone?

cheers!
nick


>> this looks like a very good solution, micha?.
>>
>> so this block would "capture" the output and put it in the right place?
>
> sort of. It would be cool if with_global_scope content is executed in
> context of view where cell is rendered. I'm not sure how exactly it
> should be implemented but believe it's possible :)
>
>> what kind of methods like #content_for are there?
>
> #capture for example
> http://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#M001762
>
> I don't remember more, but won't be surprised if they exist ;-)
>
> regards,
> Micha?
>
>> >
>> >> 2009/7/21 Micha? ?omnicki <michal.lomnicki at gmail.com>:
>> >> >
>> >> >> I understand the reason why plain content_for doesn't simply works and
>> >> >> thanks for the workaround, but I think that a allowing such a mixed
>> >> >> behavior could be useful to newcomers like me ;)
>> >> >
>> >> > You may create an issue on github.
>> >> > http://github.com/apotonick/cells/issues
>> >> >
>> >> > I agree with you that setting a content for an app-level layout should
>> >> > be easier than now.
>> >> >
>> >> > Michal
>> >> >
>> >> >> 2009/7/21 Micha? ?omnicki <michal.lomnicki at gmail.com>:
>> >> >> > hi Maurizio
>> >> >> >
>> >> >> >> I'd like to use this because inside my main layout, inside <head> I
>> >> >> >> have a section for js code that I fill when needed by #content_for
>> >> >> >> calls.
>> >> >> >>
>> >> >> >> Is it a common bug?
>> >> >> >
>> >> >> > I'm not sure if it's a bug. Cells support own layouts shared between
>> >> >> > then. When you call content_for it's understood as content for
>> >> >> > cell-level layout not application-level layout
>> >> >> >
>> >> >> > However it's possible to do what you want, but it's tricky and ugly, I
>> >> >> > warned you :)
>> >> >> >
>> >> >> > instead of plain content_for try
>> >> >> > <% @controller.instance_variable_get("@template").content_for :head do %
>> >> >> >>
>> >> >> > ? ? ? ?<%= "your js here" %>
>> >> >> > <% end %>
>> >> >> >
>> >> >> > but maybe someone could propose a better solution?
>> >> >> >
>> >> >> > Regards
>> >> >> > --
>> >> >> > Micha? ?omnicki
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Cells-talk mailing list
>> >> > Cells-talk at rubyforge.org
>> >> > http://rubyforge.org/mailman/listinfo/cells-talk
>> >> >
>> >> _______________________________________________
>> >> Cells-talk mailing list
>> >> Cells-talk at rubyforge.org
>> >> http://rubyforge.org/mailman/listinfo/cells-talk
>> > --
>> > Micha? ?omnicki
>> >
>> >
>> _______________________________________________
>> Cells-talk mailing list
>> Cells-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cells-talk
> --
> Micha? ?omnicki
>
>

From michal.lomnicki at gmail.com  Thu Dec 10 04:46:45 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Thu, 10 Dec 2009 10:46:45 +0100
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248210042.24919.10.camel@wyjec>
	<a9d2d0fd0907211417m63b3deb2n69621f022e50ab4d@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
	<e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
Message-ID: <1260438405.4521.26.camel@wyjec.localdomain>

Hey nick, 

> i found out why your #with_global_scope experiment worked. you didn't
> pass a block to #content_for, i bet you did like
> 
> <% with_global_scope do |view| %>
>   <% view.content_for :global_block, "against globalization!" %>
> <% end %>
> 
> passing strings works! however, the block argument doesn't.

yeah I've noticed the same. What's more - the problem will still exist
with rails 3, so we can't deal with it by waiting for new rails
version :) 
I like the idea of with_global_scope with nested blocks (maybe because
it's mine) but it seems to be tricky do make it work... or even
impossible. Image situation like that:
<% with_global_scope do |view| %>
  <% @foo = capture do %>
	Some text
  <% end %>
<% end %>

In that case @foo should be set in parent view. The more I think about
things like that the more I believe it should be simply unsupported by
cells.
In my opinion with_global_scope shouldn't be introduced into cells as it
may work only with content_for without a block and nothing else. Instead
maybe just override content_for so it may be parameterized to use cell
view or parent view scope.

Or maybe you've got an idea of wider use with_global_scope, I mean not
limited to content_for only?

zdr?wko
-- 
Micha? ?omnicki


From apotonick at gmail.com  Thu Dec 10 07:40:45 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Thu, 10 Dec 2009 13:40:45 +0100
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <1260438405.4521.26.camel@wyjec.localdomain>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248210042.24919.10.camel@wyjec>
	<a9d2d0fd0907211417m63b3deb2n69621f022e50ab4d@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
	<e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
	<1260438405.4521.26.camel@wyjec.localdomain>
Message-ID: <e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>

hey my friend!

> I like the idea of with_global_scope with nested blocks (maybe because
> it's mine) but it seems to be tricky do make it work... or even
> impossible. Image situation like that:
> <% with_global_scope do |view| %>
> ?<% @foo = capture do %>
> ? ? ? ?Some text
> ?<% end %>
> <% end %>
>
> In that case @foo should be set in parent view. The more I think about
> things like that the more I believe it should be simply unsupported by
> cells.
> In my opinion with_global_scope shouldn't be introduced into cells as it
> may work only with content_for without a block and nothing else. Instead
> maybe just override content_for so it may be parameterized to use cell
> view or parent view scope.
>
i like your idea of #with_global_scope, too, as i would like to
provide as much "rails" functionality in cells as possible.
however, there are two things that prevent the introduction of
#with_global_scope.

1. it simply breaks encapsulation. cells are meant to be independent.
with the usage #capture and friends in cell views they access some
globals which they shouldn't.

2. the more i dove in the rails view code, the more i got scared of
it. the problem begins with rails distinguishing between "views" and
"partials", and it ends with code as found in renderable.rb

view.with_template self do
        view.send(:_evaluate_assigns_and_ivars)
        view.send(:_set_controller_content_type, mime_type) if
respond_to?(:mime_type)
        view.send(method_name(local_assigns), local_assigns) do |*names|

i mean, i simply don't WANT to know what's going on there!


we should better spend our time thinking about a cell-ish approach for
the problem of having global blocks in independent cells. many people
want to insert JavaScript code so we could at least provide something
for that. anyway, this should work by propagating the global block to
the parent cell recursively where the root cell will insert the markup
into the layout or whereever.

any thougts?
prost!

nick




> Or maybe you've got an idea of wider use with_global_scope, I mean not
> limited to content_for only?
>
> zdr?wko
> --
> Micha? ?omnicki
>
>

From emmanuel.gomez at gmail.com  Thu Dec 10 11:46:34 2009
From: emmanuel.gomez at gmail.com (Emmanuel Gomez)
Date: Thu, 10 Dec 2009 08:46:34 -0800
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248210042.24919.10.camel@wyjec>
	<a9d2d0fd0907211417m63b3deb2n69621f022e50ab4d@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
	<e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
	<1260438405.4521.26.camel@wyjec.localdomain>
	<e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>
Message-ID: <60E6B9F0-C14C-412F-AB8D-6BDDF1913470@gmail.com>

I'm currently working on a solution to a subset of this problem: exporting js requirements from a cell on a per-state basis to the parent controller. Required js will be declared per-state in the cell with a class macro (like Cell::Base.cache).

My solution has a few assumptions about the parent controller and its view, but they basically boil down to a helper module JavascriptHelper#javascript, which accepts a string and stores it in an array, and a call in the layout that invokes javascript_include_tag with the list of required files. 

The final piece of the puzzle is a method Cell::Base#prepare_for(state) and a modification of Cell::ActionView#render_cell that calls #prepare_for before rendering. This allows the cell instance to call the #javascript helper method on the parent controller's template and register the required js files.

There are a lot of moving pieces; in general it's more complicated than I'd like. But, it does work with cached states. I've found content_for is problematic with caching in general. Well, any sort of side effects aside from the view complicate caching, but that's another discussion.

I have some of the described code in my fork of cells on github (http://github.com/emmanuel/cells), and most of the rest is at: http://pastie.textmate.org/737474. If anyone is interested in this, I'll add some tests for these modifications and push them to github in the next couple of days.

Emmanuel


On Dec 10, 2009, at 4:40 AM, Nick Sutterer wrote:

> hey my friend!
> 
>> I like the idea of with_global_scope with nested blocks (maybe because
>> it's mine) but it seems to be tricky do make it work... or even
>> impossible. Image situation like that:
>> <% with_global_scope do |view| %>
>>  <% @foo = capture do %>
>>        Some text
>>  <% end %>
>> <% end %>
>> 
>> In that case @foo should be set in parent view. The more I think about
>> things like that the more I believe it should be simply unsupported by
>> cells.
>> In my opinion with_global_scope shouldn't be introduced into cells as it
>> may work only with content_for without a block and nothing else. Instead
>> maybe just override content_for so it may be parameterized to use cell
>> view or parent view scope.
>> 
> i like your idea of #with_global_scope, too, as i would like to
> provide as much "rails" functionality in cells as possible.
> however, there are two things that prevent the introduction of
> #with_global_scope.
> 
> 1. it simply breaks encapsulation. cells are meant to be independent.
> with the usage #capture and friends in cell views they access some
> globals which they shouldn't.
> 
> 2. the more i dove in the rails view code, the more i got scared of
> it. the problem begins with rails distinguishing between "views" and
> "partials", and it ends with code as found in renderable.rb
> 
> view.with_template self do
>        view.send(:_evaluate_assigns_and_ivars)
>        view.send(:_set_controller_content_type, mime_type) if
> respond_to?(:mime_type)
>        view.send(method_name(local_assigns), local_assigns) do |*names|
> 
> i mean, i simply don't WANT to know what's going on there!
> 
> 
> we should better spend our time thinking about a cell-ish approach for
> the problem of having global blocks in independent cells. many people
> want to insert JavaScript code so we could at least provide something
> for that. anyway, this should work by propagating the global block to
> the parent cell recursively where the root cell will insert the markup
> into the layout or whereever.
> 
> any thougts?
> prost!
> 
> nick
> 
> 
> 
> 
>> Or maybe you've got an idea of wider use with_global_scope, I mean not
>> limited to content_for only?
>> 
>> zdr?wko
>> --
>> Micha? ?omnicki
>> 
>> 
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk


From michal.lomnicki at gmail.com  Fri Dec 11 05:43:55 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Fri, 11 Dec 2009 11:43:55 +0100
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248210042.24919.10.camel@wyjec>
	<a9d2d0fd0907211417m63b3deb2n69621f022e50ab4d@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
	<e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
	<1260438405.4521.26.camel@wyjec.localdomain>
	<e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>
Message-ID: <1260528235.5069.35.camel@wyjec.localdomain>


> 2. the more i dove in the rails view code, the more i got scared of
> it. the problem begins with rails distinguishing between "views" and
> "partials", and it ends with code as found in renderable.rb

I agree, probably the problem will be solved in Rails3.0 where partials
are going to be templates used in the same way as the others.

> view.with_template self do
>         view.send(:_evaluate_assigns_and_ivars)
>         view.send(:_set_controller_content_type, mime_type) if
> respond_to?(:mime_type)
>         view.send(method_name(local_assigns), local_assigns) do |*names|
> 
> i mean, i simply don't WANT to know what's going on there!

Sure it looks terrible :)

> we should better spend our time thinking about a cell-ish approach for
> the problem of having global blocks in independent cells. many people
> want to insert JavaScript code so we could at least provide something
> for that. anyway, this should work by propagating the global block to
> the parent cell recursively where the root cell will insert the markup
> into the layout or whereever.

Personally I deal with that problem by using unobtrusive javascript
however it requires plain javascript coding, ie:

$('a.remote').live('click', function() {
  $.get(this.href);
  return false;
});

With that approach one don't need to inject javascript anywhere. Of
course I realize that solution is not acceptable for everyone and
doesn't solve our problem, but maybe would help to deal with some
gotchas.

Propagating block to cells should work, however it seems to be a bit
complicated solution and as Emmanuel noticed we should care about
caching issues when using ie. content_for.

PS. Some beers at the weekend to strengthen minds and prefect solution
will surely come ;-)

-- 
Micha? ?omnicki


From jeremywesselman at insightbb.com  Tue Dec 15 21:13:45 2009
From: jeremywesselman at insightbb.com (Jeremy J. Wesselman)
Date: Tue, 15 Dec 2009 21:13:45 -0500
Subject: [Cells-talk] undefined method render_cell
Message-ID: <4B284259.1050402@insightbb.com>

Hello all,

I've been watching Cells for a while now and have finally got the chance 
to use it on a project.

I was following the readme to get things set up. All was going well. I 
understand what I need to do, but when I call render_cell in the view, I 
get an undefined method 'render_cell' error.

Do I need to include the module in the application controller or 
something? I've studied the cells_examples app on github and I don't see 
any special includes anywhere.

Any insight would be appreciated.

Sincerely,

Jeremy Wesselman

From jeremywesselman at insightbb.com  Wed Dec 16 00:25:30 2009
From: jeremywesselman at insightbb.com (Jeremy J. Wesselman)
Date: Wed, 16 Dec 2009 00:25:30 -0500
Subject: [Cells-talk] undefined method render_cell
In-Reply-To: <4B284259.1050402@insightbb.com>
References: <4B284259.1050402@insightbb.com>
Message-ID: <4B286F4A.70207@insightbb.com>

Hello again,

I have uninstalled the plugin and reinstalled it and it seems to be 
working now.

Sincerely,

Jeremy Wesselman

Jeremy J. Wesselman wrote:
> Hello all,
>
> I've been watching Cells for a while now and have finally got the 
> chance to use it on a project.
>
> I was following the readme to get things set up. All was going well. I 
> understand what I need to do, but when I call render_cell in the view, 
> I get an undefined method 'render_cell' error.
>
> Do I need to include the module in the application controller or 
> something? I've studied the cells_examples app on github and I don't 
> see any special includes anywhere.
>
> Any insight would be appreciated.
>
> Sincerely,
>
> Jeremy Wesselman
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>


From mike.pence at gmail.com  Wed Dec 16 00:46:27 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 16 Dec 2009 00:46:27 -0500
Subject: [Cells-talk] undefined method render_cell
In-Reply-To: <4B286F4A.70207@insightbb.com>
References: <4B284259.1050402@insightbb.com> <4B286F4A.70207@insightbb.com>
Message-ID: <7EA7BB87-EF8E-4B5A-BF8D-0EB90E311041@gmail.com>

Excellent!

Sent from my iPod

On Dec 16, 2009, at 12:25 AM, "Jeremy J. Wesselman" <jeremywesselman at insightbb.com 
 > wrote:

> Hello again,
>
> I have uninstalled the plugin and reinstalled it and it seems to be  
> working now.
>
> Sincerely,
>
> Jeremy Wesselman
>
> Jeremy J. Wesselman wrote:
>> Hello all,
>>
>> I've been watching Cells for a while now and have finally got the  
>> chance to use it on a project.
>>
>> I was following the readme to get things set up. All was going  
>> well. I understand what I need to do, but when I call render_cell  
>> in the view, I get an undefined method 'render_cell' error.
>>
>> Do I need to include the module in the application controller or  
>> something? I've studied the cells_examples app on github and I  
>> don't see any special includes anywhere.
>>
>> Any insight would be appreciated.
>>
>> Sincerely,
>>
>> Jeremy Wesselman
>> _______________________________________________
>> Cells-talk mailing list
>> Cells-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cells-talk
>>
>
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk

From apotonick at gmail.com  Wed Dec 16 04:04:55 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Wed, 16 Dec 2009 10:04:55 +0100
Subject: [Cells-talk] undefined method render_cell
In-Reply-To: <7EA7BB87-EF8E-4B5A-BF8D-0EB90E311041@gmail.com>
References: <4B284259.1050402@insightbb.com> <4B286F4A.70207@insightbb.com>
	<7EA7BB87-EF8E-4B5A-BF8D-0EB90E311041@gmail.com>
Message-ID: <e2cf7aef0912160104sdc719d4qd18226c00273e113@mail.gmail.com>

Perfect!

Sent from my ordinary PC.

Jeremy- if you have questions don't hesitate to ask us on the list. if
you need real-time help or just wanna have a nice chat, join #cells on
freenode!

cheers,
nick

On Wed, Dec 16, 2009 at 6:46 AM, Mike Pence <mike.pence at gmail.com> wrote:
> Excellent!
>
> Sent from my iPod
>
> On Dec 16, 2009, at 12:25 AM, "Jeremy J. Wesselman"
> <jeremywesselman at insightbb.com> wrote:
>
>> Hello again,
>>
>> I have uninstalled the plugin and reinstalled it and it seems to be
>> working now.
>>
>> Sincerely,
>>
>> Jeremy Wesselman
>>
>> Jeremy J. Wesselman wrote:
>>>
>>> Hello all,
>>>
>>> I've been watching Cells for a while now and have finally got the chance
>>> to use it on a project.
>>>
>>> I was following the readme to get things set up. All was going well. I
>>> understand what I need to do, but when I call render_cell in the view, I get
>>> an undefined method 'render_cell' error.
>>>
>>> Do I need to include the module in the application controller or
>>> something? I've studied the cells_examples app on github and I don't see any
>>> special includes anywhere.
>>>
>>> Any insight would be appreciated.
>>>
>>> Sincerely,
>>>
>>> Jeremy Wesselman
>>> _______________________________________________
>>> Cells-talk mailing list
>>> Cells-talk at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cells-talk
>>>
>>
>> _______________________________________________
>> Cells-talk mailing list
>> Cells-talk at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cells-talk
>
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>

From apotonick at gmail.com  Wed Dec 16 06:10:37 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Wed, 16 Dec 2009 12:10:37 +0100
Subject: [Cells-talk] render question
In-Reply-To: <1259323490.4535.13.camel@wyjec>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
	<e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
	<1259141560.4573.43.camel@wyjec>
	<e2cf7aef0911250233m39796874r3b9b32d6e18f1478@mail.gmail.com>
	<1259149062.4573.81.camel@wyjec>
	<d8ee51740911250812y2e53410dw4d201e7bed4b362c@mail.gmail.com>
	<e2cf7aef0911261505l1c9fa464k53b792817cf55d21@mail.gmail.com>
	<1259323490.4535.13.camel@wyjec>
Message-ID: <e2cf7aef0912160310p775607d0h47e6fb8929daa42@mail.gmail.com>

> I only wonder about render :nothing. Shouldn't it be done in common way
> like other render options, I mean something like render :nothing =>
> true, not just plain render :nothing?
> Passing :nothing as hash key would allow easy passing/merging/deleting
> options in the future, coz the argument for render is always a hash.
> With current approach in better-render branch it's sometimes a hash and
> sometimes a symbol.
>
> What do you think?
>
i like :nothing => true better, so we can always safely assume an
option hash. should i change that?
saufen,
nick

From apotonick at gmail.com  Sun Dec 27 08:51:45 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Sun, 27 Dec 2009 14:51:45 +0100
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0912160310p775607d0h47e6fb8929daa42@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
	<e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
	<1259141560.4573.43.camel@wyjec>
	<e2cf7aef0911250233m39796874r3b9b32d6e18f1478@mail.gmail.com>
	<1259149062.4573.81.camel@wyjec>
	<d8ee51740911250812y2e53410dw4d201e7bed4b362c@mail.gmail.com>
	<e2cf7aef0911261505l1c9fa464k53b792817cf55d21@mail.gmail.com>
	<1259323490.4535.13.camel@wyjec>
	<e2cf7aef0912160310p775607d0h47e6fb8929daa42@mail.gmail.com>
Message-ID: <e2cf7aef0912270551i4c1bd3a2j7a1ec2eca2983e07@mail.gmail.com>

yo! i just posted a brief summary about the new #render in Cells and
how to use it.
it's here: http://apotomo.de/2009/12/magic-sucks-the-new-render-is-explicit

if i don't get minimum 10 comments until new year i'm gonna close down
the whole project!!!

cheers,
nick

2009/12/16 Nick Sutterer <apotonick at gmail.com>:
>> I only wonder about render :nothing. Shouldn't it be done in common way
>> like other render options, I mean something like render :nothing =>
>> true, not just plain render :nothing?
>> Passing :nothing as hash key would allow easy passing/merging/deleting
>> options in the future, coz the argument for render is always a hash.
>> With current approach in better-render branch it's sometimes a hash and
>> sometimes a symbol.
>>
>> What do you think?
>>
> i like :nothing => true better, so we can always safely assume an
> option hash. should i change that?
> saufen,
> nick
>

From apotonick at gmail.com  Mon Dec 28 16:05:46 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Mon, 28 Dec 2009 22:05:46 +0100
Subject: [Cells-talk] content_for renders nothing
In-Reply-To: <1260528235.5069.35.camel@wyjec.localdomain>
References: <a9d2d0fd0907211245v13f143f3vb32ca88d7f868ba0@mail.gmail.com>
	<1248211724.24919.27.camel@wyjec>
	<e2cf7aef0907211442lddad23fp4f910676067b983e@mail.gmail.com>
	<1248247770.11331.5.camel@wyjec>
	<e2cf7aef0907220843l57d1eeb5qa503b4176419ee7@mail.gmail.com>
	<1248282045.11331.16.camel@wyjec>
	<e2cf7aef0912091349k1c3a647dqcd9eabb7d50d5a1e@mail.gmail.com>
	<1260438405.4521.26.camel@wyjec.localdomain>
	<e2cf7aef0912100440q3b2736ffnc12213947206ca24@mail.gmail.com>
	<1260528235.5069.35.camel@wyjec.localdomain>
Message-ID: <e2cf7aef0912281305y7b805fb2udc7dd4b0452b9611@mail.gmail.com>

hi all,
i added support for #capture and #content_for in cells. see
http://github.com/apotonick/cells/commit/ed892c156d2002e4939136d1241c9661d5cc881b

however, we have to think about how to handle capturing when having a
cache hit --> emmanuel's proposal for #prepare_for

cheers,
nick

2009/12/11 Micha? ?omnicki <michal.lomnicki at gmail.com>:
>
>> 2. the more i dove in the rails view code, the more i got scared of
>> it. the problem begins with rails distinguishing between "views" and
>> "partials", and it ends with code as found in renderable.rb
>
> I agree, probably the problem will be solved in Rails3.0 where partials
> are going to be templates used in the same way as the others.
>
>> view.with_template self do
>> ? ? ? ? view.send(:_evaluate_assigns_and_ivars)
>> ? ? ? ? view.send(:_set_controller_content_type, mime_type) if
>> respond_to?(:mime_type)
>> ? ? ? ? view.send(method_name(local_assigns), local_assigns) do |*names|
>>
>> i mean, i simply don't WANT to know what's going on there!
>
> Sure it looks terrible :)
>
>> we should better spend our time thinking about a cell-ish approach for
>> the problem of having global blocks in independent cells. many people
>> want to insert JavaScript code so we could at least provide something
>> for that. anyway, this should work by propagating the global block to
>> the parent cell recursively where the root cell will insert the markup
>> into the layout or whereever.
>
> Personally I deal with that problem by using unobtrusive javascript
> however it requires plain javascript coding, ie:
>
> $('a.remote').live('click', function() {
> ?$.get(this.href);
> ?return false;
> });
>
> With that approach one don't need to inject javascript anywhere. Of
> course I realize that solution is not acceptable for everyone and
> doesn't solve our problem, but maybe would help to deal with some
> gotchas.
>
> Propagating block to cells should work, however it seems to be a bit
> complicated solution and as Emmanuel noticed we should care about
> caching issues when using ie. content_for.
>
> PS. Some beers at the weekend to strengthen minds and prefect solution
> will surely come ;-)
>
> --
> Micha? ?omnicki
>
>