From sjoonk at gmail.com  Mon Nov  2 22:05:01 2009
From: sjoonk at gmail.com (Sukjoon Kim)
Date: Tue, 3 Nov 2009 12:05:01 +0900
Subject: [Cells-talk] how can i use will_paginate inside cell?
Message-ID: <267d5b650911021905j619c6c84pfb95c2df4bb14c13@mail.gmail.com>

I'm trying to use will_paginate helper method inside my cell. but doesn't
work.
It' goes lke this error message:

undefined method `will_paginage' for #<#<Class:0x104aae790>:0x104aae6f0>

How can i??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091103/2d58af3d/attachment.html>

From apotonick at gmail.com  Tue Nov  3 06:55:30 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Tue, 3 Nov 2009 12:55:30 +0100
Subject: [Cells-talk] how can i use will_paginate inside cell?
In-Reply-To: <267d5b650911021905j619c6c84pfb95c2df4bb14c13@mail.gmail.com>
References: <267d5b650911021905j619c6c84pfb95c2df4bb14c13@mail.gmail.com>
Message-ID: <e2cf7aef0911030355s32178a6akd8837bd584f745e0@mail.gmail.com>

hi sukjoon,
thanks for your feedback.

On Tue, Nov 3, 2009 at 4:05 AM, Sukjoon Kim <sjoonk at gmail.com> wrote:
> I'm trying to use will_paginate helper method inside my cell. but doesn't
> work.
> It' goes lke this error message:
>
> undefined method `will_paginage' for #<#<Class:0x104aae790>:0x104aae6f0>
>
usually rails plugins are addressed to controllers and/or views, at
load time they automatically extend ActionController::Base and/or
ActionView::Base, resulting in cells that simply do not know about the
additional features (since the plugin did NOT extend Cell::Base).

in your example, will_paginate extends ActionPack in
http://github.com/github/will_paginate/blob/master/lib/will_paginate.rb
like:

def enable_actionpack
      require 'will_paginate/view_helpers'
      ActionView::Base.class_eval { include ViewHelpers }

so from what i can see here is that only ActionView::Base is extended.
if you put a #will_paginate in your cell view, that should work out of
the box. is that what you need? does that work?

feel free to give more feedback, and cheers,

nick

From kjvarga at gmail.com  Fri Nov 13 00:41:15 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Fri, 13 Nov 2009 13:41:15 +0800
Subject: [Cells-talk] render question
Message-ID: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>

Hi guys,

I've recently started using cells.  It's perfect for what I'm doing,
which is a music player widget.  I started off tentatively using cells
AND presenter classes...then I realized I could just use cells after
reading some of the Cells subclassing magic.  So I did that and it
worked out great.  I had some confusions along the way, mostly around
rendering.  It just didn't work quite as I expected it to.  I started
off avoiding partials, because the source code implies that partials
are BAD...but they're the only thing that worked in the end.  Anyways,
my question is...

I have the following files:

./player/widget:
  collection_cell.rb
  playing_now_collection_cell.rb

  ./player/widget/collection:
    _empty_item.html.haml
    album_item.haml
    artist_item.haml
    collection.html.haml
    playlist_item.html.haml
    track_item.html.haml

  ./player/widget/playing_now_collection:
    _empty_item.html.haml
    track_item.html.haml

The PlayingNowCollection (PNC) is a special type of Collection but it
only needs to override the track_item view.  collection.html.haml is
the view that starts everything off, and it's the same for both
classes, so I only want that in the base class.  In collection.html I
have the following call:

.songs
  = render :partial => 'empty_item' if @show_empty_item

This works.  When displaying a PNC it uses it's _empty_item partial
and when displaying a Collection it uses the collection _empty_item
partial.  Awesome.  The problem is I want similar behaviour but I want
to render a state.  I don't know how to do it without hard-coding the
cell class as in:

  - @items.each do |item|
    = render_cell 'player/widget/collection', :item, :item => item

(BTW it would be great to have render :collection support...)

How can I do this?  render :view => :item doesn't work.  And that's
another problem.  I would expect render :view to first look in the
directory of the Cell class that was instantiated (PNC in this
example), not in the directory that the calling view resides in
(collection).  That's what forced me to use partials, they seem to do
the "right" thing.  But now I'm having the same problem rendering the
state of a subclass from a view in the superclass.

Regards,
Karl

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

From apotonick at gmail.com  Fri Nov 13 04:47:30 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Fri, 13 Nov 2009 10:47:30 +0100
Subject: [Cells-talk] render question
In-Reply-To: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
Message-ID: <e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>

hey karl!

> I've recently started using cells. ?It's perfect for what I'm doing,
>
cool.

> How can I do this? ?render :view => :item doesn't work. ?And that's
> another problem. ?I would expect render :view to first look in the
> directory of the Cell class that was instantiated (PNC in this
> example), not in the directory that the calling view resides in
> (collection). ?That's what forced me to use partials, they seem to do
> the "right" thing. ?But now I'm having the same problem rendering the
> state of a subclass from a view in the superclass.
>
after reading it twice i finally got what you might want, correct me
if i'm wrong:

render :view => :item should only work in the cell state method right
now - so, in your cell

def collection
  @songs = collect_all_songs

  render :view => :list_songs
end

will render the list_songs.html.haml view and also apply the view
inheriting, by looking in PNC and then in CollectionCell directories.

what you are trying to do is to use #render in views, where you
suppose the view inheritance to work. like

file: list_songs.html.haml
.songs
  = render :view => :song_item

right?

i'm really not sure what will happen here, i have to look in the code.
the current rule is to use another #render_cell in your view, since we
want to avoid partials.
would you like to have partial-rendering with inheritance in cell
views? if yes, i think (again) render :view => :list_songs in views
should do exactly the same as in state methods.

what do you think?


cheers,
nick

From kjvarga at gmail.com  Fri Nov 13 09:13:41 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Fri, 13 Nov 2009 22:13:41 +0800
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
Message-ID: <9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>

> what you are trying to do is to use #render in views, where you
> suppose the view inheritance to work. like
>
> file: list_songs.html.haml
> .songs
> ?= render :view => :song_item
>
> right?

Correct.

> i'm really not sure what will happen here, i have to look in the code.
> the current rule is to use another #render_cell in your view, since we
> want to avoid partials.
> would you like to have partial-rendering with inheritance in cell
> views? if yes, i think (again) render :view => :list_songs in views
> should do exactly the same as in state methods.

The partial rendering with inheritance is working as I would expect.
However, I've not been able to render :view from inside a view (and
with inheritance) successfully.  I think it's down to this difference
between the path lookups for partials and views in lib/cell/view.rb:

    def render(options = {}, local_assigns = {}, &block)
      if partial_path = options[:partial]
        # adds the cell name to the partial name.
        options[:partial] = expand_view_path(partial_path)
      end
      super(options, local_assigns, &block)
    end

    def expand_view_path(path)
      path = "#{cell.cell_name}/#{path}" unless path.include?('/')
      path
    end

But I can't be certain.  It would probably work if I tried a simple
example with two views in the current directory, but I've only tried
to get fancy where I have:

super_class_cell.rb
super_class/
  render_first.html.haml
  should_override.html.haml
sub_class_cell.rb
sub_class/
  should_override.html.haml

render_first.html.haml
= render :view => :should_override

I would expect render_cell(:sub_class, :render_first) to render
super_class/render_first.html.html and
sub_class/should_override.html.haml.  But it doesn't seem to find
sub_class/should_override.html.haml.  Usually it ends up rendering
nothing and not complaining...which is weird.

I don't see the point in using a render_cell call to render a view of
the current cell.  Why do we need to instantiate the cell again when
we already have it?  Furthermore, a render_cell call forces you to
define a state for every view, which is most often unnecessary.  Any
similarly, why can't I render another state of the current cell from
inside a view without calling render_cell?  I've already done all the
heavy lifting and setup my cell instance variables to use in my views,
I don't want to have to do that for every view rendering.

The solution I've come up with to get around these limitations is to
call render_state on the @cell instance variable from inside a view
e.g.

= @cell.render_state(:collection)
= @cell.render_state(:another_state)

I'd like to see render working the same in view and states, however.
Something like:

render :state => :state_name   # render the state with that name in
the current cell, or it's super-class
render :view => :view_name    # render the named view, starting the
lookup in the directory of the cell instance and working up through
it's super-classes.  when rendering views/partials in directories of
super-classes, the lookups will still start at the directory of the
original cell instance.
render :cell => :cell_name, :state # btw it took me a while to figure
out how to render a nested cell...would be useful to have in the docs
e.g. render_cell 'player/widget/playing_now_collection', :show, :user
=> @user

I thought cells were supposed to abolish the *single render* doctine
of Rails.  But I'm finding it frustrating that I can't render two
views in a state, or two views in a view.  I have to use partials.
Maybe I'm doing it wrong, I'm not entirely sure.

I hope some of that is clear :)

Any thoughts?

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

From apotonick at gmail.com  Fri Nov 13 11:56:41 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Fri, 13 Nov 2009 17:56:41 +0100
Subject: [Cells-talk] render question
In-Reply-To: <9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
Message-ID: <e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>

yo karl,

> I thought cells were supposed to abolish the *single render* doctine
> of Rails. ?But I'm finding it frustrating that I can't render two
> views in a state, or two views in a view. ?I have to use partials.
> Maybe I'm doing it wrong, I'm not entirely sure.
>
i see your point. when cells were brought to life we considered
#render_cell to be fairly enough everywhere.
what i can get from your very clear posting (thanks):

- render :state
- render :view
- render :locals =>
- render :collection =>

the same #render should be available in views AND cell states (not as
in rails, two different implementations).

i'd love to get rid of the term "partial", since cells and their
corresponding views are something like "partials". we could just use
"view" everywhere. so, if you would like to render another "partial"
in a state view it would be

.comments
  = render :view => :comments, :locals => comments

the view :comments would be looked up in

sub/comments.html.haml
super/comments.haml.haml
...


NO partial semantics at all, especially no "_comments.html.haml".
ok? what do you think?


nick

From kjvarga at gmail.com  Fri Nov 13 13:09:09 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Sat, 14 Nov 2009 02:09:09 +0800
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
Message-ID: <9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>

Yes!  That's exactly it :)  I think that would work wonderfully.
Since these views are already "partials", but at the same time, can be
so much more.

I like having the option of rendering a view in a view and not
requiring that view to have a corresponding state.  And if the view is
a component that you use often, and want to plug in somewhere else,
you can create a state for it, set up your magic variables, and render
it that way too.

One thing though.  I would be great if a view rendered from a view
still had access to the instance variables (so you didn't *have* to
pass everything through locals).  I think it would, right? as long as
you were reusing the same cell instance, and why wouldn't you?

That gives you the option of using locals to keep views reusable, or
instance variables (or a combination of both) for highly integrated
components where you don't want to have to pass in X locals every
time.

I really like your cells work by the way.  It's great stuff.  It's
allowed me to create a nicely organized structure for what would
otherwise be a real mess.

Regards,
Karl

On Sat, Nov 14, 2009 at 12:56 AM, Nick Sutterer <apotonick at gmail.com> wrote:
> yo karl,
>
>> I thought cells were supposed to abolish the *single render* doctine
>> of Rails. ?But I'm finding it frustrating that I can't render two
>> views in a state, or two views in a view. ?I have to use partials.
>> Maybe I'm doing it wrong, I'm not entirely sure.
>>
> i see your point. when cells were brought to life we considered
> #render_cell to be fairly enough everywhere.
> what i can get from your very clear posting (thanks):
>
> - render :state
> - render :view
> - render :locals =>
> - render :collection =>
>
> the same #render should be available in views AND cell states (not as
> in rails, two different implementations).
>
> i'd love to get rid of the term "partial", since cells and their
> corresponding views are something like "partials". we could just use
> "view" everywhere. so, if you would like to render another "partial"
> in a state view it would be
>
> .comments
> ?= render :view => :comments, :locals => comments
>
> the view :comments would be looked up in
>
> sub/comments.html.haml
> super/comments.haml.haml
> ...
>
>
> NO partial semantics at all, especially no "_comments.html.haml".
> ok? what do you think?
>
>
> nick
>



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

From apotonick at gmail.com  Fri Nov 13 14:51:28 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Fri, 13 Nov 2009 20:51:28 +0100
Subject: [Cells-talk] render question
In-Reply-To: <9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
Message-ID: <e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>

> Yes! ?That's exactly it :) ?I think that would work wonderfully.
> Since these views are already "partials", but at the same time, can be
> so much more.
>
so you like the idea of disposing of the term "partials" in cells?

i really like the idea of using render :view in views while still
being able to access the instance vars of the cell. this sounds
conclusive to me, as views always get an instance of something to
stick to.
if you don't want that, you could use
render(:state)/render_cell/render(:cell) and have a complete separate
environment. cool. was your idea :-D

gotta drink now!
cheers,

nick

> I really like your cells work by the way. ?It's great stuff. ?It's
> allowed me to create a nicely organized structure for what would
> otherwise be a real mess.
>
we all love hearing that :-D

From kjvarga at gmail.com  Sat Nov 14 00:36:34 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Sat, 14 Nov 2009 13:36:34 +0800
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
Message-ID: <9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>

> so you like the idea of disposing of the term "partials" in cells?

Yeah.  I can't see a need for them now.

> i really like the idea of using render :view in views while still
> being able to access the instance vars of the cell. this sounds
> conclusive to me, as views always get an instance of something to
> stick to.
> if you don't want that, you could use
> render(:state)/render_cell/render(:cell) and have a complete separate
> environment. cool. was your idea :-D

Totally :).  Sounds good.

I was thinking the syntax for render :cell would be like the Rails
view rendering, and would need to include the state name:
render :cell => 'player/widget/playing_now_collection/show', :opt1 =>
val, :opt2 => val

That would render the PlayingNowCollectionCell show state and pass in
the options.

I also think it should render the default view for a state if the
state method DNE.  Like how Rails controllers work.  Since cells are
mini controllers I think this also makes sense.  This would be useful
when you have static views that you want to include in a number of
different components.

I think all that would be required is in cell/base.rb:

    def dispatch_state(state)
      send(state)
    rescue NoMethodError
      {}
    end

That would have the same effect as an empty method with a render call
in it.  And if the view DNE an ActionView::MissingTemplate would be
raised.

You could do some fancier checking, but I don't think it's really
neccessary?.  I think that's better than doing:
   respond_to?(state) ? send(state) : {}
because that prevents you using method_missing() as a catch-all in
your cell class.  There's actually a bug in ActiveRecord's
AssociationProxy like this.

I was also thinking it would be cool to have before and after filters.
 This would be for setting up instance variables and doing general
lifting when you have a number of states that require the same
initialization code.  Right now I'm using the initialize() method to
do setup that is common to all my states, but I can see a use for it.
An after filter would also be useful for similar reasons.

Have a good weekend, Nick!

Cheers,
Karl

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

From michal.lomnicki at gmail.com  Sun Nov 15 15:26:35 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Sun, 15 Nov 2009 21:26:35 +0100
Subject: [Cells-talk] Cells 3.0
Message-ID: <1258316795.4804.20.camel@wyjec>

Hello guys,

I would like to introduce you Cells port for Rails 3.0.
http://github.com/mlomnicki/cells3

Fork is under heavy development but able to use.

Beside making cells compatible with the newest Rails the goal is to
improve cells and add some nifty features. 
Some tasks are done currently:
* support for filters
* initial code cleanup
* initializer 

To make cells lightweight you can choose which features you want to use
Example:
Cells::Initializer.run do |cell|
  cell.use_helpers = true
  cell.use_filters = true
  cell.use_layouts = false
  cell.use_caching = false
end

More in cells3 README.

If you would like to test it just go to 
http://github.com/mlomnicki/rails3_setup
and follow README - you'll easily run full rails 3.0 framework including
cells 3.0.

Each concept, feature request, patch, criticism and amazement is very
very welcomed. 
I hope there will be some responses - your opinion is very important!

Regards
-- 
Micha? ?omnicki


From mike.pence at gmail.com  Mon Nov 16 10:27:08 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Mon, 16 Nov 2009 10:27:08 -0500
Subject: [Cells-talk] Cells 3.0
In-Reply-To: <1258316795.4804.20.camel@wyjec>
References: <1258316795.4804.20.camel@wyjec>
Message-ID: <d8ee51740911160727u793ccfbcm961a31b1b6f53983@mail.gmail.com>

Very exciting! Looking forward to finding out more about it!

There is a lot of support for having Engines-like and Merb-Parts-like
functionality in Rails (see http://rails.uservoice.com), and I think  we
have a unique opportunity to fill some of that understandable demand.

2009/11/15 Micha? ?omnicki <michal.lomnicki at gmail.com>

> Hello guys,
>
> I would like to introduce you Cells port for Rails 3.0.
> http://github.com/mlomnicki/cells3
>
> Fork is under heavy development but able to use.
>
> Beside making cells compatible with the newest Rails the goal is to
> improve cells and add some nifty features.
> Some tasks are done currently:
> * support for filters
> * initial code cleanup
> * initializer
>
> To make cells lightweight you can choose which features you want to use
> Example:
> Cells::Initializer.run do |cell|
>  cell.use_helpers = true
>  cell.use_filters = true
>  cell.use_layouts = false
>  cell.use_caching = false
> end
>
> More in cells3 README.
>
> If you would like to test it just go to
> http://github.com/mlomnicki/rails3_setup
> and follow README - you'll easily run full rails 3.0 framework including
> cells 3.0.
>
> Each concept, feature request, patch, criticism and amazement is very
> very welcomed.
> I hope there will be some responses - your opinion is very important!
>
> Regards
> --
> Micha? ?omnicki
>
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091116/0f80e7cb/attachment.html>

From mike.pence at gmail.com  Mon Nov 16 10:44:06 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Mon, 16 Nov 2009 10:44:06 -0500
Subject: [Cells-talk] render question
In-Reply-To: <9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
Message-ID: <d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>

This is an excellent conversation that, for me, begs the larger question:
Where are we keeping track of issues for Cells and Apotomo? Should we be
using the Issues tab for the projects in Github, like
http://github.com/apotonick/apotomo/issues?

I created some lighthouse ticket repos some time ago, at
http://mikepence.lighthouseapp.com, and Nick seems to be still be using
those.

In any event, I am happy to say that I see myself taking a more active role
in development and in making tutorials in the immediate future. I just have
to figure out the mechanics of having Cells and Apotomo as separate github
repos under my Rails projects, and the workings of plugin development in
general, with Netbeans.

Any pointers on that appreciated.

So, let's decide. Do we track issues on Github? And can we make some tickets
for the things that Karl has suggested? I am not saying that I agree or
necessarily think that we should develop all of his ideas -- I need to look
into them more -- but they are certainly worth capturing.

Best,
Mike Pence

On Sat, Nov 14, 2009 at 12:36 AM, Karl Varga <kjvarga at gmail.com> wrote:

> > so you like the idea of disposing of the term "partials" in cells?
>
> Yeah.  I can't see a need for them now.
>
> > i really like the idea of using render :view in views while still
> > being able to access the instance vars of the cell. this sounds
> > conclusive to me, as views always get an instance of something to
> > stick to.
> > if you don't want that, you could use
> > render(:state)/render_cell/render(:cell) and have a complete separate
> > environment. cool. was your idea :-D
>
> Totally :).  Sounds good.
>
> I was thinking the syntax for render :cell would be like the Rails
> view rendering, and would need to include the state name:
> render :cell => 'player/widget/playing_now_collection/show', :opt1 =>
> val, :opt2 => val
>
> That would render the PlayingNowCollectionCell show state and pass in
> the options.
>
> I also think it should render the default view for a state if the
> state method DNE.  Like how Rails controllers work.  Since cells are
> mini controllers I think this also makes sense.  This would be useful
> when you have static views that you want to include in a number of
> different components.
>
> I think all that would be required is in cell/base.rb:
>
>    def dispatch_state(state)
>      send(state)
>    rescue NoMethodError
>      {}
>    end
>
> That would have the same effect as an empty method with a render call
> in it.  And if the view DNE an ActionView::MissingTemplate would be
> raised.
>
> You could do some fancier checking, but I don't think it's really
> neccessary?.  I think that's better than doing:
>   respond_to?(state) ? send(state) : {}
> because that prevents you using method_missing() as a catch-all in
> your cell class.  There's actually a bug in ActiveRecord's
> AssociationProxy like this.
>
> I was also thinking it would be cool to have before and after filters.
>  This would be for setting up instance variables and doing general
> lifting when you have a number of states that require the same
> initialization code.  Right now I'm using the initialize() method to
> do setup that is common to all my states, but I can see a use for it.
> An after filter would also be useful for similar reasons.
>
> Have a good weekend, Nick!
>
> Cheers,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091116/ccbe1115/attachment.html>

From michal.lomnicki at gmail.com  Mon Nov 16 11:14:06 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Mon, 16 Nov 2009 17:14:06 +0100
Subject: [Cells-talk] render question
In-Reply-To: <d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
Message-ID: <1258388046.14264.14.camel@wyjec>



> I created some lighthouse ticket repos some time ago, at
> http://mikepence.lighthouseapp.com, and Nick seems to be still be
> using those. 

hmm that's interesting. I even didn't know tickets for cells exist
there.

> In any event, I am happy to say that I see myself taking a more active
> role in development and in making tutorials in the immediate future. 

That's cool! In my opinion cells have potential to be number 1 component
framework for Rails and be as popular as ie. mislav-will_paginate. 
I think we should clarify some fundamental concepts of cells like render
API mentioned by Karl recently.

> So, let's decide. Do we track issues on Github? 

I vote for github as it would be better to have source, issues and wiki
in one place.


regards
-- 
Micha? ?omnicki


From apotonick at gmail.com  Mon Nov 16 16:58:54 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Mon, 16 Nov 2009 22:58:54 +0100
Subject: [Cells-talk] render question
In-Reply-To: <d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
Message-ID: <e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>

hey mike, hey list,

> So, let's decide. Do we track issues on Github? And can we make some tickets
> for the things that Karl has suggested? I am not saying that I agree or
> necessarily think that we should develop all of his ideas -- I need to look
> into them more -- but they are certainly worth capturing.
>
i can't even remember my lighthouse password :-D i would be fine with
keeping things at github for now.

from the last discussion i compiled an RFC or draft for an improved
#render implementation, please comment!
http://wiki.github.com/apotonick/cells/rfc-api-for-render

cheers,

nick


> Best,
> Mike Pence
>
> On Sat, Nov 14, 2009 at 12:36 AM, Karl Varga <kjvarga at gmail.com> wrote:
>>
>> > so you like the idea of disposing of the term "partials" in cells?
>>
>> Yeah. ?I can't see a need for them now.
>>
>> > i really like the idea of using render :view in views while still
>> > being able to access the instance vars of the cell. this sounds
>> > conclusive to me, as views always get an instance of something to
>> > stick to.
>> > if you don't want that, you could use
>> > render(:state)/render_cell/render(:cell) and have a complete separate
>> > environment. cool. was your idea :-D
>>
>> Totally :). ?Sounds good.
>>
>> I was thinking the syntax for render :cell would be like the Rails
>> view rendering, and would need to include the state name:
>> render :cell => 'player/widget/playing_now_collection/show', :opt1 =>
>> val, :opt2 => val
>>
>> That would render the PlayingNowCollectionCell show state and pass in
>> the options.
>>
>> I also think it should render the default view for a state if the
>> state method DNE. ?Like how Rails controllers work. ?Since cells are
>> mini controllers I think this also makes sense. ?This would be useful
>> when you have static views that you want to include in a number of
>> different components.
>>
>> I think all that would be required is in cell/base.rb:
>>
>> ? ?def dispatch_state(state)
>> ? ? ?send(state)
>> ? ?rescue NoMethodError
>> ? ? ?{}
>> ? ?end
>>
>> That would have the same effect as an empty method with a render call
>> in it. ?And if the view DNE an ActionView::MissingTemplate would be
>> raised.
>>
>> You could do some fancier checking, but I don't think it's really
>> neccessary?. ?I think that's better than doing:
>> ? respond_to?(state) ? send(state) : {}
>> because that prevents you using method_missing() as a catch-all in
>> your cell class. ?There's actually a bug in ActiveRecord's
>> AssociationProxy like this.
>>
>> I was also thinking it would be cool to have before and after filters.
>> ?This would be for setting up instance variables and doing general
>> lifting when you have a number of states that require the same
>> initialization code. ?Right now I'm using the initialize() method to
>> do setup that is common to all my states, but I can see a use for it.
>> An after filter would also be useful for similar reasons.
>>
>> Have a good weekend, Nick!
>>
>> Cheers,
>> 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
>
>
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
>

From mike.pence at gmail.com  Tue Nov 17 16:38:50 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Tue, 17 Nov 2009 16:38:50 -0500
Subject: [Cells-talk] Couldn't render non-existant widget `foo`
Message-ID: <d8ee51740911171338u7b74c6fcn51b844b6e80bd314@mail.gmail.com>

I keep getting the error "Couldn't render non-existant widget `foo`" when
trying to render an Apotomo widget. Anyone encountered this and know where
to look for a solution?

Also, Nick, "existant" is spelled with an "e", not an "a". :)

Best,
Mike Pence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091117/b12de1f1/attachment.html>

From apotonick at gmail.com  Wed Nov 18 03:40:42 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Wed, 18 Nov 2009 09:40:42 +0100
Subject: [Cells-talk] Couldn't render non-existant widget `foo`
In-Reply-To: <d8ee51740911171338u7b74c6fcn51b844b6e80bd314@mail.gmail.com>
References: <d8ee51740911171338u7b74c6fcn51b844b6e80bd314@mail.gmail.com>
Message-ID: <e2cf7aef0911180040rb932a74hbbd5de08ef1b9386@mail.gmail.com>

poor mike-
1. try to append &reload_tree=1 to your url when reloading the page
with a new widget tree. we should somehow detect that in dev-mode and
reload the tree automatically instead of retrieving the chached one.

2. did you look here already?
http://wiki.github.com/apotonick/apotomo/troubleshooting

hope this helps. ah and mike, could you somehow push the two new blog
posts a bit? last time you did that we had 200 visitors/day.

keep up the good work,

nick


> Also, Nick, "existant" is spelled with an "e", not an "a". :)
>
mnemonic: existEnce -> existent.... thanks ;-) fixed.

> Best,
> Mike Pence
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
>

From mike.pence at gmail.com  Wed Nov 18 12:38:13 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 18 Nov 2009 12:38:13 -0500
Subject: [Cells-talk] Couldn't render non-existant widget `foo`
In-Reply-To: <e2cf7aef0911180040rb932a74hbbd5de08ef1b9386@mail.gmail.com>
References: <d8ee51740911171338u7b74c6fcn51b844b6e80bd314@mail.gmail.com>
	<e2cf7aef0911180040rb932a74hbbd5de08ef1b9386@mail.gmail.com>
Message-ID: <d8ee51740911180938n5c72c0feseedfd6e12d137a@mail.gmail.com>

Hmm. Opening the same page in another browser caused it to work, so it is
definitely a matter of the session storing an older version of the tree. I
need to see if there is a way to force that new tree each time.

On Wed, Nov 18, 2009 at 3:40 AM, Nick Sutterer <apotonick at gmail.com> wrote:

> poor mike-
> 1. try to append &reload_tree=1 to your url when reloading the page
> with a new widget tree. we should somehow detect that in dev-mode and
> reload the tree automatically instead of retrieving the chached one.
>
> 2. did you look here already?
> http://wiki.github.com/apotonick/apotomo/troubleshooting
>
> hope this helps. ah and mike, could you somehow push the two new blog
> posts a bit? last time you did that we had 200 visitors/day.
>
> keep up the good work,
>
> nick
>
>
> > Also, Nick, "existant" is spelled with an "e", not an "a". :)
> >
> mnemonic: existEnce -> existent.... thanks ;-) fixed.
>
> > Best,
> > Mike Pence
> > _______________________________________________
> > Cells-talk mailing list
> > Cells-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/cells-talk
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091118/feacb6f0/attachment.html>

From mike.pence at gmail.com  Wed Nov 18 12:51:37 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 18 Nov 2009 12:51:37 -0500
Subject: [Cells-talk] Couldn't render non-existant widget `foo`
In-Reply-To: <d8ee51740911180938n5c72c0feseedfd6e12d137a@mail.gmail.com>
References: <d8ee51740911171338u7b74c6fcn51b844b6e80bd314@mail.gmail.com>
	<e2cf7aef0911180040rb932a74hbbd5de08ef1b9386@mail.gmail.com>
	<d8ee51740911180938n5c72c0feseedfd6e12d137a@mail.gmail.com>
Message-ID: <d8ee51740911180951l1927bcb7ia36f2485da4e67a9@mail.gmail.com>

I worked around the problem by adding a call to  flush_widget_tree to my
controller, for now.

On Wed, Nov 18, 2009 at 12:38 PM, Mike Pence <mike.pence at gmail.com> wrote:

> Hmm. Opening the same page in another browser caused it to work, so it is
> definitely a matter of the session storing an older version of the tree. I
> need to see if there is a way to force that new tree each time.
>
>
> On Wed, Nov 18, 2009 at 3:40 AM, Nick Sutterer <apotonick at gmail.com>wrote:
>
>> poor mike-
>> 1. try to append &reload_tree=1 to your url when reloading the page
>> with a new widget tree. we should somehow detect that in dev-mode and
>> reload the tree automatically instead of retrieving the chached one.
>>
>> 2. did you look here already?
>> http://wiki.github.com/apotonick/apotomo/troubleshooting
>>
>> hope this helps. ah and mike, could you somehow push the two new blog
>> posts a bit? last time you did that we had 200 visitors/day.
>>
>> keep up the good work,
>>
>> nick
>>
>>
>> > Also, Nick, "existant" is spelled with an "e", not an "a". :)
>> >
>> mnemonic: existEnce -> existent.... thanks ;-) fixed.
>>
>> > Best,
>> > Mike Pence
>> > _______________________________________________
>> > Cells-talk mailing list
>> > Cells-talk at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/cells-talk
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091118/29ba19ca/attachment.html>

From michal.lomnicki at gmail.com  Wed Nov 18 13:24:45 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Wed, 18 Nov 2009 19:24:45 +0100
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
Message-ID: <1258568685.5085.6.camel@wyjec>


> 
> from the last discussion i compiled an RFC or draft for an improved
> #render implementation, please comment!
> http://wiki.github.com/apotonick/cells/rfc-api-for-render
> 

Looks very nice.

And what about rendering plain text?

something like render :text => "cells kick ass"

Currently it can be done by returning string

def my_state
  "I'm going to be rendered"
end

vs

def my_state
  render :text =>  "I'm going to be rendered"
end

In my opinion the latter seems to be clearer. What do you think?

-- 
Micha? ?omnicki


From emmanuel.gomez at gmail.com  Wed Nov 18 14:55:25 2009
From: emmanuel.gomez at gmail.com (Emmanuel Gomez)
Date: Wed, 18 Nov 2009 11:55:25 -0800
Subject: [Cells-talk] render question
In-Reply-To: <1258568685.5085.6.camel@wyjec>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130147g660ced28u8bcf1e2547f25a47@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
Message-ID: <DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>

I'm a new cell user, so take this input for what its worth (perhaps little?). 

Personally, I'd like to see the Cells API move more towards explicitness. I really like Merb's explicit render, and the fact that Merb controller actions simply return strings. 

I know that may not be practical considering the integration with and reliance on ActionView, but I just thought I'd add my two cents to the discussion.

Cells is very cool, and I'm excitedly refactoring big ugly chunks of shared view/controller code in my current project into nice clean cells. It's a big step forward for modularity.

Emmanuel Gomez

On Nov 18, 2009, at 10:24 AM, Micha? ?omnicki wrote:

> 
>> 
>> from the last discussion i compiled an RFC or draft for an improved
>> #render implementation, please comment!
>> http://wiki.github.com/apotonick/cells/rfc-api-for-render
>> 
> 
> Looks very nice.
> 
> And what about rendering plain text?
> 
> something like render :text => "cells kick ass"
> 
> Currently it can be done by returning string
> 
> def my_state
>  "I'm going to be rendered"
> end
> 
> vs
> 
> def my_state
>  render :text =>  "I'm going to be rendered"
> end
> 
> In my opinion the latter seems to be clearer. What do you think?
> 
> -- 
> Micha? ?omnicki
> 
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk


From mike.pence at gmail.com  Tue Nov 24 14:43:59 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Tue, 24 Nov 2009 14:43:59 -0500
Subject: [Cells-talk] Using the Tab and TabPanel
Message-ID: <d8ee51740911241143l9f1f27agd3fedf1da3554fb4@mail.gmail.com>

Hey guys,

I am about to start using the Tab and TabPanel controls, but I am totally
going to have to dissect it all to understand how it works. Anyone have any
sample code on how to use these?

Best,
Mike Pence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091124/51e8cdb5/attachment-0001.html>

From apotonick at gmail.com  Tue Nov 24 17:32:34 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Tue, 24 Nov 2009 23:32:34 +0100
Subject: [Cells-talk] render question
In-Reply-To: <DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
Message-ID: <e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>

hey guys,

you may have noticed the new better-render branch already, here's the
commit history:
http://github.com/apotonick/cells/commits/better-render

most of the rails options like :text, :inline, etc work. most cells
options like :nothing and :view work, too.

> Personally, I'd like to see the Cells API move more towards explicitness. I really like Merb's explicit render, and the fact that Merb controller actions simply return strings.
>

we now come to the point where we would have to decide if we want
explicit or implicit/magic #render.

with implicit #render, something like this would work (as it did before):

def my_state
  do_something
  nil
end

would render my_state.html _automatically_.

the new explicit (and imo better) approach would contain a obligatory
call to #render

def my_state
  do_something
  render
end

the cool thing about the explicit approach is that you don't have any
magic rendering, and things like this would also work:

def my_state
  do_something
  first_content = render  # will render my_state.html

  do_more_and_go_to_sleep
  second_content = render :layout => 'sweet_frame' # will also render
my_state.html, even with a layout!

  return first_content + second_content
end

the bottom line is, explicit rendering allows multiple #render in a
state method (and in views!) where #render simply returns what it
rendered. the state method itself can return any string which will be
the actual state view. we know the latter from the actual cells
standard. did i say standard? that's exorbitant.

please comment the explicit approach. it's already available on github
right here: http://github.com/apotonick/cells/commit/360aae978c6ba70a9a6cff583b6d6bc3fb406dd1


hope to hear from you.

cheers!
nick

From apotonick at gmail.com  Tue Nov 24 17:37:20 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Tue, 24 Nov 2009 23:37:20 +0100
Subject: [Cells-talk] Using the Tab and TabPanel
In-Reply-To: <d8ee51740911241143l9f1f27agd3fedf1da3554fb4@mail.gmail.com>
References: <d8ee51740911241143l9f1f27agd3fedf1da3554fb4@mail.gmail.com>
Message-ID: <e2cf7aef0911241437r4b28d234ic65559f97eb2cafc@mail.gmail.com>

hey mike!

On Tue, Nov 24, 2009 at 8:43 PM, Mike Pence <mike.pence at gmail.com> wrote:
> Hey guys,
> I am about to start using the Tab and TabPanel controls, but I am totally
> going to have to dissect it all to understand how it works. Anyone have any
> sample code on how to use these?
>
do these widgets work at all? should take a quick look at that.
tomorrow. promised :-D

nick

> Best,
> Mike Pence
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
>

From kjvarga at gmail.com  Tue Nov 24 22:00:59 2009
From: kjvarga at gmail.com (Karl Varga)
Date: Wed, 25 Nov 2009 11:00:59 +0800
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
	<e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
Message-ID: <9042dfb30911241900x1006ce5es9108f68984f6f8a3@mail.gmail.com>

+1 for the explicit render.  I think it just makes sense.  Then it's
always true that render returns a string.  No special cases and no
magic.  And your states must return a string if you want it to return
anything.  I've encountered a few cases where I've wanted to render
two views in a state and I don't like the limitation of being forced
to only one render.

IMO this flexibility is what differentiates cells from controllers.
They're like your cool older cousin who buys you booze and gets you
into all the clubs :)

Karl

PS The Cells3 work sounds pretty awesome!  It just makes me want Rails
3 even more...

On Wed, Nov 25, 2009 at 6:32 AM, Nick Sutterer <apotonick at gmail.com> wrote:
> hey guys,
>
> you may have noticed the new better-render branch already, here's the
> commit history:
> http://github.com/apotonick/cells/commits/better-render
>
> most of the rails options like :text, :inline, etc work. most cells
> options like :nothing and :view work, too.
>
>> Personally, I'd like to see the Cells API move more towards explicitness. I really like Merb's explicit render, and the fact that Merb controller actions simply return strings.
>>
>
> we now come to the point where we would have to decide if we want
> explicit or implicit/magic #render.
>
> with implicit #render, something like this would work (as it did before):
>
> def my_state
> ?do_something
> ?nil
> end
>
> would render my_state.html _automatically_.
>
> the new explicit (and imo better) approach would contain a obligatory
> call to #render
>
> def my_state
> ?do_something
> ?render
> end
>
> the cool thing about the explicit approach is that you don't have any
> magic rendering, and things like this would also work:
>
> def my_state
> ?do_something
> ?first_content = render ?# will render my_state.html
>
> ?do_more_and_go_to_sleep
> ?second_content = render :layout => 'sweet_frame' # will also render
> my_state.html, even with a layout!
>
> ?return first_content + second_content
> end
>
> the bottom line is, explicit rendering allows multiple #render in a
> state method (and in views!) where #render simply returns what it
> rendered. the state method itself can return any string which will be
> the actual state view. we know the latter from the actual cells
> standard. did i say standard? that's exorbitant.
>
> please comment the explicit approach. it's already available on github
> right here: http://github.com/apotonick/cells/commit/360aae978c6ba70a9a6cff583b6d6bc3fb406dd1
>
>
> hope to hear from you.
>
> cheers!
> nick
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>



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

From michal.lomnicki at gmail.com  Wed Nov 25 04:32:40 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Wed, 25 Nov 2009 10:32:40 +0100
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<9042dfb30911130613q681feedfw8e1076e6a271a697@mail.gmail.com>
	<e2cf7aef0911130856q130801datb8bc3e768732a6c@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
	<e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
Message-ID: <1259141560.4573.43.camel@wyjec>


> you may have noticed the new better-render branch already, here's the
> commit history:
> http://github.com/apotonick/cells/commits/better-render

great work, I like new render more and more.


> def my_state
>   do_something
>   nil
> end
> 
> would render my_state.html _automatically_.

In my opinion it's not really automatically -- you have to return nil
which does something like render. Anyway 

>From my point of view _automatically_ means something like this

def my_state
  @username = current_user.login
end

=> renders my_state.html.erb

In that case framework calls render implicite. 

I can see advantages of both approaches as it's a bit shorter to not to
call render explicite. 

We should also remember that requiring explicit render will break
backward compatibility. Maybe it's better to deprecate rendering by
returning nil, at the moment.

> def my_state
>   do_something
>   first_content = render  # will render my_state.html
> 
>   do_more_and_go_to_sleep
>   second_content = render :layout => 'sweet_frame' # will also render
> my_state.html, even with a layout!
> 
>   return first_content + second_content
> end

Good example, I agree that explicit render is better. 
One disadvantage is that people get used to implicit render used in
rails, so they will be forced to read the docs ;)

And one thing more. What the following code do?

def my_state
  "pretty string'
end

In cells in renders "pretty string". Let's say it's ok, however when
someone does

def my_state
  @text = "pretty string"
end

he expects my_state.html to be rendered with @text instance variable
set, but of course "pretty string" is rendered, which is often
confusing. What's worse that feature is undocumented. 
All in all I think that functionality should be simply replaced by 
render :text => "pretty string".

cheers!
-- 
Micha? ?omnicki


From apotonick at gmail.com  Wed Nov 25 05:33:31 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Wed, 25 Nov 2009 11:33:31 +0100
Subject: [Cells-talk] render question
In-Reply-To: <1259141560.4573.43.camel@wyjec>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@mail.gmail.com>
	<1258568685.5085.6.camel@wyjec>
	<DF20E920-ECB4-4685-BF23-94BD8C323991@gmail.com>
	<e2cf7aef0911241432x25bd8d99t5e1db3ca2e4778f6@mail.gmail.com>
	<1259141560.4573.43.camel@wyjec>
Message-ID: <e2cf7aef0911250233m39796874r3b9b32d6e18f1478@mail.gmail.com>

yo!

> And one thing more. What the following code do?
>
> def my_state
> ?"pretty string'
> end
>
the current implementation works like this:
- if nil is returned, the view is rendered automatically (implicit)
- if a string is returned, that string's supposed to be the view already

i think we should allow returning nil for backward compatibility and
raise a deprecation note.
the rest of the current API would remain the same as before. however,
we should discourage the returning of strings (simply not document it)
and document render :text => "..." for that.

> In cells in renders "pretty string". Let's say it's ok, however when
> someone does
>
> def my_state
> ?@text = "pretty string"
> end
>

the more i think about it, the more i like an explicit render. apart
from making things more obvious we also prevent confusion!
so, if somebody comes up with the question "why does my state render
'pretty string'?" you just say "idiot- you forgot to call render!".

you're right when you say people are used to implicit rendering from
controllers, but do we really like the black magic? i know you say
"HELL NO!". so why not push things in the right direction and simply
be explicit, at the risk of becoming rails outlaws?!?!

cheers,
nick

From michal.lomnicki at gmail.com  Wed Nov 25 06:37:42 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Wed, 25 Nov 2009 12:37:42 +0100
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911250233m39796874r3b9b32d6e18f1478@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<9042dfb30911131009t5f4f66f4m82620e85757e7d68@mail.gmail.com>
	<e2cf7aef0911131151s25179433ld13926b886a4726e@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@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>
Message-ID: <1259149062.4573.81.camel@wyjec>


> the current implementation works like this:
> - if nil is returned, the view is rendered automatically (implicit)

I can say event more - view is rendered if non-string is returned, ie.
def my_state
  @text = "OMG"
  Array.new
end

Array.new is not a string so my_state.html.erb is rendered. It's a bit
strange, so another vote for explicit render.

> - if a string is returned, that string's supposed to be the view already

> i think we should allow returning nil for backward compatibility and
> raise a deprecation note.

OK, we agree here.

> the rest of the current API would remain the same as before. however,
> we should discourage the returning of strings (simply not document it)
> and document render :text => "..." for that.

That sounds OK as well.

> > In cells in renders "pretty string". Let's say it's ok, however when
> > someone does
> >
> > def my_state
> >  @text = "pretty string"
> > end
> >
> 
> the more i think about it, the more i like an explicit render. apart
> from making things more obvious we also prevent confusion!
> so, if somebody comes up with the question "why does my state render
> 'pretty string'?" you just say "idiot- you forgot to call render!".

At beginning I wasn't sure, but now I absolutely agree with you about
explicit render. Whole idea seems to be very simple:
1. render returns string
2. cell render the value returned from state
3. when you set ie. @text = 'pretty string' at the last line of state
method you return it so it's obvious the string is going to be rendered
- that's simply the rule no. 2

> you're right when you say people are used to implicit rendering from
> controllers, but do we really like the black magic? i know you say
> "HELL NO!". so why not push things in the right direction and simply
> be explicit, at the risk of becoming rails outlaws?!?!

In *my* opinion different approach is OK as long as the rules are clear,
simple and well documented. You're right saying that current rendering
model in rails is a bit of black magic, but people (including me) are
very used to it! However I see the point and I strongly believe that
cells direction is right and *better* direction. All in all I can't wait
using new approach ;)

prost!
-- 
Micha? ?omnicki


From mike.pence at gmail.com  Wed Nov 25 11:12:14 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 25 Nov 2009 11:12:14 -0500
Subject: [Cells-talk] render question
In-Reply-To: <1259149062.4573.81.camel@wyjec>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<9042dfb30911132136q55aadab2w8f70954f12a1f39b@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@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>
Message-ID: <d8ee51740911250812y2e53410dw4d201e7bed4b362c@mail.gmail.com>

What a great tagline for Cells: "They're like your cool older cousin who
buys you booze and gets you
into all the clubs :)"

2009/11/25 Micha? ?omnicki <michal.lomnicki at gmail.com>

>
> > the current implementation works like this:
> > - if nil is returned, the view is rendered automatically (implicit)
>
> I can say event more - view is rendered if non-string is returned, ie.
> def my_state
>  @text = "OMG"
>  Array.new
> end
>
> Array.new is not a string so my_state.html.erb is rendered. It's a bit
> strange, so another vote for explicit render.
>
> > - if a string is returned, that string's supposed to be the view already
>
> > i think we should allow returning nil for backward compatibility and
> > raise a deprecation note.
>
> OK, we agree here.
>
> > the rest of the current API would remain the same as before. however,
> > we should discourage the returning of strings (simply not document it)
> > and document render :text => "..." for that.
>
> That sounds OK as well.
>
> > > In cells in renders "pretty string". Let's say it's ok, however when
> > > someone does
> > >
> > > def my_state
> > >  @text = "pretty string"
> > > end
> > >
> >
> > the more i think about it, the more i like an explicit render. apart
> > from making things more obvious we also prevent confusion!
> > so, if somebody comes up with the question "why does my state render
> > 'pretty string'?" you just say "idiot- you forgot to call render!".
>
> At beginning I wasn't sure, but now I absolutely agree with you about
> explicit render. Whole idea seems to be very simple:
> 1. render returns string
> 2. cell render the value returned from state
> 3. when you set ie. @text = 'pretty string' at the last line of state
> method you return it so it's obvious the string is going to be rendered
> - that's simply the rule no. 2
>
> > you're right when you say people are used to implicit rendering from
> > controllers, but do we really like the black magic? i know you say
> > "HELL NO!". so why not push things in the right direction and simply
> > be explicit, at the risk of becoming rails outlaws?!?!
>
> In *my* opinion different approach is OK as long as the rules are clear,
> simple and well documented. You're right saying that current rendering
> model in rails is a bit of black magic, but people (including me) are
> very used to it! However I see the point and I strongly believe that
> cells direction is right and *better* direction. All in all I can't wait
> using new approach ;)
>
> prost!
> --
> Micha? ?omnicki
>
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091125/7d5eeece/attachment-0001.html>

From mike.pence at gmail.com  Wed Nov 25 11:52:42 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 25 Nov 2009 11:52:42 -0500
Subject: [Cells-talk] Some infrastructure questions
Message-ID: <d8ee51740911250852h36cc71d2pb19b17adf58d6098@mail.gmail.com>

Ok, so as I am diving into Cells and Apotomo, a couple of questions.

1. Test-first development. How does one go about doing test-first
development of a Rails plugin?
2. Submodules, maybe? I want to have my Rails project come from one git
repo, and my plugins to come from my fork of them on github. Should I be
doing this with git submodules? Anyone care to give me a step-by-step?
3. Do we have a documentation page on contributing to Apotomo and Cells?

Thanks!

Mike Pence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091125/13022281/attachment.html>

From emmanuel.gomez at gmail.com  Wed Nov 25 15:13:34 2009
From: emmanuel.gomez at gmail.com (Emmanuel Gomez)
Date: Wed, 25 Nov 2009 12:13:34 -0800
Subject: [Cells-talk] Layouts
Message-ID: <2B03CEEE-5D03-4B11-A104-D2CC8FBA53FF@gmail.com>

I'm a little confused about the state of layout support in Cells. 

I realize you can render :partial with a :layout option, but I envision layout support to be a little more like ActionController: you can set a default layout per cell, or you can explicitly render any template wrapped in any layout.

I find this kind of layout support really useful and I didn't see how to do that with Cells mainline today, so I've merged in changes from Chris Eppstein's branch. This adds a Cell::Base.layout class macro for setting a default layout for all states, and overrides some of the behavior in render_state to wrap the rendered output in a layout if requested.

Is this something that could make it into the mainline? I can add some tests for what I've got if there's any interest. Credit for the implementation goes to Chris Eppstein.

Emmanuel Gomez

From mike.pence at gmail.com  Wed Nov 25 19:49:22 2009
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 25 Nov 2009 19:49:22 -0500
Subject: [Cells-talk] Layouts
In-Reply-To: <2B03CEEE-5D03-4B11-A104-D2CC8FBA53FF@gmail.com>
References: <2B03CEEE-5D03-4B11-A104-D2CC8FBA53FF@gmail.com>
Message-ID: <d8ee51740911251649g5b7ee4ddw2b32d0e1a42121cd@mail.gmail.com>

This would be a valuable addition, IMHO.

On Wed, Nov 25, 2009 at 3:13 PM, Emmanuel Gomez <emmanuel.gomez at gmail.com>wrote:

> I'm a little confused about the state of layout support in Cells.
>
> I realize you can render :partial with a :layout option, but I envision
> layout support to be a little more like ActionController: you can set a
> default layout per cell, or you can explicitly render any template wrapped
> in any layout.
>
> I find this kind of layout support really useful and I didn't see how to do
> that with Cells mainline today, so I've merged in changes from Chris
> Eppstein's branch. This adds a Cell::Base.layout class macro for setting a
> default layout for all states, and overrides some of the behavior in
> render_state to wrap the rendered output in a layout if requested.
>
> Is this something that could make it into the mainline? I can add some
> tests for what I've got if there's any interest. Credit for the
> implementation goes to Chris Eppstein.
>
> Emmanuel Gomez
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cells-talk/attachments/20091125/4893e07a/attachment.html>

From apotonick at gmail.com  Thu Nov 26 04:12:56 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Thu, 26 Nov 2009 10:12:56 +0100
Subject: [Cells-talk] Layouts
In-Reply-To: <d8ee51740911251649g5b7ee4ddw2b32d0e1a42121cd@mail.gmail.com>
References: <2B03CEEE-5D03-4B11-A104-D2CC8FBA53FF@gmail.com>
	<d8ee51740911251649g5b7ee4ddw2b32d0e1a42121cd@mail.gmail.com>
Message-ID: <e2cf7aef0911260112v31b87835ld7e6c2cc36ac29ef@mail.gmail.com>

hey emmanuel, hi mike!

currently we have support for layouts in #render only, like
render :layout => 'freaking_frame'

so we need a default layout, too? i will take a look at your patches,
emmanuel! we can write tests together.
prost!

nick

On Thu, Nov 26, 2009 at 1:49 AM, Mike Pence <mike.pence at gmail.com> wrote:
> This would be a valuable addition, IMHO.
>
> On Wed, Nov 25, 2009 at 3:13 PM, Emmanuel Gomez <emmanuel.gomez at gmail.com>
> wrote:
>>
>> I'm a little confused about the state of layout support in Cells.
>>
>> I realize you can render :partial with a :layout option, but I envision
>> layout support to be a little more like ActionController: you can set a
>> default layout per cell, or you can explicitly render any template wrapped
>> in any layout.
>>
>> I find this kind of layout support really useful and I didn't see how to
>> do that with Cells mainline today, so I've merged in changes from Chris
>> Eppstein's branch. This adds a Cell::Base.layout class macro for setting a
>> default layout for all states, and overrides some of the behavior in
>> render_state to wrap the rendered output in a layout if requested.
>>
>> Is this something that could make it into the mainline? I can add some
>> tests for what I've got if there's any interest. Credit for the
>> implementation goes to Chris Eppstein.
>>
>> Emmanuel Gomez
>> _______________________________________________
>> 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  Thu Nov 26 06:41:11 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Thu, 26 Nov 2009 12:41:11 +0100
Subject: [Cells-talk] Some infrastructure questions
In-Reply-To: <d8ee51740911250852h36cc71d2pb19b17adf58d6098@mail.gmail.com>
References: <d8ee51740911250852h36cc71d2pb19b17adf58d6098@mail.gmail.com>
Message-ID: <e2cf7aef0911260341kf07b382r193bee21f6c8315f@mail.gmail.com>

yo mike!

On Wed, Nov 25, 2009 at 5:52 PM, Mike Pence <mike.pence at gmail.com> wrote:
> Ok, so as I am diving into Cells and Apotomo, a couple of questions.
> 1. Test-first development. How does one go about doing test-first
> development of a Rails plugin?
both Apotomo and Cells provide test helpers, they have to be improved
of course, but you can do tests like

def test_my_mike_widget
  m = cell(:mike, :waiting, 'my_mike')
  assert_state :waiting, m
  m.trigger(:payForMikeBeers)
  assert_state :grining, m
end

does that help?

> 2. Submodules, maybe? I want to have my Rails project come from one git
> repo, and my plugins to come from my fork of them on github. Should I be
> doing this with git submodules? Anyone care to give me a step-by-step?
submodules are perfect for your needs.
just do

mikes_rails_project/vendor/plugins/> git submodule add
git://github.com/apotonick/cells
mikes_rails_project/vendor/plugins> git submodule add
git://github.com/apotonick/apotomo

git init
git update

for a very good tutorial, go here (got that link from winston):
http://woss.name/blog/2008/4/9/using-git-submodules-to-track-plugins.html

> 3. Do we have a documentation page on contributing to Apotomo and Cells?
let's use the github wikis for now, ok?

> Thanks!
thanks!

nick

> Mike Pence
> _______________________________________________
> Cells-talk mailing list
> Cells-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cells-talk
>
>

From apotonick at gmail.com  Thu Nov 26 18:05:01 2009
From: apotonick at gmail.com (Nick Sutterer)
Date: Fri, 27 Nov 2009 00:05:01 +0100
Subject: [Cells-talk] render question
In-Reply-To: <d8ee51740911250812y2e53410dw4d201e7bed4b362c@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@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>
Message-ID: <e2cf7aef0911261505l1c9fa464k53b792817cf55d21@mail.gmail.com>

cheers everybody!

please do test the new better-render branch, as we want to merge it
into the mainline at the end of this week. the improved #render API
feels really stable and works perfect.

just go
vendor/plugins/cells> git checkout better-render
to switch branch

you can even do funny things like

def my_state
  render :state => :another_state, :layout => 'fancy_frame'
end

to put the output of :another_state into a fancy frame.



> What a great tagline for Cells: "They're like your cool older cousin who
> buys you booze and gets you
> into all the clubs :)"
>
let's see where i can put it on the site :-D

looking forward to merge!

cheers again,
nick

> 2009/11/25 Micha? ?omnicki <michal.lomnicki at gmail.com>
>>
>> > the current implementation works like this:
>> > - if nil is returned, the view is rendered automatically (implicit)
>>
>> I can say event more - view is rendered if non-string is returned, ie.
>> def my_state
>> ?@text = "OMG"
>> ?Array.new
>> end
>>
>> Array.new is not a string so my_state.html.erb is rendered. It's a bit
>> strange, so another vote for explicit render.
>>
>> > - if a string is returned, that string's supposed to be the view already
>>
>> > i think we should allow returning nil for backward compatibility and
>> > raise a deprecation note.
>>
>> OK, we agree here.
>>
>> > the rest of the current API would remain the same as before. however,
>> > we should discourage the returning of strings (simply not document it)
>> > and document render :text => "..." for that.
>>
>> That sounds OK as well.
>>
>> > > In cells in renders "pretty string". Let's say it's ok, however when
>> > > someone does
>> > >
>> > > def my_state
>> > > ?@text = "pretty string"
>> > > end
>> > >
>> >
>> > the more i think about it, the more i like an explicit render. apart
>> > from making things more obvious we also prevent confusion!
>> > so, if somebody comes up with the question "why does my state render
>> > 'pretty string'?" you just say "idiot- you forgot to call render!".
>>
>> At beginning I wasn't sure, but now I absolutely agree with you about
>> explicit render. Whole idea seems to be very simple:
>> 1. render returns string
>> 2. cell render the value returned from state
>> 3. when you set ie. @text = 'pretty string' at the last line of state
>> method you return it so it's obvious the string is going to be rendered
>> - that's simply the rule no. 2
>>
>> > you're right when you say people are used to implicit rendering from
>> > controllers, but do we really like the black magic? i know you say
>> > "HELL NO!". so why not push things in the right direction and simply
>> > be explicit, at the risk of becoming rails outlaws?!?!
>>
>> In *my* opinion different approach is OK as long as the rules are clear,
>> simple and well documented. You're right saying that current rendering
>> model in rails is a bit of black magic, but people (including me) are
>> very used to it! However I see the point and I strongly believe that
>> cells direction is right and *better* direction. All in all I can't wait
>> using new approach ;)
>>
>> prost!
>> --
>> 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 Nov 27 07:04:50 2009
From: michal.lomnicki at gmail.com (=?UTF-8?Q?Micha=C5=82_=C5=81omnicki?=)
Date: Fri, 27 Nov 2009 13:04:50 +0100
Subject: [Cells-talk] render question
In-Reply-To: <e2cf7aef0911261505l1c9fa464k53b792817cf55d21@mail.gmail.com>
References: <9042dfb30911122141j3ee83a4j7866ae254ecbba34@mail.gmail.com>
	<d8ee51740911160744s699f8862ocb9641b86cfc0e7@mail.gmail.com>
	<e2cf7aef0911161358h9bcd91ckcb433175d7edb6cf@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>
Message-ID: <1259323490.4535.13.camel@wyjec>

hi Nick

> please do test the new better-render branch, as we want to merge it
> into the mainline at the end of this week. the improved #render API
> feels really stable and works perfect.

It looks pretty good! 
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?

-- 
Micha? ?omnicki