From brian at pivotallabs.com  Thu Apr  2 12:58:09 2009
From: brian at pivotallabs.com (Brian Takita)
Date: Thu, 2 Apr 2009 09:58:09 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com>
Message-ID: <1d7ddd110904020958v42f10de5idd61cfdfde73d28c@mail.gmail.com>

On Wed, Apr 1, 2009 at 2:05 PM, Jeff Dean <jdean at pivotallabs.com> wrote:
> It is April 1st, but I get the sense that this is not a joke.? RailsConf
> changed their mind, and they accepted the Erector proposal.? It's a bit
> awkward, because Erector has a major flaw right now that basically makes it
> useless for it's most common use case, so we have some fixing to do before
> the conference.
What is the major flaw?
>
> Corey and Ben have both said they'd put in some time pairing to get it to
> work with me, and I think we can make progress this month.
>
> If this turns out not to be a joke, I'd like to do the following:
>
> - erector stops supporting all but the latest version of rails (will make
> the code base much easier to develop, read and maintain)
> - discontinue subversion
> - make the gemspec build on github
>
> Casebook is in the process of converting to ERB, and we can spend a little
> time getting erector to work on a real app before we fully get off erector,
> so we should be able to go to the talk with confidence that it actually
> works.
>
> Jeff
>
>
> ---------- Forwarded message ----------
> From: Shirley Bailes <shirley at oreilly.com>
> Date: Wed, Apr 1, 2009 at 11:35 PM
> Subject: Proposal accepted for RailsConf 2009
> To: Jeff Dean <jdean at pivotallabs.com>
>
>
> (To respond to this message, use the web page link at the
> bottom.)
>
> We are pleased to accept the following proposal for RailsConf
> 2009.
>
> * Advanced Views with Erector
>
> Hello!
>
> We have managed to add more space to our schedule in order to
> accept additional sessions for RailsConf 2009 in Las Vegas. Yours
> is one of the sessions we would love to accept.
>
> If you could please confirm that you have received this
> acceptance and can deliver the presentation as soon as possible,
> we'd appreciate it.
>
> To send us your response, please click on this link:
> http://en.oreilly.com/rails2009/rq/99a1407d37fe38b8229ce6077753e69e
>
> Thank you,
>
> Shirley Bailes
>
> --
> RailsConf 2009 -- http://railsconf.com/
> Las Vegas, NV -- May ?4 - May ?7, 2009
> The Official Event for the Ruby on Rails Community
>
>

From brian at pivotallabs.com  Thu Apr  2 13:29:06 2009
From: brian at pivotallabs.com (Brian Takita)
Date: Thu, 2 Apr 2009 10:29:06 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com>
Message-ID: <1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com>

On Wed, Apr 1, 2009 at 2:05 PM, Jeff Dean <jdean at pivotallabs.com> wrote:
> It is April 1st, but I get the sense that this is not a joke.? RailsConf
> changed their mind, and they accepted the Erector proposal.? It's a bit
> awkward, because Erector has a major flaw right now that basically makes it
> useless for it's most common use case, so we have some fixing to do before
> the conference.
I forgot to congratulate you. So, congratulations. :-)
>
> Corey and Ben have both said they'd put in some time pairing to get it to
> work with me, and I think we can make progress this month.
>
> If this turns out not to be a joke, I'd like to do the following:
>
> - erector stops supporting all but the latest version of rails (will make
> the code base much easier to develop, read and maintain)
There is also some cleanup that needs to happen (e.g. using a subclass
of Widget, named something like RailsWidget, instead of
monkey-patching Widget for Rails support). Maybe, if somebody want
compatibility with an older version of Rails, they can make a gem
(e.g. erector-rails-2.1?).
> - discontinue subversion
> - make the gemspec build on github
I can probably get this working. I've been liking the Jeweler library
for this purpose.
>
> Casebook is in the process of converting to ERB, and we can spend a little
> time getting erector to work on a real app before we fully get off erector,
> so we should be able to go to the talk with confidence that it actually
> works.
>
> Jeff
>
>
> ---------- Forwarded message ----------
> From: Shirley Bailes <shirley at oreilly.com>
> Date: Wed, Apr 1, 2009 at 11:35 PM
> Subject: Proposal accepted for RailsConf 2009
> To: Jeff Dean <jdean at pivotallabs.com>
>
>
> (To respond to this message, use the web page link at the
> bottom.)
>
> We are pleased to accept the following proposal for RailsConf
> 2009.
>
> * Advanced Views with Erector
>
> Hello!
>
> We have managed to add more space to our schedule in order to
> accept additional sessions for RailsConf 2009 in Las Vegas. Yours
> is one of the sessions we would love to accept.
>
> If you could please confirm that you have received this
> acceptance and can deliver the presentation as soon as possible,
> we'd appreciate it.
>
> To send us your response, please click on this link:
> http://en.oreilly.com/rails2009/rq/99a1407d37fe38b8229ce6077753e69e
>
> Thank you,
>
> Shirley Bailes
>
> --
> RailsConf 2009 -- http://railsconf.com/
> Las Vegas, NV -- May ?4 - May ?7, 2009
> The Official Event for the Ruby on Rails Community
>
>

From alex at pivotallabs.com  Thu Apr  2 18:23:20 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 2 Apr 2009 15:23:20 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com> 
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com>
Message-ID: <7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com>

Brian came over a few weeks ago and we made a checklist of things we
wanted to fix, but we had beer, so I can't remember what they all
were. IIRC:

* Make the "new" method saner, supporting the use case of creating a
widget at a point where you may not know all the stuff like what
output stream and helpers you're going to be rendering with

* Replace the "widget" method with a new method (say, "render_widget")
that takes in an instance of a widget that you've instantiated via new

* Set the output stream and helpers just before/during render, not new

* Possibly retire the "inline widget" stuff, or move it to a subclass
("Erector::Inline" ?), since the semantics are confusing -- what
happens when you pass in a block *and* you override render?

Brian, did I get the above right, or was it all an alcoholic fantasy?

Jeff, what's the major flaw? And congrats on your acceptance!

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

From alex at pivotallabs.com  Thu Apr  2 20:18:07 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 2 Apr 2009 17:18:07 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com> 
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com> 
	<7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com> 
	<565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com>
Message-ID: <7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com>

> potentially splitting erector-rails apart from erector, like rspec/rspec
> rails (needs more discussion)

My opinion on this is that it doesn't hurt to check out code that you
don't need and never require, but it hurts a lot to have two projects
with potentially diverging version numbers and mutual support
matrices. So I'd like to keep rails support in the main library,
inside a subdirectory &c where it doesn't hurt anybody who doesn't use
it.

> when you pass variables in, it makes them into methods, which override
> methods you've already defined in your widget.? I'd like to make this
> optional

This is news to me! I've been going around declaring "attr_reader" for
these just to be more self-documenting.

This reminds me of something else Brian and I were talking about:
adding a macro so people who write widgets can declare what named
variables they want or need passed in to their constructor. We could
even do it in a sneaky opt-in kind of way, e.g. if you write:

class MyWidget < Erector::Widget
  needs :title, :items

then if the caller passes in MyWidget.new({:title => "Foo", :user =>
joe}) it'll complain. But if you never declared "needs" then it'll
just gladly set @title and @user like it does now, and just not work
right when @items is nil.

> erector doens't play too well with rails - you have to use rawtext and
> helpers entirely too much - I'd like to add more helpers to the list of
> things that get automatically rendered to the buffer

Definitely. I was adding those as I came across them rather than going
through all the scattered Rails docs for all the helper methods.

> if we rename render to render_widget, we can finally use render(:partial),
> which would be a big win

I have a feeling the word "render" needs to be exised, for that reason
as well as some others. My dream architecture is a two-pass "template
method" pattern. Psuedocode:

class Widget
  def write_via(parent)
    self.output = parent.output
    self.helpers = parent.helpers
    self.write
  end
end

class FooWidget < Widget
  def write
    p do
      text "we are now writing to the parent's output stream"
      BarWidget.new(:title => "ha").write_via(self)
      # or...
      bar = BarWidget.new(:title => "ha")
      write_widget bar
    end
  end
end

I hope that gets the idea across.

> On casebook we can no longer render regular .html.erb files - it complains
> about it not defining the right class.? I'd like to figure out if this is an
> erector issue, or a casebook-specific issue, and document it or fix it.

I've had similar problems. My gut feeling is to blame Rails for not
making a clean and well-documented template renderer plugin
architecture, but I'm biased -- I blame Rails for everything. :-)

(In my current project I'm using Sinatra, Erector, ActiveRecord, and
some rake tasks I swiped from Rails. It's much more fun than
routes.rb, environments, the menagerie of bizarre helpers with
inconsistent calling conventions, etc...)

> Public Tracker Project
>
> I say we kill the lighthouse project (which is private anyway) and start a
> public tracker project for it, and get all these ideas into an organized
> backlog and let people claim them.? Any objections?

Sounds fine to me. One sanity check I would recommend is going through
the existing "for developers" page with its checklists and making sure
every point there is translated to the new system (or unchanged) so
git-noobs like me can pick up the flow.

We already have an Erector tracker project and I can make it public
any time we choose. I'll invite you to it, Jeff, so you can help
figure out if it's still relevant or if we want to wipe it and start
from scratch.

 - Alex

From list1 at gjunka.com  Fri Apr  3 06:36:36 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Fri, 03 Apr 2009 11:36:36 +0100
Subject: [Erector-devel] Contributing to Erector
Message-ID: <49D5E6B4.5000805@gjunka.com>

Hi All!
Congratulations on the acceptance of Erector proposal for RailsConf! 
Erector is a great tool and it deserves a bright future. I am trying to 
use it in my web app and from time to time I need to tweak or fix 
something here and there. I would like to ask what is the policy of 
contributing these changes back to the Erector main branch. I know that 
I would need to be listed as a contributor and that the tool is mainly 
developed by people from PivotalLabs. Are you interested in receiving 
and integrating these small improvements and fixes at all, and if yes, 
would it be better to use git or just send a diff in an email?
Kind Regards and many thanks for your work on Erector!
Grzegorz (Greg) Junka


From kingdon at panix.com  Fri Apr  3 07:03:47 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Fri,  3 Apr 2009 07:03:47 -0400 (EDT)
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com>
	(message from Alex Chaffee on Thu, 2 Apr 2009 17:18:07 -0700)
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com> 
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com> 
	<7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com> 
	<565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com>
	<7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com>
Message-ID: <20090403110347.C66E724297@panix5.panix.com>

> My opinion on this is that it doesn't hurt to check out code that you
> don't need and never require

You say you are running erector without rails.  How?  I was unable to
even run the erector non-rails tests without installing rails.  I
think the problem was in lib/erector/widgets/table.rb (where it is
commented) but this was a while ago so I don't know whether that was
the only problem.

From alex at pivotallabs.com  Fri Apr  3 11:24:55 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Fri, 3 Apr 2009 08:24:55 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <20090403110347.C66E724297@panix5.panix.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com> 
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com> 
	<7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com> 
	<565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com> 
	<7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com> 
	<20090403110347.C66E724297@panix5.panix.com>
Message-ID: <7a93bd340904030824q929aff8l23bc77b37ecb6382@mail.gmail.com>

On Fri, Apr 3, 2009 at 4:03 AM, Jim Kingdon <kingdon at panix.com> wrote:
>> My opinion on this is that it doesn't hurt to check out code that you
>> don't need and never require
>
> You say you are running erector without rails. ?How? ?I was unable to
> even run the erector non-rails tests without installing rails.

Oh, well, I'm not running the erector tests, just using the library
from a non-Rails project.

I just 'gem unpack'ed it and then did require
'erector-0.5.1/lib/erector' in my init file.

 - A

From alex at pivotallabs.com  Fri Apr  3 11:39:04 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Fri, 3 Apr 2009 08:39:04 -0700
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <49D5E6B4.5000805@gjunka.com>
References: <49D5E6B4.5000805@gjunka.com>
Message-ID: <7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>

Grzegorz -

http://erector.rubyforge.org/developers.html should tell you
everything you need to know about contributing back to erector. We
don't have formal rules yet for accepting new contributors, but if you
have any patches, please post a diff here -- or, better yet, post a
git url so we can use git's awesome diffing and merging tools. Then
we'll have a chance to review it and make any comments before we pull
it into the main branch.

I'd like to use the Apache rules for accepting new contributors, which
is that once you've made a few good patches, you should attract the
attention of an existing contributor, who becomes your sponsor. The
sponsor sends a message to this list proposing you, and current
members all reply with a simple "+1" for yes and "-1" for no. If
there's any -1's then we need to discuss it until we all agree;
otherwise you're in like Flynn :-)

 - Alex

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com



On Fri, Apr 3, 2009 at 3:36 AM, Grzegorz Junka <list1 at gjunka.com> wrote:
> Hi All!
> Congratulations on the acceptance of Erector proposal for RailsConf! Erector
> is a great tool and it deserves a bright future. I am trying to use it in my
> web app and from time to time I need to tweak or fix something here and
> there. I would like to ask what is the policy of contributing these changes
> back to the Erector main branch. I know that I would need to be listed as a
> contributor and that the tool is mainly developed by people from
> PivotalLabs. Are you interested in receiving and integrating these small
> improvements and fixes at all, and if yes, would it be better to use git or
> just send a diff in an email?
> Kind Regards and many thanks for your work on Erector!
> Grzegorz (Greg) Junka
>
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From brian.takita at gmail.com  Fri Apr  3 17:17:21 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 3 Apr 2009 14:17:21 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <20090403110347.C66E724297@panix5.panix.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com>
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com>
	<7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com>
	<565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com>
	<7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com>
	<20090403110347.C66E724297@panix5.panix.com>
Message-ID: <1d7ddd110904031417u469f8b8dqf07f02ac73502b9@mail.gmail.com>

On Fri, Apr 3, 2009 at 4:03 AM, Jim Kingdon <kingdon at panix.com> wrote:
>> My opinion on this is that it doesn't hurt to check out code that you
>> don't need and never require
>
> You say you are running erector without rails. ?How? ?I was unable to
> even run the erector non-rails tests without installing rails. ?I
> think the problem was in lib/erector/widgets/table.rb (where it is
> commented) but this was a while ago so I don't know whether that was
> the only problem.
>
Yes, there is a dependency on ActiveSupport there. That can go away.

From list1 at gjunka.com  Fri Apr  3 18:08:29 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Fri, 03 Apr 2009 23:08:29 +0100
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
Message-ID: <49D688DD.6020005@gjunka.com>

Alex,
My server is not visible outside yet. I have one server where I think I 
could run a git repository available from outside but it will take some 
time to set it up. For now my changes are really basic so I am including 
them as two diffs.

First of all I don't think the Erector User Guide is quite accurate. I 
am using a single Page layout as a superclass which is inherited by 
specific view classes. In particular in section Layout Inheritance to 
make it working I had to define the class like this:

class Views::Layouts::Page < Erector::Widget

not like written in the documentation:

class Page < Erector::Widget

And then every page like this:

class Views::Languages::Index < Views::Layouts::Page

not like written in the documentation:

class Faq < Page

I guess it may be because of some default settings, but the next example 
in the documentation mentions the full path:

class Views::Layouts::Application < Erector::Widget

It may be confusing for someone coming to Erector for the first time.

Now my changes. When using the single Page superclass without any html 
templates, every html produced by Erector contains 8 white spaces in the 
beginning of the file, fon instance: "________<!DOCTYPE html PUBLIC 
"-//W3C". I know that some people may not even notice but I am a kind of 
purist and I want to control the tool, not the otherwise ;-) The problem 
is shown in the first diff. Between "<<-ERB" and "<%" there are 8 spaces 
which are not ignored because they are a part of the html template (they 
are in the file before the sequence "<%" which starts the Ruby code). My 
fix isn't ideal but I didn't really know how I could fix this without 
moving the whole text to the left.

Now in the second diff, all the four helper methods listed as "return 
text, take block" don't really take any blocks, only options (you can 
check the rails documentation http://api.rubyonrails.org/). Helper 
link_to_function is really the only one which takes a block. I moved the 
others to the section earlier titled "helpers returning raw text", 
reorganized them a bit to keep links-related helpers together (in fact 
image_tag could probably stay at the top, anyway it is not that 
important), and added another helper label_tag.

Please let me know if you think that these changes make any sense. It 
will help me to know if these are only because I don't know Erector 
enough yet ;-)

 - Greg

Alex Chaffee wrote:
> Grzegorz -
>
> http://erector.rubyforge.org/developers.html should tell you
> everything you need to know about contributing back to erector. We
> don't have formal rules yet for accepting new contributors, but if you
> have any patches, please post a diff here -- or, better yet, post a
> git url so we can use git's awesome diffing and merging tools. Then
> we'll have a chance to review it and make any comments before we pull
> it into the main branch.
>
> I'd like to use the Apache rules for accepting new contributors, which
> is that once you've made a few good patches, you should attract the
> attention of an existing contributor, who becomes your sponsor. The
> sponsor sends a message to this list proposing you, and current
> members all reply with a simple "+1" for yes and "-1" for no. If
> there's any -1's then we need to discuss it until we all agree;
> otherwise you're in like Flynn :-)
>
>  - Alex
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
>
>
>
> On Fri, Apr 3, 2009 at 3:36 AM, Grzegorz Junka <list1 at gjunka.com> wrote:
>   
>> Hi All!
>> Congratulations on the acceptance of Erector proposal for RailsConf! Erector
>> is a great tool and it deserves a bright future. I am trying to use it in my
>> web app and from time to time I need to tweak or fix something here and
>> there. I would like to ask what is the policy of contributing these changes
>> back to the Erector main branch. I know that I would need to be listed as a
>> contributor and that the tool is mainly developed by people from
>> PivotalLabs. Are you interested in receiving and integrating these small
>> improvements and fixes at all, and if yes, would it be better to use git or
>> just send a diff in an email?
>> Kind Regards and many thanks for your work on Erector!
>> Grzegorz (Greg) Junka
>>
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>>
>>     
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff1.diff
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20090403/b7784994/attachment-0002.pl>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff2.diff
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20090403/b7784994/attachment-0003.pl>

From sconover at gmail.com  Fri Apr  3 18:41:00 2009
From: sconover at gmail.com (Steve Conover)
Date: Fri, 3 Apr 2009 15:41:00 -0700
Subject: [Erector-devel] Proposal accepted for RailsConf 2009 Accepted
In-Reply-To: <1d7ddd110904031417u469f8b8dqf07f02ac73502b9@mail.gmail.com>
References: <565072b0904011405l1106ab11rce6211df18fd2dda@mail.gmail.com> 
	<1d7ddd110904021029h48f4b93dl6ee1fb6c831c463b@mail.gmail.com> 
	<7a93bd340904021523m4236c006t6d8e61c4d70e5a65@mail.gmail.com> 
	<565072b0904021559o147794fl4a3a17bc64d9d980@mail.gmail.com> 
	<7a93bd340904021718u4ed299efhe194094c2964afe5@mail.gmail.com> 
	<20090403110347.C66E724297@panix5.panix.com>
	<1d7ddd110904031417u469f8b8dqf07f02ac73502b9@mail.gmail.com>
Message-ID: <d9743bb40904031541h36bee7c7n97a4f7f5876f685@mail.gmail.com>

You could, at the very least, have a very narrow dependency into
ActiveSupport.  There are a couple tricks to this and Ben understands
them.

Ben has also turned me on to including bits of activesupport and
thinking of that separately from "Rails", quotes-and-capital-R.
There's some very useful stuff in there, and you can pick and choose
what parts you want to bring in.  So you can use little interesting
bits of Rails without feeling like you're in Gremlins.

On Fri, Apr 3, 2009 at 2:17 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Fri, Apr 3, 2009 at 4:03 AM, Jim Kingdon <kingdon at panix.com> wrote:
>>> My opinion on this is that it doesn't hurt to check out code that you
>>> don't need and never require
>>
>> You say you are running erector without rails. ?How? ?I was unable to
>> even run the erector non-rails tests without installing rails. ?I
>> think the problem was in lib/erector/widgets/table.rb (where it is
>> commented) but this was a while ago so I don't know whether that was
>> the only problem.
>>
> Yes, there is a dependency on ActiveSupport there. That can go away.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From thewoolleyman at gmail.com  Fri Apr  3 21:01:18 2009
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 3 Apr 2009 18:01:18 -0700
Subject: [Erector-devel] Be careful with gemspec dependencies when depending
	on ActiveSupport...
Message-ID: <e3af97510904031801r722bb2fds8fed32393f878b21@mail.gmail.com>

On Fri, Apr 3, 2009 at 3:41 PM, Steve Conover <sconover at gmail.com> wrote:
> You could, at the very least, have a very narrow dependency into
> ActiveSupport. ?There are a couple tricks to this and Ben understands
> them.

Therein lies unresolvable circular dependencies, unless you are careful.

If Erector gem depends on ActiveSupport, will you make it a dependency
in the gem (e.g. for use outside of rails)?  If so, what version spec
of ActiveSupport will you depend on in the Erector gemspec?

Now, say you use Erector as part of Rails.  You activate Rails version
X, which automatically activates ActiveSupport version X.  Then you
activate the Erector gem.  If the Erector gem spec specifies a version
of ActiveSupport which is not satisfied by version X, then you have an
unresolvable dependency.

This is what happened when mislav-will_paginate used to depend on ActiveSupport.

If you only anticipate Erector to be used in Rails, then just don't
specify a dependency on ActiveSupport, and you'll be fine (you'll use
whatever version Rails already loaded)

-- Chad

From kingdon at panix.com  Fri Apr  3 21:55:08 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Fri,  3 Apr 2009 21:55:08 -0400 (EDT)
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <49D688DD.6020005@gjunka.com> (message from Grzegorz Junka on
	Fri, 03 Apr 2009 23:08:29 +0100)
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
	<49D688DD.6020005@gjunka.com>
Message-ID: <20090404015508.AC28124298@panix5.panix.com>

> I have one server where I think I could run a git repository available
> from outside but it will take some time to set it up.

You could also sign up for a free github account.  But emailing
patches is fine (git was very much designed to work well with emailed
patches).

> First of all I don't think the Erector User Guide is quite accurate. I 
> am using a single Page layout as a superclass which is inherited by 
> specific view classes.
> [define as Views::Layouts::Page instead of Page]

Well, I think it has to do with what directories you put the files in
(which is a detail which I don't think this section should go into).
But I have changed the paths roughly as you suggest (this is in
web/userguide.rb so feel free to submit future suggestions as
diffs).  Let me know if four months away from rails have led me to
forget everything I knew about rails conventions.
http://github.com/pivotal/erector/commit/c0a1f8287c4033ec31ecbc12e3ed2aa8587f3928

> Now my changes.

Can you write unit tests for these?

The one about the whitespace looks correct to me (whitespace before
<!DOCTYPE is legal but kind of funny-looking but whitespace before
<?xml is not even legal).

The one about rails helpers seems like the kind of thing which would
be really nice to have tests for, if it can be done without too much
hassle (using the existing setup whereby various tests are run with
different rails versions).  Talking to rails always has a whiff of
black magic, and tested black magic at least gives more confidence
about whether the spell has been cast correctly.

From kingdon at panix.com  Fri Apr  3 22:06:49 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Fri,  3 Apr 2009 22:06:49 -0400 (EDT)
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
	(message from Alex Chaffee on Fri, 3 Apr 2009 08:39:04 -0700)
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
Message-ID: <20090404020649.D4C2D24298@panix5.panix.com>

> I'd like to use the Apache rules for accepting new contributors, which
> is that once you've made a few good patches, you should attract the
> attention of an existing contributor, who becomes your sponsor. The
> sponsor sends a message to this list proposing you, and current
> members all reply with a simple "+1" for yes and "-1" for no.

Something along these lines sounds OK, although I would recommend
focusing on accepting and rejecting changes, not accepting and
rejecting people.

This might be a difference in mindset as much as procedure, since the
basic concept of having a central github repository which a variety of
people push to is useful and we need to have some way of adding people
to that collaborator list.  Basing this on acceptance of patches makes
more sense than basing it on intention to contribute or something.

From sconover at gmail.com  Fri Apr  3 22:47:56 2009
From: sconover at gmail.com (Steve Conover)
Date: Fri, 3 Apr 2009 19:47:56 -0700
Subject: [Erector-devel] Be careful with gemspec dependencies when
	depending on ActiveSupport...
In-Reply-To: <e3af97510904031801r722bb2fds8fed32393f878b21@mail.gmail.com>
References: <e3af97510904031801r722bb2fds8fed32393f878b21@mail.gmail.com>
Message-ID: <d9743bb40904031947x4f141d7al98770405419a86fe@mail.gmail.com>

Yeah great point.  Which IMHO strongly argues for removing the
dependency.  But the final decision ought to be left to the code
monkeys.

On Fri, Apr 3, 2009 at 6:01 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Fri, Apr 3, 2009 at 3:41 PM, Steve Conover <sconover at gmail.com> wrote:
>> You could, at the very least, have a very narrow dependency into
>> ActiveSupport. ?There are a couple tricks to this and Ben understands
>> them.
>
> Therein lies unresolvable circular dependencies, unless you are careful.
>
> If Erector gem depends on ActiveSupport, will you make it a dependency
> in the gem (e.g. for use outside of rails)? ?If so, what version spec
> of ActiveSupport will you depend on in the Erector gemspec?
>
> Now, say you use Erector as part of Rails. ?You activate Rails version
> X, which automatically activates ActiveSupport version X. ?Then you
> activate the Erector gem. ?If the Erector gem spec specifies a version
> of ActiveSupport which is not satisfied by version X, then you have an
> unresolvable dependency.
>
> This is what happened when mislav-will_paginate used to depend on ActiveSupport.
>
> If you only anticipate Erector to be used in Rails, then just don't
> specify a dependency on ActiveSupport, and you'll be fine (you'll use
> whatever version Rails already loaded)
>
> -- Chad
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From list1 at gjunka.com  Sat Apr  4 06:40:03 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Sat, 04 Apr 2009 11:40:03 +0100
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <20090404015508.AC28124298@panix5.panix.com>
References: <49D5E6B4.5000805@gjunka.com>	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
	<49D688DD.6020005@gjunka.com>
	<20090404015508.AC28124298@panix5.panix.com>
Message-ID: <49D73903.60502@gjunka.com>

Jim Kingdon wrote:
>
>> First of all I don't think the Erector User Guide is quite accurate. I 
>> am using a single Page layout as a superclass which is inherited by 
>> specific view classes.
>> [define as Views::Layouts::Page instead of Page]
>>     
>
> Well, I think it has to do with what directories you put the files in
> (which is a detail which I don't think this section should go into).
> But I have changed the paths roughly as you suggest (this is in
> web/userguide.rb so feel free to submit future suggestions as
> diffs).  Let me know if four months away from rails have led me to
> forget everything I knew about rails conventions.
> http://github.com/pivotal/erector/commit/c0a1f8287c4033ec31ecbc12e3ed2aa8587f3928
>   
The file page.rb with the super class Page I put to app/views/layouts, 
and particular views inheriting the main class, like in my example 
Languages::Index (file index.rb), I put to the app/views/languages 
(replacing index.html.erb). Similarly new.rb replaces new.html.erb in 
the same views/languages directory. These folders were created 
automatically by the Rails scaffold and I think these are pretty 
standard locations which someone starting with Erector like me would try 
to use in the first place?

BTW it may have something to do with the new REST path resolving scheme, 
introduced in one of the recent Rails 2.2 versions. Basically there are 
separate views in separates files for each of the 7 possible controller 
actions: edit, index, new, show, etc., addressed with the use of 
map.resources in config/routes.rb. I don't know because I wasn't using 
the old way of addressing controller actions with Erector.

>> Now my changes.
>>     
>
> Can you write unit tests for these?
>
> The one about the whitespace looks correct to me (whitespace before
> <!DOCTYPE is legal but kind of funny-looking but whitespace before
> <?xml is not even legal).
>
> The one about rails helpers seems like the kind of thing which would
> be really nice to have tests for, if it can be done without too much
> hassle (using the existing setup whereby various tests are run with
> different rails versions).  Talking to rails always has a whiff of
> black magic, and tested black magic at least gives more confidence
> about whether the spell has been cast correctly.
>
>   
Well I guess I can. Is there any test for the previous helpers as they 
were written before, so I could start with something? It would be also 
helpful if you could tell me how you run the current spec tests against 
Rails. There isn't much information (or at least I couldn't find it) 
about testing Erector itself.


From list1 at gjunka.com  Sat Apr  4 06:51:07 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Sat, 04 Apr 2009 11:51:07 +0100
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <20090404020649.D4C2D24298@panix5.panix.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
	<20090404020649.D4C2D24298@panix5.panix.com>
Message-ID: <49D73B9B.1080604@gjunka.com>

Jim Kingdon wrote:
>> I'd like to use the Apache rules for accepting new contributors, which
>> is that once you've made a few good patches, you should attract the
>> attention of an existing contributor, who becomes your sponsor. The
>> sponsor sends a message to this list proposing you, and current
>> members all reply with a simple "+1" for yes and "-1" for no.
>>     
>
> Something along these lines sounds OK, although I would recommend
> focusing on accepting and rejecting changes, not accepting and
> rejecting people.
>
> This might be a difference in mindset as much as procedure, since the
> basic concept of having a central github repository which a variety of
> people push to is useful and we need to have some way of adding people
> to that collaborator list.  Basing this on acceptance of patches makes
> more sense than basing it on intention to contribute or something.
>
>   
Taking an example from Linux kernel development, as far as I know only 
Linus and few trusted developers have written access to the main branch. 
All developers are submitting to temporary branches, from where changes 
are pulled to the main branch. I think in case of Erector it may be 
useful to have a bleeding edge with more developers being able to submit 
to that branch, and a stable branch to which changes are pulled on 
demand from the bleeding edge by developers who know the software the 
best (in this example it would be you as the creators). This is how 
releasing in FreeBSD works (and probably in Rails as well). How viable 
is that option?

Maybe for now there aren't many developers contributing to the project 
besides you, but after the conference, when Erector becomes a smashing 
success, it may be a more practical solution ;-)

 - Greg


From alex at pivotallabs.com  Sat Apr  4 12:32:42 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 4 Apr 2009 09:32:42 -0700
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <49D688DD.6020005@gjunka.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com> 
	<49D688DD.6020005@gjunka.com>
Message-ID: <7a93bd340904040932i4dfd4470rb8e9a50ba196a3a2@mail.gmail.com>

> First of all I don't think the Erector User Guide is quite accurate. I am
> using a single Page layout as a superclass which is inherited by specific
> view classes. In particular in section Layout Inheritance to make it working
> I had to define the class like this:
>
> class Views::Layouts::Page < Erector::Widget
>
> not like written in the documentation:
>
> class Page < Erector::Widget
>
> And then every page like this:
>
> class Views::Languages::Index < Views::Layouts::Page
>
> not like written in the documentation:
>
> class Faq < Page

I agree the documentation isn't clear, but it is *accurate* :-)

When we wrote Erector we decided to make it stand alone independently
from Rails. So the basic examples all assume(d) that you were running
stuff as a normal Ruby program, and didn't make any assumptions about
project directory layout.

I haven't had a chance to look at Jim's changes but I'll go back and
try to make sure the language is clearer about what code is generic
and what code is Rails-specific.

At first glance, your changes look righteous. Nice job :-)

 - A

From alex at pivotallabs.com  Sat Apr  4 12:42:30 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 4 Apr 2009 09:42:30 -0700
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <20090404020649.D4C2D24298@panix5.panix.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com> 
	<20090404020649.D4C2D24298@panix5.panix.com>
Message-ID: <7a93bd340904040942x31e64f7bm223408864a88031f@mail.gmail.com>

On Fri, Apr 3, 2009 at 7:06 PM, Jim Kingdon <kingdon at panix.com> wrote:
>> I'd like to use the Apache rules for accepting new contributors, which
>> is that once you've made a few good patches, you should attract the
>> attention of an existing contributor, who becomes your sponsor. The
>> sponsor sends a message to this list proposing you, and current
>> members all reply with a simple "+1" for yes and "-1" for no.
>
> Something along these lines sounds OK, although I would recommend
> focusing on accepting and rejecting changes, not accepting and
> rejecting people.
>
> This might be a difference in mindset as much as procedure, since the
> basic concept of having a central github repository which a variety of
> people push to is useful and we need to have some way of adding people
> to that collaborator list. ?Basing this on acceptance of patches makes
> more sense than basing it on intention to contribute or something.
>

I agree with the distinction. I was thinking that committers can pull
in whatever patches they want, and so it's necessary to be stricter on
who can become a committer (with great power etc). But it might be
useful to have more discussion on each individual patch that's
submitted to the list, and voting would provoke such a discussion. My
only fear in that is that email discussion threads are where good
patches go to die...

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

From m.kristian at web.de  Sat Apr  4 13:38:09 2009
From: m.kristian at web.de (kristian)
Date: Sat, 4 Apr 2009 23:08:09 +0530
Subject: [Erector-devel] form_for helper can be used as in erb now
Message-ID: <932801940904041038i41df793at100934e91053312@mail.gmail.com>

hello,

just to give something back to erector ;-)

I guess one can look which parameters could be escaped or not. but the
first step is to get widget classes cleaner with rawtext.

the hidden_tag was the second method I need rawtext.

with regards
Kristian
-- 
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-form_for-helper-can-be-used-as-in-erb-now.patch
Type: text/x-patch
Size: 1608 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20090404/021e4915/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-added-missing-hidden_tag-method.patch
Type: text/x-patch
Size: 720 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20090404/021e4915/attachment-0001.bin>

From list1 at gjunka.com  Sat Apr  4 14:36:03 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Sat, 04 Apr 2009 19:36:03 +0100
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <7a93bd340904040932i4dfd4470rb8e9a50ba196a3a2@mail.gmail.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com>
	<49D688DD.6020005@gjunka.com>
	<7a93bd340904040932i4dfd4470rb8e9a50ba196a3a2@mail.gmail.com>
Message-ID: <49D7A893.30906@gjunka.com>

Alex Chaffee wrote:
>> First of all I don't think the Erector User Guide is quite accurate. I am
>> using a single Page layout as a superclass which is inherited by specific
>> view classes. In particular in section Layout Inheritance to make it working
>> I had to define the class like this:
>>
>> class Views::Layouts::Page < Erector::Widget
>>
>> not like written in the documentation:
>>
>> class Page < Erector::Widget
>>
>> And then every page like this:
>>
>> class Views::Languages::Index < Views::Layouts::Page
>>
>> not like written in the documentation:
>>
>> class Faq < Page
>>     
>
> I agree the documentation isn't clear, but it is *accurate* :-)
>
> When we wrote Erector we decided to make it stand alone independently
> from Rails. So the basic examples all assume(d) that you were running
> stuff as a normal Ruby program, and didn't make any assumptions about
> project directory layout.
>   
Well, what about this line then:

class Views::Layouts::Application < Erector::Widget

which I mentioned in my email is in the user guide in the next example, 
after the one with the Page example? It says about stuff specific to 
Rails, but the first example is also specific to Rails. They are both in 
"Layout Inheritance" paragraph starting with "Erector replaces the 
typical Rails layout mechanism...". Obviously you don't want to write 
Rails-independent code in the section about Rails. And if you do, then 
you should do it consistently. Maybe it is not that *accurate* as you 
thought? ;-)

 - Greg


From alex at pivotallabs.com  Sat Apr  4 15:12:25 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 4 Apr 2009 12:12:25 -0700
Subject: [Erector-devel] Contributing to Erector
In-Reply-To: <49D7A893.30906@gjunka.com>
References: <49D5E6B4.5000805@gjunka.com>
	<7a93bd340904030839h3727deav4efc58aa7559ab65@mail.gmail.com> 
	<49D688DD.6020005@gjunka.com>
	<7a93bd340904040932i4dfd4470rb8e9a50ba196a3a2@mail.gmail.com> 
	<49D7A893.30906@gjunka.com>
Message-ID: <7a93bd340904041212i2d133cdaj20a3fee84fbc000a@mail.gmail.com>

OK, you got me. Busted. :-)

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com



On Sat, Apr 4, 2009 at 11:36 AM, Grzegorz Junka <list1 at gjunka.com> wrote:
> Alex Chaffee wrote:
>>>
>>> First of all I don't think the Erector User Guide is quite accurate. I am
>>> using a single Page layout as a superclass which is inherited by specific
>>> view classes. In particular in section Layout Inheritance to make it
>>> working
>>> I had to define the class like this:
>>>
>>> class Views::Layouts::Page < Erector::Widget
>>>
>>> not like written in the documentation:
>>>
>>> class Page < Erector::Widget
>>>
>>> And then every page like this:
>>>
>>> class Views::Languages::Index < Views::Layouts::Page
>>>
>>> not like written in the documentation:
>>>
>>> class Faq < Page
>>>
>>
>> I agree the documentation isn't clear, but it is *accurate* :-)
>>
>> When we wrote Erector we decided to make it stand alone independently
>> from Rails. So the basic examples all assume(d) that you were running
>> stuff as a normal Ruby program, and didn't make any assumptions about
>> project directory layout.
>>
>
> Well, what about this line then:
>
> class Views::Layouts::Application < Erector::Widget
>
> which I mentioned in my email is in the user guide in the next example,
> after the one with the Page example? It says about stuff specific to Rails,
> but the first example is also specific to Rails. They are both in "Layout
> Inheritance" paragraph starting with "Erector replaces the typical Rails
> layout mechanism...". Obviously you don't want to write Rails-independent
> code in the section about Rails. And if you do, then you should do it
> consistently. Maybe it is not that *accurate* as you thought? ;-)
>
> - Greg
>
>

From kingdon at panix.com  Sun Apr  5 08:19:24 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Sun,  5 Apr 2009 08:19:24 -0400 (EDT)
Subject: [Erector-devel] tests
Message-ID: <20090405121924.EED8924299@panix5.panix.com>

"rake spec" should run the tests (although they aren't passing for me
right now, and I'm not sure why not).  You are right that much of the
existing code (in certain parts of the rails integration especially)
is untested.  This makes it hard for me to know whether patches such
as the ones recently submitted are correct, but maybe someone else can
either write the tests, test it manually, or just eyeball it.

Unfortunately, I'm pretty busy with work these days, so I don't expect
to have time to follow up myself in a timely fashion.  I hope this
doesn't become one of those "email threads where patches go to die"
which Alex mentioned.

From brian.takita at gmail.com  Sun Apr  5 22:46:50 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 5 Apr 2009 19:46:50 -0700
Subject: [Erector-devel] Be careful with gemspec dependencies when
	depending on ActiveSupport...
In-Reply-To: <d9743bb40904031947x4f141d7al98770405419a86fe@mail.gmail.com>
References: <e3af97510904031801r722bb2fds8fed32393f878b21@mail.gmail.com>
	<d9743bb40904031947x4f141d7al98770405419a86fe@mail.gmail.com>
Message-ID: <1d7ddd110904051946u424fff21v3474bf1246d4e202@mail.gmail.com>

On Fri, Apr 3, 2009 at 7:47 PM, Steve Conover <sconover at gmail.com> wrote:
> Yeah great point. ?Which IMHO strongly argues for removing the
> dependency. ?But the final decision ought to be left to the code
> monkeys.
I think we should just remove the dependency.

It would be like 10-20 lines of code to fix it.
>
> On Fri, Apr 3, 2009 at 6:01 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> On Fri, Apr 3, 2009 at 3:41 PM, Steve Conover <sconover at gmail.com> wrote:
>>> You could, at the very least, have a very narrow dependency into
>>> ActiveSupport. ?There are a couple tricks to this and Ben understands
>>> them.
>>
>> Therein lies unresolvable circular dependencies, unless you are careful.
>>
>> If Erector gem depends on ActiveSupport, will you make it a dependency
>> in the gem (e.g. for use outside of rails)? ?If so, what version spec
>> of ActiveSupport will you depend on in the Erector gemspec?
>>
>> Now, say you use Erector as part of Rails. ?You activate Rails version
>> X, which automatically activates ActiveSupport version X. ?Then you
>> activate the Erector gem. ?If the Erector gem spec specifies a version
>> of ActiveSupport which is not satisfied by version X, then you have an
>> unresolvable dependency.
>>
>> This is what happened when mislav-will_paginate used to depend on ActiveSupport.
>>
>> If you only anticipate Erector to be used in Rails, then just don't
>> specify a dependency on ActiveSupport, and you'll be fine (you'll use
>> whatever version Rails already loaded)
>>
>> -- Chad
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>>
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From m.kristian at web.de  Mon Apr  6 00:41:51 2009
From: m.kristian at web.de (kristian)
Date: Mon, 6 Apr 2009 10:11:51 +0530
Subject: [Erector-devel] tests
In-Reply-To: <20090405121924.EED8924299@panix5.panix.com>
References: <20090405121924.EED8924299@panix5.panix.com>
Message-ID: <932801940904052141i7ca716e6j3ebfd5baed681c35@mail.gmail.com>

I am sorry that I just forgot about the test/specs along with the last
patch. unfortunatley I am (almost) offline for the next 6 weeks. but
after this I will resubmit the patch with tests.

with regards Kristian

On Sun, Apr 5, 2009 at 5:49 PM, Jim Kingdon <kingdon at panix.com> wrote:
> "rake spec" should run the tests (although they aren't passing for me
> right now, and I'm not sure why not). ?You are right that much of the
> existing code (in certain parts of the rails integration especially)
> is untested. ?This makes it hard for me to know whether patches such
> as the ones recently submitted are correct, but maybe someone else can
> either write the tests, test it manually, or just eyeball it.
>
> Unfortunately, I'm pretty busy with work these days, so I don't expect
> to have time to follow up myself in a timely fashion. ?I hope this
> doesn't become one of those "email threads where patches go to die"
> which Alex mentioned.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

From m.kristian at web.de  Mon Apr  6 00:59:43 2009
From: m.kristian at web.de (kristian)
Date: Mon, 6 Apr 2009 10:29:43 +0530
Subject: [Erector-devel] rails generators (the second)
Message-ID: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>

hello,

I once had this topic again but it was turned down in favour of the erect tool.

but I need to get to it again. time passed and the way I use erector
is beyond what the default generator and erect are doing.

the best is to have a look at my personal sandbox
http://github.com/mkristian/kristians_rails_plugins/tree/e41ee0ef959c5837ee3d257c41d4ee4a0ab1233a/erector_widgets

why I think an erector generator is better than the combination rails
default generator + erect:
* rerun the generator allows to identify modified files, you can have
look at the diff and decide whether you want to overwrite them or not.
with
 rails default generator + erect you do not get that feature
* erector is more elegant then just replacing erb files with erector widgets

the above generator uses datamapper instead of activerecord that is
why things like the error messages are a bit strange. anyways what I
do here is to offer two base widgets for displaying data models. for
each restful resource I have 4 view files: new.rb, show.rb, edit.rb
and index.rb. the first three reuse the MyModelWidget and the index.rb
uses MyModelsWidget (the list of model entities). with this all four
files are very small and on top you can use the MyModel(s)Widgets at
other places where needed. so basically using a composite pattern to
setup the views.

so in my opinion this would help to show the potential which lies in
erector. since the above is my personal sandbox is carries some extras
which is not needed for a public, but if you guys change your opinion
about erector generators I can provide them. if you do not like my
approach that is also OK for me since I am using erector all over the
place and I am about to migrate even two more small projects to use
erector (most probably using my generators and regenerate some code
with it)

with regards Kristian

From m.kristian at web.de  Mon Apr  6 02:30:46 2009
From: m.kristian at web.de (kristian)
Date: Mon, 6 Apr 2009 12:00:46 +0530
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
Message-ID: <932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>

just thinking about it again. maybe things become a bit cleaner and
worth considering it if there are two gems:
erector
erector-rails
like you have it with rspecs, rspecs-rails. the latter has the all the
rails specific code and would be the right place for a few generators.
for example I still look for a nice way to test/spec my widgets, I
guess I have to look at the erector test once.

regards Kristian

On Mon, Apr 6, 2009 at 10:29 AM, kristian <m.kristian at web.de> wrote:
> hello,
>
> I once had this topic again but it was turned down in favour of the erect tool.
>
> but I need to get to it again. time passed and the way I use erector
> is beyond what the default generator and erect are doing.
>
> the best is to have a look at my personal sandbox
> http://github.com/mkristian/kristians_rails_plugins/tree/e41ee0ef959c5837ee3d257c41d4ee4a0ab1233a/erector_widgets
>
> why I think an erector generator is better than the combination rails
> default generator + erect:
> * rerun the generator allows to identify modified files, you can have
> look at the diff and decide whether you want to overwrite them or not.
> with
> ?rails default generator + erect you do not get that feature
> * erector is more elegant then just replacing erb files with erector widgets
>
> the above generator uses datamapper instead of activerecord that is
> why things like the error messages are a bit strange. anyways what I
> do here is to offer two base widgets for displaying data models. for
> each restful resource I have 4 view files: new.rb, show.rb, edit.rb
> and index.rb. the first three reuse the MyModelWidget and the index.rb
> uses MyModelsWidget (the list of model entities). with this all four
> files are very small and on top you can use the MyModel(s)Widgets at
> other places where needed. so basically using a composite pattern to
> setup the views.
>
> so in my opinion this would help to show the potential which lies in
> erector. since the above is my personal sandbox is carries some extras
> which is not needed for a public, but if you guys change your opinion
> about erector generators I can provide them. if you do not like my
> approach that is also OK for me since I am using erector all over the
> place and I am about to migrate even two more small projects to use
> erector (most probably using my generators and regenerate some code
> with it)
>
> with regards Kristian
>



-- 
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

From brian.takita at gmail.com  Mon Apr  6 03:13:08 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 6 Apr 2009 00:13:08 -0700
Subject: [Erector-devel] pivotal-erector gem being built on github
Message-ID: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>

FYI, I got pivotal-erector being built on EY. Currently, version 0.5.1
is released.

I removed the hoe task from the Rakefile, which would break the
deployment to Rubyforge, I presume.

I'm not sure what our Rubyforge strategy would be, but I know that I
have not been able to successfully deploy Erector there due to
permission issues.

We have two options here:
1. Get permissions working on Rubyforge so multiple core team members
can deploy a new version of Erector
2. Have the Erector site on Github

From brian.takita at gmail.com  Mon Apr  6 03:16:13 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 6 Apr 2009 00:16:13 -0700
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
Message-ID: <1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>

Thank you Kristian. We are in the process of deciding what to do
regarding packaging Erector and Rails integration.
Would everybody else like to chime in on this?

On Sun, Apr 5, 2009 at 11:30 PM, kristian <m.kristian at web.de> wrote:
> just thinking about it again. maybe things become a bit cleaner and
> worth considering it if there are two gems:
> erector
> erector-rails
> like you have it with rspecs, rspecs-rails. the latter has the all the
> rails specific code and would be the right place for a few generators.
> for example I still look for a nice way to test/spec my widgets, I
> guess I have to look at the erector test once.
>
> regards Kristian
>
> On Mon, Apr 6, 2009 at 10:29 AM, kristian <m.kristian at web.de> wrote:
>> hello,
>>
>> I once had this topic again but it was turned down in favour of the erect tool.
>>
>> but I need to get to it again. time passed and the way I use erector
>> is beyond what the default generator and erect are doing.
>>
>> the best is to have a look at my personal sandbox
>> http://github.com/mkristian/kristians_rails_plugins/tree/e41ee0ef959c5837ee3d257c41d4ee4a0ab1233a/erector_widgets
>>
>> why I think an erector generator is better than the combination rails
>> default generator + erect:
>> * rerun the generator allows to identify modified files, you can have
>> look at the diff and decide whether you want to overwrite them or not.
>> with
>> ?rails default generator + erect you do not get that feature
>> * erector is more elegant then just replacing erb files with erector widgets
>>
>> the above generator uses datamapper instead of activerecord that is
>> why things like the error messages are a bit strange. anyways what I
>> do here is to offer two base widgets for displaying data models. for
>> each restful resource I have 4 view files: new.rb, show.rb, edit.rb
>> and index.rb. the first three reuse the MyModelWidget and the index.rb
>> uses MyModelsWidget (the list of model entities). with this all four
>> files are very small and on top you can use the MyModel(s)Widgets at
>> other places where needed. so basically using a composite pattern to
>> setup the views.
>>
>> so in my opinion this would help to show the potential which lies in
>> erector. since the above is my personal sandbox is carries some extras
>> which is not needed for a public, but if you guys change your opinion
>> about erector generators I can provide them. if you do not like my
>> approach that is also OK for me since I am using erector all over the
>> place and I am about to migrate even two more small projects to use
>> erector (most probably using my generators and regenerate some code
>> with it)
>>
>> with regards Kristian
>>
>
>
>
> --
> Kristian Meier + Saumya Sharma + Sanuka Meier
> Vadakkethu House,
> Edayanmula West PO - 689532,
> Pathanamthitta District, Kerala, INDIA
>
> tel: +91 468 2319577
>
> protect your privacy while searching the net: www.ixquick.com
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From list1 at gjunka.com  Mon Apr  6 05:12:37 2009
From: list1 at gjunka.com (Grzegorz Junka)
Date: Mon, 06 Apr 2009 10:12:37 +0100
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>
Message-ID: <49D9C785.7030104@gjunka.com>

I have just a general comment. I think that keeping Erector as easily 
installable in Rails as possible should be the priority. I don't know 
how often Erector is used outside of Rails but I guess that Rails is 
still the driving horse for Erector. Newcomers to Rails or Erector 
should just be able to issue one command, eventually add one line to a 
configuration file, and start using it without any issues. I think that 
HAML could serve here as a good example. So whatever you decide to do 
with the integration between Erector and Rails, please don't throw out 
the baby with the bath water ;-)
 - Greg

Brian Takita wrote:
> Thank you Kristian. We are in the process of deciding what to do
> regarding packaging Erector and Rails integration.
> Would everybody else like to chime in on this?
>
> On Sun, Apr 5, 2009 at 11:30 PM, kristian <m.kristian at web.de> wrote:
>   
>> just thinking about it again. maybe things become a bit cleaner and
>> worth considering it if there are two gems:
>> erector
>> erector-rails
>> like you have it with rspecs, rspecs-rails. the latter has the all the
>> rails specific code and would be the right place for a few generators.
>> for example I still look for a nice way to test/spec my widgets, I
>> guess I have to look at the erector test once.
>>
>> regards Kristian
>>
>> On Mon, Apr 6, 2009 at 10:29 AM, kristian <m.kristian at web.de> wrote:
>>     
>>> hello,
>>>
>>> I once had this topic again but it was turned down in favour of the erect tool.
>>>
>>> but I need to get to it again. time passed and the way I use erector
>>> is beyond what the default generator and erect are doing.
>>>
>>> the best is to have a look at my personal sandbox
>>> http://github.com/mkristian/kristians_rails_plugins/tree/e41ee0ef959c5837ee3d257c41d4ee4a0ab1233a/erector_widgets
>>>
>>> why I think an erector generator is better than the combination rails
>>> default generator + erect:
>>> * rerun the generator allows to identify modified files, you can have
>>> look at the diff and decide whether you want to overwrite them or not.
>>> with
>>>  rails default generator + erect you do not get that feature
>>> * erector is more elegant then just replacing erb files with erector widgets
>>>
>>> the above generator uses datamapper instead of activerecord that is
>>> why things like the error messages are a bit strange. anyways what I
>>> do here is to offer two base widgets for displaying data models. for
>>> each restful resource I have 4 view files: new.rb, show.rb, edit.rb
>>> and index.rb. the first three reuse the MyModelWidget and the index.rb
>>> uses MyModelsWidget (the list of model entities). with this all four
>>> files are very small and on top you can use the MyModel(s)Widgets at
>>> other places where needed. so basically using a composite pattern to
>>> setup the views.
>>>
>>> so in my opinion this would help to show the potential which lies in
>>> erector. since the above is my personal sandbox is carries some extras
>>> which is not needed for a public, but if you guys change your opinion
>>> about erector generators I can provide them. if you do not like my
>>> approach that is also OK for me since I am using erector all over the
>>> place and I am about to migrate even two more small projects to use
>>> erector (most probably using my generators and regenerate some code
>>> with it)
>>>
>>> with regards Kristian
>>>
>>>       
>>
>> --
>> Kristian Meier + Saumya Sharma + Sanuka Meier
>> Vadakkethu House,
>> Edayanmula West PO - 689532,
>> Pathanamthitta District, Kerala, INDIA
>>
>> tel: +91 468 2319577
>>
>> protect your privacy while searching the net: www.ixquick.com
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>>
>>     
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>
>   


From thewoolleyman at gmail.com  Mon Apr  6 12:47:46 2009
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 6 Apr 2009 09:47:46 -0700
Subject: [Erector-devel] pivotal-erector gem being built on github
In-Reply-To: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>
References: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>
Message-ID: <e3af97510904060947w348a5b8n9cc7e602ea51d47d@mail.gmail.com>

On Mon, Apr 6, 2009 at 12:13 AM, Brian Takita <brian.takita at gmail.com> wrote:
> FYI, I got pivotal-erector being built on EY. Currently, version 0.5.1
> is released.

EY?  Do you mean github?

> I removed the hoe task from the Rakefile, which would break the
> deployment to Rubyforge, I presume.

Why would this break deployment to rubyforge?  If used properly, Hoe
maintains a manifest, creates, and uploads gem, release notes, etc to
Rubyforge.

> I'm not sure what our Rubyforge strategy would be, but I know that I
> have not been able to successfully deploy Erector there due to
> permission issues.

There are two separate issues - uploading the gem, and uploading the
docs.  Even if there are permission issues with the automatic gem
upload via hoe, any project admin can always manually upload the .gem
file via the RubyForge admin "Files" interface.

Uploading the docs is different, and requires that you have
permissions to SCP files up to the RF account.  I think that does
break down sometimes if you don't always use the same ID.

> We have two options here:
> 1. Get permissions working on Rubyforge so multiple core team members
> can deploy a new version of Erector

Sharing an ID may be the only way to do that reliably, or open a
RubyForge ticket and find out the exact steps to make it reliable.

> 2. Have the Erector site on Github

That seems like the best solution to me.  You would have to convert
the current site into README.markdown, but this shouldn't be a big
deal.  If you want multiple pages, you can even have multiple
*.markdown pages, github should render them.  Then you can just
replace the Rubyforge page with a redirect to the github project
homepage.

This has several benefits - the docs are managed via git with all that
implies, automatically "published" upon checking, etc.

-- Chad

P.S. You should also set the default reply-to to be the list instead
of sender.  I know Alex disagrees with this, but he is wrong.
Anything else results in fragmented discussions, and people can
filter/opt out if they don't want to participate in discussions.

From kingdon at panix.com  Mon Apr  6 22:08:02 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Mon,  6 Apr 2009 22:08:02 -0400 (EDT)
Subject: [Erector-devel] pivotal-erector gem being built on github
In-Reply-To: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>
	(message from Brian Takita on Mon, 6 Apr 2009 00:13:08 -0700)
References: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>
Message-ID: <20090407020802.436332429B@panix5.panix.com>

> 1. Get permissions working on Rubyforge so multiple core team members
> can deploy a new version of Erector

As far as I know, I fixed this with commit
82d3394b0ae62ff99584be7d38cb2649cca994a2
Set rsync args so rsyncing to rubyforge will work
2008-12-16

Have you tried since then?

From alex at pivotallabs.com  Tue Apr  7 14:09:42 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 7 Apr 2009 11:09:42 -0700
Subject: [Erector-devel] pivotal-erector gem being built on github
In-Reply-To: <e3af97510904060947w348a5b8n9cc7e602ea51d47d@mail.gmail.com>
References: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com> 
	<e3af97510904060947w348a5b8n9cc7e602ea51d47d@mail.gmail.com>
Message-ID: <7a93bd340904071109y5e8e0029n31c1c2cc7d3db6c2@mail.gmail.com>

> You would have to convert
the current site into README.markdown, but this shouldn't be a big
deal.

Yes it should. There's lots of fancy stuff in the current site,
including a generated nav bar and tables and stuff.

Rubyforge has a permissions problem, but we know how to get around it.
If it's still failing even with Jim's change, let me know and I'll go
click the magic button that resets all permissions on the next cron
sweep.

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com



On Mon, Apr 6, 2009 at 9:47 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Mon, Apr 6, 2009 at 12:13 AM, Brian Takita <brian.takita at gmail.com> wrote:
>> FYI, I got pivotal-erector being built on EY. Currently, version 0.5.1
>> is released.
>
> EY? ?Do you mean github?
>
>> I removed the hoe task from the Rakefile, which would break the
>> deployment to Rubyforge, I presume.
>
> Why would this break deployment to rubyforge? ?If used properly, Hoe
> maintains a manifest, creates, and uploads gem, release notes, etc to
> Rubyforge.
>
>> I'm not sure what our Rubyforge strategy would be, but I know that I
>> have not been able to successfully deploy Erector there due to
>> permission issues.
>
> There are two separate issues - uploading the gem, and uploading the
> docs. ?Even if there are permission issues with the automatic gem
> upload via hoe, any project admin can always manually upload the .gem
> file via the RubyForge admin "Files" interface.
>
> Uploading the docs is different, and requires that you have
> permissions to SCP files up to the RF account. ?I think that does
> break down sometimes if you don't always use the same ID.
>
>> We have two options here:
>> 1. Get permissions working on Rubyforge so multiple core team members
>> can deploy a new version of Erector
>
> Sharing an ID may be the only way to do that reliably, or open a
> RubyForge ticket and find out the exact steps to make it reliable.
>
>> 2. Have the Erector site on Github
>
> That seems like the best solution to me. ?You would have to convert
> the current site into README.markdown, but this shouldn't be a big
> deal. ?If you want multiple pages, you can even have multiple
> *.markdown pages, github should render them. ?Then you can just
> replace the Rubyforge page with a redirect to the github project
> homepage.
>
> This has several benefits - the docs are managed via git with all that
> implies, automatically "published" upon checking, etc.
>
> -- Chad
>
> P.S. You should also set the default reply-to to be the list instead
> of sender. ?I know Alex disagrees with this, but he is wrong.
> Anything else results in fragmented discussions, and people can
> filter/opt out if they don't want to participate in discussions.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From alex at pivotallabs.com  Tue Apr  7 21:25:31 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 7 Apr 2009 18:25:31 -0700
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <49D9C785.7030104@gjunka.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com> 
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com> 
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com> 
	<49D9C785.7030104@gjunka.com>
Message-ID: <7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>

A couple of points:

* I am strongly *against* splitting Erector into two gems. As I said a few
days ago: "My opinion on this is that it doesn't hurt to check out code that you
don't need and never require, but it hurts a lot to have two projects
with potentially diverging version numbers and mutual support
matrices. So I'd like to keep rails support in the main library,
inside a subdirectory &c where it doesn't hurt anybody who doesn't use
it."

* Generators make me feel kind of weird -- generated code can get
stale fast, much faster than library code that sits behind a clean API
-- but given that Rails already uses it I suppose I can't complain if
someone writes an Erector scaffold generator. When I wrote 'erect' I
thought I could make it work well enough that you could just run it on
Rails-generated RHTML but right now you need to do a lot of cleanup
after you run it, maybe too much to make it a recommendable option.
Even in a perfect world you'd have to do some cleanup.

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

From thewoolleyman at gmail.com  Wed Apr  8 00:36:15 2009
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 7 Apr 2009 21:36:15 -0700
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com> 
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com> 
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com> 
	<49D9C785.7030104@gjunka.com>
	<7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
Message-ID: <e3af97510904072136s14b85eb0p4213b772244673ca@mail.gmail.com>

On Tue, Apr 7, 2009 at 6:25 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> A couple of points:
>
> * I am strongly *against* splitting Erector into two gems. As I said a few
> days ago: "My opinion on this is that it doesn't hurt to check out code that you
> don't need and never require, but it hurts a lot to have two projects
> with potentially diverging version numbers and mutual support
> matrices. So I'd like to keep rails support in the main library,
> inside a subdirectory &c where it doesn't hurt anybody who doesn't use
> it."

+1 for one gem.

Multiple gems causes confusion and duplicated effort.  Stick with one
gem until there is a real pain and motivator to do otherwise (i.e.
people complaining with real problems for which there is no good
workaround).

-- Chad

From m.kristian at web.de  Wed Apr  8 07:54:27 2009
From: m.kristian at web.de (kristian)
Date: Wed, 8 Apr 2009 17:24:27 +0530
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>
	<49D9C785.7030104@gjunka.com>
	<7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
Message-ID: <932801940904080454w43ee6895jb4c5a573a7fff3b2@mail.gmail.com>

hello,

just a two more points from a eretor user:

* I do not care whether there are 2 gems or only one from a user point
of view, if there are strongs feelings against two, than stick with
one.

* the generators: if you have look at my generators than you could see
parts of the extracted in the lib of the gem. and from a rails point
of view, people know how to use generators, the erect tool I never
used and will probably never use. to see how erector works the fasted
way is to scaffold a resource and have a look at the generated code.
that's one of magic of rails and that is how rails got me in the first
place that I quickly scaffold an application and do the polishing of
GUI later. so generator for me is also a marketing tool so to say. but
if you guys have too strong feelings against a generator, just forget
this email thread. it is of no importants to me since I have my
generators and use them and even use them to add extra properties in a
later state and it works at least for me.

with regards
Kristian



On Wed, Apr 8, 2009 at 6:55 AM, Alex Chaffee <alex at pivotallabs.com> wrote:
> A couple of points:
>
> * I am strongly *against* splitting Erector into two gems. As I said a few
> days ago: "My opinion on this is that it doesn't hurt to check out code that you
> don't need and never require, but it hurts a lot to have two projects
> with potentially diverging version numbers and mutual support
> matrices. So I'd like to keep rails support in the main library,
> inside a subdirectory &c where it doesn't hurt anybody who doesn't use
> it."
>
> * Generators make me feel kind of weird -- generated code can get
> stale fast, much faster than library code that sits behind a clean API
> -- but given that Rails already uses it I suppose I can't complain if
> someone writes an Erector scaffold generator. When I wrote 'erect' I
> thought I could make it work well enough that you could just run it on
> Rails-generated RHTML but right now you need to do a lot of cleanup
> after you run it, maybe too much to make it a recommendable option.
> Even in a perfect world you'd have to do some cleanup.
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

From brian.takita at gmail.com  Wed Apr  8 23:57:02 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 8 Apr 2009 20:57:02 -0700
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>
	<49D9C785.7030104@gjunka.com>
	<7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
Message-ID: <1d7ddd110904082057n4a300b29ra10b9221482e1022@mail.gmail.com>

On Tue, Apr 7, 2009 at 6:25 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> A couple of points:
>
> * I am strongly *against* splitting Erector into two gems. As I said a few
> days ago: "My opinion on this is that it doesn't hurt to check out code that you
> don't need and never require, but it hurts a lot to have two projects
> with potentially diverging version numbers and mutual support
> matrices. So I'd like to keep rails support in the main library,
> inside a subdirectory &c where it doesn't hurt anybody who doesn't use
> it."
I think multiple gems worth considering.
One big problem with supporting multiple versions of Rails is there
are multiple definitions of the same method, due to how difficult it
is to integrate with Rails.

I really like Jeff's idea with only supporting one version of Rails in
the main Erector gem.

I would like to submit the idea of having a n (including one)
additional Erector gems to support backward compatibility.

Another idea is to encourage users to fork Erector for the version of
Rails they are trying to support.
Hopefully, Erector's codebase can be further simplified and be easy to
understand with good extension points.

I can start different forks of Erector which I will infrequently merge
with master. The beauty of Git is, if somebody really cares about
being up-to-date, they can create a fork off of their fork of choice.
It is then easy to merge in changes with the master branch in the
pivotal/erector project.

To me, the fork idea is the more compelling one.
>
> * Generators make me feel kind of weird -- generated code can get
> stale fast, much faster than library code that sits behind a clean API
> -- but given that Rails already uses it I suppose I can't complain if
> someone writes an Erector scaffold generator. When I wrote 'erect' I
> thought I could make it work well enough that you could just run it on
> Rails-generated RHTML but right now you need to do a lot of cleanup
> after you run it, maybe too much to make it a recommendable option.
> Even in a perfect world you'd have to do some cleanup.
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
>

From brian.takita at gmail.com  Wed Apr  8 23:58:25 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 8 Apr 2009 20:58:25 -0700
Subject: [Erector-devel] rails generators (the second)
In-Reply-To: <1d7ddd110904082057n4a300b29ra10b9221482e1022@mail.gmail.com>
References: <932801940904052159t3d0e448dp9d98b27947ee6c49@mail.gmail.com>
	<932801940904052330q58cdcfb8m48cfea553118039@mail.gmail.com>
	<1d7ddd110904060016k3dd9ad79ic0b493f0d6386422@mail.gmail.com>
	<49D9C785.7030104@gjunka.com>
	<7a93bd340904071825y417f100cm54c3ef664cb73940@mail.gmail.com>
	<1d7ddd110904082057n4a300b29ra10b9221482e1022@mail.gmail.com>
Message-ID: <1d7ddd110904082058p1c94a604v9c1a545bf636417a@mail.gmail.com>

On Wed, Apr 8, 2009 at 8:57 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Tue, Apr 7, 2009 at 6:25 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> A couple of points:
>>
>> * I am strongly *against* splitting Erector into two gems. As I said a few
>> days ago: "My opinion on this is that it doesn't hurt to check out code that you
>> don't need and never require, but it hurts a lot to have two projects
>> with potentially diverging version numbers and mutual support
>> matrices. So I'd like to keep rails support in the main library,
>> inside a subdirectory &c where it doesn't hurt anybody who doesn't use
>> it."
> I think multiple gems worth considering.
> One big problem with supporting multiple versions of Rails is there
> are multiple definitions of the same method, due to how difficult it
> is to integrate with Rails.
>
> I really like Jeff's idea with only supporting one version of Rails in
> the main Erector gem.
>
> I would like to submit the idea of having a n (including one)
> additional Erector gems to support backward compatibility.
>
> Another idea is to encourage users to fork Erector for the version of
> Rails they are trying to support.
> Hopefully, Erector's codebase can be further simplified and be easy to
> understand with good extension points.
>
> I can start different forks of Erector which I will infrequently merge
> with master. The beauty of Git is, if somebody really cares about
> being up-to-date, they can create a fork off of their fork of choice.
> It is then easy to merge in changes with the master branch in the
> pivotal/erector project.
In fact, the merge process can be automated as part of the Erector CI build.
If there is a merge conflict, the build fails.
>
> To me, the fork idea is the more compelling one.
>>
>> * Generators make me feel kind of weird -- generated code can get
>> stale fast, much faster than library code that sits behind a clean API
>> -- but given that Rails already uses it I suppose I can't complain if
>> someone writes an Erector scaffold generator. When I wrote 'erect' I
>> thought I could make it work well enough that you could just run it on
>> Rails-generated RHTML but right now you need to do a lot of cleanup
>> after you run it, maybe too much to make it a recommendable option.
>> Even in a perfect world you'd have to do some cleanup.
>>
>> ---
>> Alex Chaffee - alex at stinky.com
>> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
>> http://alexch.tumblr.com
>>
>

From brian.takita at gmail.com  Thu Apr  9 02:24:52 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 8 Apr 2009 23:24:52 -0700
Subject: [Erector-devel] rails branch
Message-ID: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>

I created a Rails branch. The first thing I did was create a
RailsWidget, which is meant to support Rails.

I will also base the Rails version branches off of this branch for now.

If everybody likes these patterns, they can be merged into master.

From brian.takita at gmail.com  Thu Apr  9 02:26:30 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 8 Apr 2009 23:26:30 -0700
Subject: [Erector-devel] rails branch
In-Reply-To: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
Message-ID: <1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>

I also pushed the rails-2-3-2 branch. The purpose of this branch is to
only support Rails 2.3.2.

On Wed, Apr 8, 2009 at 11:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
> I created a Rails branch. The first thing I did was create a
> RailsWidget, which is meant to support Rails.
>
> I will also base the Rails version branches off of this branch for now.
>
> If everybody likes these patterns, they can be merged into master.
>

From brian.takita at gmail.com  Thu Apr  9 02:27:29 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 8 Apr 2009 23:27:29 -0700
Subject: [Erector-devel] rails branch
In-Reply-To: <1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
	<1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
Message-ID: <1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>

On Wed, Apr 8, 2009 at 11:26 PM, Brian Takita <brian.takita at gmail.com> wrote:
> I also pushed the rails-2-3-2 branch. The purpose of this branch is to
> only support Rails 2.3.2.
More precisely, this branch is Erector with bundled support for Rails 2.3.2.
>
> On Wed, Apr 8, 2009 at 11:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> I created a Rails branch. The first thing I did was create a
>> RailsWidget, which is meant to support Rails.
>>
>> I will also base the Rails version branches off of this branch for now.
>>
>> If everybody likes these patterns, they can be merged into master.
>>
>

From brian.takita at gmail.com  Sun Apr 12 13:34:00 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 12 Apr 2009 10:34:00 -0700
Subject: [Erector-devel] rails branch
In-Reply-To: <1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
	<1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
	<1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>
Message-ID: <1d7ddd110904121034k5dada36eye9156bcc2178e589@mail.gmail.com>

I went ahead and created a branch for each supported version of Rails.

They are as follows:
rails -> Erector supporting the latest version of Rails
rails-2-0-0 -> Erector supporting the Rails 2.0.0
rails-2-1-0 -> Erector supporting the Rails 2.1.0
rails-2-2-0 -> Erector supporting the Rails 2.2.0
rails-2-2-2 -> Erector supporting the Rails 2.2.2

I propose that we merge the rails branch into master and base the
("erector" and/or "pivotal-erector") gem off of that version of
Erector.

We can then create a github fork for each version of Erector
supporting a version of Rails. For example the gems would have the
following names,
pivotal-erector-rails-2-0-0
pivotal-erector-rails-2-1-0
pivotal-erector-rails-2-2-0
pivotal-erector-rails-2-2-2

These gems will be a full version of Erector and kept "in sync" with
the main Erector project using git merges.

I don't expect to be frequently syncing the
pivotal-erector-rails-x-x-x gems. If an end-user needs a merge, he/she
can create a fork of the appropriate repo and submit a pull request.
If nobody cares about these forks, they can be ignored.

The nice thing is that removing the branch logic to support a
particular version of Rails is removed, while still maintaining
compatibility with multiple versions of Rails.

WDYT?

On Wed, Apr 8, 2009 at 11:27 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Wed, Apr 8, 2009 at 11:26 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> I also pushed the rails-2-3-2 branch. The purpose of this branch is to
>> only support Rails 2.3.2.
> More precisely, this branch is Erector with bundled support for Rails 2.3.2.
>>
>> On Wed, Apr 8, 2009 at 11:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
>>> I created a Rails branch. The first thing I did was create a
>>> RailsWidget, which is meant to support Rails.
>>>
>>> I will also base the Rails version branches off of this branch for now.
>>>
>>> If everybody likes these patterns, they can be merged into master.
>>>
>>
>

From brian.takita at gmail.com  Mon Apr 13 01:55:19 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 12 Apr 2009 22:55:19 -0700
Subject: [Erector-devel] pivotal-erector gem being built on github
In-Reply-To: <7a93bd340904071109y5e8e0029n31c1c2cc7d3db6c2@mail.gmail.com>
References: <1d7ddd110904060013v7604516dx7fd8e9587b42639a@mail.gmail.com>
	<e3af97510904060947w348a5b8n9cc7e602ea51d47d@mail.gmail.com>
	<7a93bd340904071109y5e8e0029n31c1c2cc7d3db6c2@mail.gmail.com>
Message-ID: <1d7ddd110904122255k10183de3p1449cba03aab607e@mail.gmail.com>

On Tue, Apr 7, 2009 at 11:09 AM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> You would have to convert
> the current site into README.markdown, but this shouldn't be a big
> deal.
>
> Yes it should. There's lots of fancy stuff in the current site,
> including a generated nav bar and tables and stuff.
>
> Rubyforge has a permissions problem, but we know how to get around it.
> If it's still failing even with Jim's change, let me know and I'll go
> click the magic button that resets all permissions on the next cron
> sweep.
I re-added the Hoe definition into the master branch. This means the
publish tasks should work again.

If we were to use Jeweler to create the gem for us, what would we
still need hoex for?
So far, I know about the publish and publish_website rake tasks.
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
>
>
>
> On Mon, Apr 6, 2009 at 9:47 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> On Mon, Apr 6, 2009 at 12:13 AM, Brian Takita <brian.takita at gmail.com> wrote:
>>> FYI, I got pivotal-erector being built on EY. Currently, version 0.5.1
>>> is released.
>>
>> EY? ?Do you mean github?
>>
>>> I removed the hoe task from the Rakefile, which would break the
>>> deployment to Rubyforge, I presume.
>>
>> Why would this break deployment to rubyforge? ?If used properly, Hoe
>> maintains a manifest, creates, and uploads gem, release notes, etc to
>> Rubyforge.
>>
>>> I'm not sure what our Rubyforge strategy would be, but I know that I
>>> have not been able to successfully deploy Erector there due to
>>> permission issues.
>>
>> There are two separate issues - uploading the gem, and uploading the
>> docs. ?Even if there are permission issues with the automatic gem
>> upload via hoe, any project admin can always manually upload the .gem
>> file via the RubyForge admin "Files" interface.
>>
>> Uploading the docs is different, and requires that you have
>> permissions to SCP files up to the RF account. ?I think that does
>> break down sometimes if you don't always use the same ID.
>>
>>> We have two options here:
>>> 1. Get permissions working on Rubyforge so multiple core team members
>>> can deploy a new version of Erector
>>
>> Sharing an ID may be the only way to do that reliably, or open a
>> RubyForge ticket and find out the exact steps to make it reliable.
>>
>>> 2. Have the Erector site on Github
>>
>> That seems like the best solution to me. ?You would have to convert
>> the current site into README.markdown, but this shouldn't be a big
>> deal. ?If you want multiple pages, you can even have multiple
>> *.markdown pages, github should render them. ?Then you can just
>> replace the Rubyforge page with a redirect to the github project
>> homepage.
>>
>> This has several benefits - the docs are managed via git with all that
>> implies, automatically "published" upon checking, etc.
>>
>> -- Chad
>>
>> P.S. You should also set the default reply-to to be the list instead
>> of sender. ?I know Alex disagrees with this, but he is wrong.
>> Anything else results in fragmented discussions, and people can
>> filter/opt out if they don't want to participate in discussions.
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>>
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From brian.takita at gmail.com  Mon Apr 13 13:16:21 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 13 Apr 2009 10:16:21 -0700
Subject: [Erector-devel] rails branch
In-Reply-To: <1d7ddd110904121034k5dada36eye9156bcc2178e589@mail.gmail.com>
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
	<1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
	<1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>
	<1d7ddd110904121034k5dada36eye9156bcc2178e589@mail.gmail.com>
Message-ID: <1d7ddd110904131016j2b7017c0u3511cf1b6263da5e@mail.gmail.com>

No objections? You guys are making this too easy :-)

On Sun, Apr 12, 2009 at 10:34 AM, Brian Takita <brian.takita at gmail.com> wrote:
> I went ahead and created a branch for each supported version of Rails.
>
> They are as follows:
> rails -> Erector supporting the latest version of Rails
> rails-2-0-0 -> Erector supporting the Rails 2.0.0
> rails-2-1-0 -> Erector supporting the Rails 2.1.0
> rails-2-2-0 -> Erector supporting the Rails 2.2.0
> rails-2-2-2 -> Erector supporting the Rails 2.2.2
>
> I propose that we merge the rails branch into master and base the
> ("erector" and/or "pivotal-erector") gem off of that version of
> Erector.
>
> We can then create a github fork for each version of Erector
> supporting a version of Rails. For example the gems would have the
> following names,
> pivotal-erector-rails-2-0-0
> pivotal-erector-rails-2-1-0
> pivotal-erector-rails-2-2-0
> pivotal-erector-rails-2-2-2
>
> These gems will be a full version of Erector and kept "in sync" with
> the main Erector project using git merges.
>
> I don't expect to be frequently syncing the
> pivotal-erector-rails-x-x-x gems. If an end-user needs a merge, he/she
> can create a fork of the appropriate repo and submit a pull request.
> If nobody cares about these forks, they can be ignored.
>
> The nice thing is that removing the branch logic to support a
> particular version of Rails is removed, while still maintaining
> compatibility with multiple versions of Rails.
>
> WDYT?
>
> On Wed, Apr 8, 2009 at 11:27 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> On Wed, Apr 8, 2009 at 11:26 PM, Brian Takita <brian.takita at gmail.com> wrote:
>>> I also pushed the rails-2-3-2 branch. The purpose of this branch is to
>>> only support Rails 2.3.2.
>> More precisely, this branch is Erector with bundled support for Rails 2.3.2.
>>>
>>> On Wed, Apr 8, 2009 at 11:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
>>>> I created a Rails branch. The first thing I did was create a
>>>> RailsWidget, which is meant to support Rails.
>>>>
>>>> I will also base the Rails version branches off of this branch for now.
>>>>
>>>> If everybody likes these patterns, they can be merged into master.
>>>>
>>>
>>
>

From kingdon at panix.com  Tue Apr 14 06:32:58 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Tue, 14 Apr 2009 06:32:58 -0400 (EDT)
Subject: [Erector-devel] rails branch
In-Reply-To: <1d7ddd110904131016j2b7017c0u3511cf1b6263da5e@mail.gmail.com>
	(message from Brian Takita on Mon, 13 Apr 2009 10:16:21 -0700)
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
	<1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
	<1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>
	<1d7ddd110904121034k5dada36eye9156bcc2178e589@mail.gmail.com>
	<1d7ddd110904131016j2b7017c0u3511cf1b6263da5e@mail.gmail.com>
Message-ID: <20090414103258.8549F242A6@panix5.panix.com>

> No objections? You guys are making this too easy :-)

Well, I'm not doing much with erector these days (in large part due to
being busy with my current job).

With your proposal, I suppose most people on the non-latest rails
would just use an old version of erector (rather than bothering with
merging), but I'm not sure that's a bad thing.

I wouldn't normally think branches are a particularly good way to
handle multiple versions of something, but given how different the
different rails versions are (in terms of how erector hooks in),
perhaps it makes sense here.

From brian.takita at gmail.com  Sat Apr 18 17:37:21 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 18 Apr 2009 14:37:21 -0700
Subject: [Erector-devel] Github Pages
Message-ID: <1d7ddd110904181437g451f6541kc07d8a39eb56e21a@mail.gmail.com>

I propose that we create an Erector github project and use Github
Pages (http://erector.github.com) instead of using Rubyforge.
Their usage of Git to update the site is pretty slick. It would also
be much easier to administer than Rubyforge.

From alex at pivotallabs.com  Sat Apr 18 18:00:45 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 18 Apr 2009 15:00:45 -0700
Subject: [Erector-devel] Github Pages
In-Reply-To: <1d7ddd110904181437g451f6541kc07d8a39eb56e21a@mail.gmail.com>
References: <1d7ddd110904181437g451f6541kc07d8a39eb56e21a@mail.gmail.com>
Message-ID: <7a93bd340904181500s7454e902l9f5d2e26b3d6d856@mail.gmail.com>

Can we keep using the existing documentation page objects (which are
written in Erector and output HTML)? There's some logic in there for
generating the navigation and faq index and stuff.

I see something about Jekyll at http://pages.github.com/ but I don't
really understand it yet.

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com



On Sat, Apr 18, 2009 at 2:37 PM, Brian Takita <brian.takita at gmail.com> wrote:
> I propose that we create an Erector github project and use Github
> Pages (http://erector.github.com) instead of using Rubyforge.
> Their usage of Git to update the site is pretty slick. It would also
> be much easier to administer than Rubyforge.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From brian.takita at gmail.com  Sun Apr 19 16:41:53 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 19 Apr 2009 13:41:53 -0700
Subject: [Erector-devel] Github Pages
In-Reply-To: <7a93bd340904181500s7454e902l9f5d2e26b3d6d856@mail.gmail.com>
References: <1d7ddd110904181437g451f6541kc07d8a39eb56e21a@mail.gmail.com>
	<7a93bd340904181500s7454e902l9f5d2e26b3d6d856@mail.gmail.com>
Message-ID: <1d7ddd110904191341q2e12690p3c3deea5ff977844@mail.gmail.com>

On Sat, Apr 18, 2009 at 3:00 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> Can we keep using the existing documentation page objects (which are
> written in Erector and output HTML)? There's some logic in there for
> generating the navigation and faq index and stuff.
I don't see why not. It would require that the generated files go into
the erector.github.com project.
Perhaps we can use submodules or a clone that we manage (like rails)
in the erector project?
>
> I see something about Jekyll at http://pages.github.com/ but I don't
> really understand it yet.
I think Jekyll is a template system that enables the generation of
html files (like what you already did for Erector).
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
>
>
>
> On Sat, Apr 18, 2009 at 2:37 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> I propose that we create an Erector github project and use Github
>> Pages (http://erector.github.com) instead of using Rubyforge.
>> Their usage of Git to update the site is pretty slick. It would also
>> be much easier to administer than Rubyforge.
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>>
>

From alex at pivotallabs.com  Mon Apr 20 22:21:29 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Mon, 20 Apr 2009 19:21:29 -0700
Subject: [Erector-devel] API Cleanup
Message-ID: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>

Inspired by GoGaRuCo, I just took a shot at rewriting the API. The
basic concept is
to clarify the lifecycle of a widget, so "new" accepts permanent state
(like "assigns"
variables) and "to_s" accepts temporary, rendering state (output
stream, helpers,
prettyprinting). This lets you do things like make collections of
widgets in once place
in your code and render them in another place, and basically establish
a more coherent
API than the 8 different ways I've seen people doing nested widgets
(or, more likely,
avoiding nesting them cause it's too confusing.)

I also renamed "render" to "write", which removes confusion/ambiguity
with Rails' "render" method and concept, and also allows "render
:partial" to be made
to work (though I haven't done that yet). Separating the two types of
state also allowed
me to unify a few concepts and remove some code, especially around
prettyprinting.
(I also fixed a couple of bugs along the way.)

When we're outside a widget, the pattern is:

  w = DateWidget.new(:when => Time.now, :title => "Nap Time")
  puts w.to_s(:helpers => some_rails_view)

When we're inside a widget we have a few more options. All of these ways inherit
the rendering state from the parent widget if possible (like output,
helpers, and
indent level) and emit text onto the same stream for better performance.

(1)
      w = DateWidget.new(:when => Time.now, :title => "Nap Time")
      w.write_via(self)

(2)
      widget DateWidget, :when => Time.now, :title => "Nap Time"

(3)
      w = DateWidget.new(:when => Time.now, :title => "Nap Time")
      widget w

(3b)
      widget DateWidget.new(:when => Time.now, :title => "Nap Time")

((3) and (3b) are the same but I thought I'd show how it looks when
you inline it.)

So what does everyone think? I think it might be too much to support
both "widget"
and "write_via", but since one actually calls the other under the
hood, it's not
too big a commitment to keep them both around in the public API. I'm
not in love with
the new names, either; other possibilites are "emit" instead of render and ""

I've done these in a fork on GitHub (my first!). Please check it out
and tell me what you think.

GitHub seems to be stale right now but maybe later it'll be visible at
http://github.com/alexch/erector/tree/master
or maybe
http://github.com/alexch/erector/tree/api-cleanup
or you can clone it with
git://github.com/alexch/erector.git

Once we agree that it's a righteous change, I figure we will carefully
pull it into
the main repo and increment the minor version number and make a good
HOWTO so people
aren't taken off guard when their code breaks. I've put in what I hope are good
deprecation warnings too (that actually give suggestions and say which class
needs to be fixed).

Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
getting it
into the various Rails branches. And I don't really understand the
plan for render_partial.
Shouldn't calling render_partial on a widget just call render (now
"write") on that widget?
Why do we need/want a separate method called render_partial on the widget?

 - A

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

From alex at pivotallabs.com  Mon Apr 20 22:23:01 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Mon, 20 Apr 2009 19:23:01 -0700
Subject: [Erector-devel] little tidbits I noticed while frolicking through
	the code
Message-ID: <7a93bd340904201923s9822c6bs900595334df88214@mail.gmail.com>

Widget#inspect just calls to_s. Is this useful? Do we want some other
debugging info to appear instead?

Widget#join -- is anyone using this? Also the rdoc says it works on
"strings, which are quoted and output"
-- but this is not really true, right? They're not quoted, just
html-escaped like any text.

Widget#after_initialize -- is anyone using this feature? It's not tested.


---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

From kingdon at panix.com  Mon Apr 20 23:15:26 2009
From: kingdon at panix.com (Jim Kingdon)
Date: Mon, 20 Apr 2009 23:15:26 -0400 (EDT)
Subject: [Erector-devel] little tidbits I noticed while frolicking
	through	the code
In-Reply-To: <7a93bd340904201923s9822c6bs900595334df88214@mail.gmail.com>
	(message from Alex Chaffee on Mon, 20 Apr 2009 19:23:01 -0700)
References: <7a93bd340904201923s9822c6bs900595334df88214@mail.gmail.com>
Message-ID: <20090421031526.422D2242B0@panix5.panix.com>

> Widget#join -- is anyone using this?

The motivator was in a project which switched to HAML anyway, so I
don't know if there is production code using it, but how else would
you handle this use case?  examples/join-with-dummy-array.rb was my
second-best attempt, and it turns out pretty ugly.  examples/join.rb
is the same thing using Widget#join

> Also the rdoc says it works on "strings, which are quoted and output"
> -- but this is not really true, right? They're not quoted, just
> html-escaped like any text.

I guess the word "quoted" should be changed to "html-escaped".  That's
what "quoted" was supposed to mean here, but evidently that wasn't
clear.

From m.kristian at web.de  Tue Apr 21 00:42:26 2009
From: m.kristian at web.de (kristian)
Date: Mon, 20 Apr 2009 21:42:26 -0700
Subject: [Erector-devel] rails branch
In-Reply-To: <af9ce6c90904140902s13a4e2fcq1ef49304790c5c5b@mail.gmail.com>
References: <1d7ddd110904082324y583260b6yebd3462778b82236@mail.gmail.com>
	<1d7ddd110904082326s58ff54c1o44bbbdb904475d14@mail.gmail.com>
	<1d7ddd110904082327h52538552h3ab91781a2db8233@mail.gmail.com>
	<1d7ddd110904121034k5dada36eye9156bcc2178e589@mail.gmail.com>
	<af9ce6c90904140902s13a4e2fcq1ef49304790c5c5b@mail.gmail.com>
Message-ID: <932801940904202142u3c500486te90daea092a2f987@mail.gmail.com>

I think that sounds good for me (as erector user) and with rails 3.0
there will be a clean and stable API for the template engines. so
there is a chance that these branches are a temporary setup.

with metta
Kristian

On 4/14/09, Mike Grafton <mike at pivotallabs.com> wrote:
> +1
>
> As Jim said, I suspect changes on the branches for the older versions of
> Rails will be infrequent enough that merging won't be a problem.  And I
> wouldn't bother with the extra forks until we have a demonstrated need for
> building older gems.
>
> Mike
>
>
> On Sun, Apr 12, 2009 at 10:34 AM, Brian Takita <brian.takita at gmail.com>
> wrote:
> > I went ahead and created a branch for each supported version of Rails.
> >
> > They are as follows:
> > rails -> Erector supporting the latest version of Rails
> > rails-2-0-0 -> Erector supporting the Rails 2.0.0
> > rails-2-1-0 -> Erector supporting the Rails 2.1.0
> > rails-2-2-0 -> Erector supporting the Rails 2.2.0
> > rails-2-2-2 -> Erector supporting the Rails 2.2.2
> >
> > I propose that we merge the rails branch into master and base the
> > ("erector" and/or "pivotal-erector") gem off of that version of
> > Erector.
> >
> > We can then create a github fork for each version of Erector
> > supporting a version of Rails. For example the gems would have the
> > following names,
> > pivotal-erector-rails-2-0-0
> > pivotal-erector-rails-2-1-0
> > pivotal-erector-rails-2-2-0
> > pivotal-erector-rails-2-2-2
> >
> > These gems will be a full version of Erector and kept "in sync" with
> > the main Erector project using git merges.
> >
> > I don't expect to be frequently syncing the
> > pivotal-erector-rails-x-x-x gems. If an end-user needs a merge, he/she
> > can create a fork of the appropriate repo and submit a pull request.
> > If nobody cares about these forks, they can be ignored.
> >
> > The nice thing is that removing the branch logic to support a
> > particular version of Rails is removed, while still maintaining
> > compatibility with multiple versions of Rails.
> >
> > WDYT?
> >
> >
> >
> >
> > On Wed, Apr 8, 2009 at 11:27 PM, Brian Takita <brian.takita at gmail.com>
> wrote:
> > > On Wed, Apr 8, 2009 at 11:26 PM, Brian Takita <brian.takita at gmail.com>
> wrote:
> > >> I also pushed the rails-2-3-2 branch. The purpose of this branch is to
> > >> only support Rails 2.3.2.
> > > More precisely, this branch is Erector with bundled support for Rails
> 2.3.2.
> > >>
> > >> On Wed, Apr 8, 2009 at 11:24 PM, Brian Takita <brian.takita at gmail.com>
> wrote:
> > >>> I created a Rails branch. The first thing I did was create a
> > >>> RailsWidget, which is meant to support Rails.
> > >>>
> > >>> I will also base the Rails version branches off of this branch for
> now.
> > >>>
> > >>> If everybody likes these patterns, they can be merged into master.
> > >>>
> > >>
> > >
> > _______________________________________________
> > Erector-devel mailing list
> > Erector-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/erector-devel
> >
>
>
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>
>


-- 
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

From brian.takita at gmail.com  Tue Apr 21 01:20:49 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Apr 2009 22:20:49 -0700
Subject: [Erector-devel] little tidbits I noticed while frolicking
	through the code
In-Reply-To: <7a93bd340904201923s9822c6bs900595334df88214@mail.gmail.com>
References: <7a93bd340904201923s9822c6bs900595334df88214@mail.gmail.com>
Message-ID: <1d7ddd110904202220u2a37e11bsbb82e46ded9c5cfe@mail.gmail.com>

On Mon, Apr 20, 2009 at 7:23 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> Widget#inspect just calls to_s. Is this useful? Do we want some other
> debugging info to appear instead?
>
> Widget#join -- is anyone using this? Also the rdoc says it works on
> "strings, which are quoted and output"
> -- but this is not really true, right? They're not quoted, just
> html-escaped like any text.
>
> Widget#after_initialize -- is anyone using this feature? It's not tested.
The idea behind this is that the initialize method is important for
the widget to run.
It saves the programmer from having to invoke super in correct
location in #initialize.

AR follows this approach, so I think I assumed that it was a common
(and nice to have) pattern. I'd like to hear if its useful to anybody
else.
I don't use it myself.

I cannot think of why it was not tested. It was probably an oversight
of some sort.
>
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From brian.takita at gmail.com  Tue Apr 21 01:50:07 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Apr 2009 22:50:07 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
Message-ID: <1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>

On Mon, Apr 20, 2009 at 7:21 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> Inspired by GoGaRuCo, I just took a shot at rewriting the API. The
> basic concept is
> to clarify the lifecycle of a widget, so "new" accepts permanent state
> (like "assigns"
> variables) and "to_s" accepts temporary, rendering state (output
> stream, helpers,
> prettyprinting). This lets you do things like make collections of
> widgets in once place
> in your code and render them in another place, and basically establish
> a more coherent
> API than the 8 different ways I've seen people doing nested widgets
> (or, more likely,
> avoiding nesting them cause it's too confusing.)
That sounds good to me. I assume that this means a single widget
object can only be accessed in one thread (which also makes sense to
me).
>
> I also renamed "render" to "write", which removes confusion/ambiguity
I remember complaints that render was a verb and should be a noun instead.
The rationale was Erector has methods for the html tag names instead
of a verb to create the tag (e.g. div, not write_div).
I think I slightly favor this, though I would be swayed by a
compelling argument.

Maybe something like content?
> with Rails' "render" method and concept, and also allows "render
> :partial" to be made
> to work (though I haven't done that yet). Separating the two types of
> state also allowed
> me to unify a few concepts and remove some code, especially around
> prettyprinting.
> (I also fixed a couple of bugs along the way.)
Very nice.
>
> When we're outside a widget, the pattern is:
>
> ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
> ?puts w.to_s(:helpers => some_rails_view)
>
> When we're inside a widget we have a few more options. All of these ways inherit
> the rendering state from the parent widget if possible (like output,
> helpers, and
> indent level) and emit text onto the same stream for better performance.
>
> (1)
> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
> ? ? ?w.write_via(self)
>
> (2)
> ? ? ?widget DateWidget, :when => Time.now, :title => "Nap Time"
>
> (3)
> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
> ? ? ?widget w
>
> (3b)
> ? ? ?widget DateWidget.new(:when => Time.now, :title => "Nap Time")
>
> ((3) and (3b) are the same but I thought I'd show how it looks when
> you inline it.)
>
> So what does everyone think? I think it might be too much to support
> both "widget"
> and "write_via", but since one actually calls the other under the
> hood, it's not
> too big a commitment to keep them both around in the public API. I'm
> not in love with
> the new names, either; other possibilites are "emit" instead of render and ""
I think I favor nouns here because they seem more declarative.
So I would favor 2 & 3 in this case, though there may be a better term
than #widget.
>
> I've done these in a fork on GitHub (my first!). Please check it out
> and tell me what you think.
>
> GitHub seems to be stale right now but maybe later it'll be visible at
> http://github.com/alexch/erector/tree/master
> or maybe
> http://github.com/alexch/erector/tree/api-cleanup
> or you can clone it with
> git://github.com/alexch/erector.git
>
> Once we agree that it's a righteous change, I figure we will carefully
> pull it into
> the main repo and increment the minor version number and make a good
> HOWTO so people
> aren't taken off guard when their code breaks. I've put in what I hope are good
> deprecation warnings too (that actually give suggestions and say which class
> needs to be fixed).
That makes sense, which reminds me I need to do the same thing with
introducing the RailsWidget class.
Did you stick your instructions in the README or in CHANGES?
>
> Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
> getting it
> into the various Rails branches. And I don't really understand the
Sure thing. Do you want me to go over it with you? Perhaps pairing
would be the best way to do this.
> plan for render_partial.
> Shouldn't calling render_partial on a widget just call render (now
> "write") on that widget?
> Why do we need/want a separate method called render_partial on the widget?
Ideally we wouldn't even want to have the concept of partials, since
we have nice things such as Widget objects & modules.
I figured that render_partial was a good analogy to Rails partials and
would hopefully be refactored away.
We could do render, write, or content, etc. with the :partial argument
too, however it seems like that would create more branching logic
inside that method, and more difficult to refactor.
>
> ?- A
>
> ---
> Alex Chaffee - alex at stinky.com
> Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
> http://alexch.tumblr.com
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>

From alex at pivotallabs.com  Tue Apr 21 02:14:48 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Mon, 20 Apr 2009 23:14:48 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
Message-ID: <7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>

> That sounds good to me. I assume that this means a single widget
> object can only be accessed in one thread (which also makes sense to
> me).

Yes, this is still true.

>> I also renamed "render" to "write", which removes confusion/ambiguity
>
> I remember complaints that render was a verb and should be a noun instead.
> The rationale was Erector has methods for the html tag names instead
> of a verb to create the tag (e.g. div, not write_div).
> I think I slightly favor this, though I would be swayed by a
> compelling argument.
>
> Maybe something like content?

"content" is ok, but I wouldn't get too caught up in following the
pattern of the tag methods. This method here is the only one that we
are asking the user to implement, so it's fine -- and maybe even
preferable -- if it's a more traditional method name like a verb.
Also, user code will never call this method directly, so it's not even
going to show up in the nesting of HTML-ish tag words. (That role is
filled by "to_s" and/or "widget" (which is a noun) and/or "write_via"
(which makes me cringe and hopefully can be hidden).)

>> (1)
>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>> ? ? ?w.write_via(self)
>>
>> (2)
>> ? ? ?widget DateWidget, :when => Time.now, :title => "Nap Time"
>>
>> (3)
>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>> ? ? ?widget w
>>
>> (3b)
>> ? ? ?widget DateWidget.new(:when => Time.now, :title => "Nap Time")
>>
>> ((3) and (3b) are the same but I thought I'd show how it looks when
>> you inline it.)
>>
>> So what does everyone think? I think it might be too much to support
>> both "widget"
>> and "write_via", but since one actually calls the other under the
>> hood, it's not
>> too big a commitment to keep them both around in the public API. I'm
>> not in love with
>> the new names, either; other possibilites are "emit" instead of render and ""
>
> I think I favor nouns here because they seem more declarative.
>
> So I would favor 2 & 3 in this case, though there may be a better term
> than #widget.


>> I've done these in a fork on GitHub (my first!). Please check it out
>> and tell me what you think.
>>
>> GitHub seems to be stale right now but maybe later it'll be visible at
>> http://github.com/alexch/erector/tree/master
>> or maybe
>> http://github.com/alexch/erector/tree/api-cleanup
>> or you can clone it with
>> git://github.com/alexch/erector.git

These are working now. I wish GitHub had an indication of how stale it
is; I wasted a lot of time mucking around and wondering why my changes
hadn't gotten pushed (when they actually had and GitHub was over an
hour behind).

> Did you stick your instructions in the README or in CHANGES?

No, I haven't worked on the documentation yet, other than the rdoc comments.

>> Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
>> getting it
>> into the various Rails branches. And I don't really understand the
> Sure thing. Do you want me to go over it with you? Perhaps pairing
> would be the best way to do this.

The code is easy but I'm a git noob so I'm sure I'd screw something up
if I tried it on my own... :-)

>> plan for render_partial.
>> Shouldn't calling render_partial on a widget just call render (now
>> "write") on that widget?
>> Why do we need/want a separate method called render_partial on the widget?
> Ideally we wouldn't even want to have the concept of partials, since
> we have nice things such as Widget objects & modules.
> I figured that render_partial was a good analogy to Rails partials and
> would hopefully be refactored away.

In my apps, the partial is not a method, it's a whole other class --
just like in Rails (where it's a whole other template). The only
difference would be that it's rendered without a layout. Can you show
me some code that contains a "def render_partial" so I can see what
I'm missing?

> We could do render, write, or content, etc. with the :partial argument
> too, however it seems like that would create more branching logic
> inside that method, and more difficult to refactor.

Be careful--! We only get to write code inside to_s/widget/write_via,
not render/write/content. That's an abstract method for all intents
and purposes. But yeah, I think the concept of partialness should be
confined to the Rails template methods and stay out of Widget
altogether.

 - A

From brian.takita at gmail.com  Tue Apr 21 02:23:36 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Apr 2009 23:23:36 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
Message-ID: <1d7ddd110904202323q2c733eb1y3ee720a79112c227@mail.gmail.com>

On Mon, Apr 20, 2009 at 11:14 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> That sounds good to me. I assume that this means a single widget
>> object can only be accessed in one thread (which also makes sense to
>> me).
>
> Yes, this is still true.
>
>>> I also renamed "render" to "write", which removes confusion/ambiguity
>>
>> I remember complaints that render was a verb and should be a noun instead.
>> The rationale was Erector has methods for the html tag names instead
>> of a verb to create the tag (e.g. div, not write_div).
>> I think I slightly favor this, though I would be swayed by a
>> compelling argument.
>>
>> Maybe something like content?
>
> "content" is ok, but I wouldn't get too caught up in following the
> pattern of the tag methods. This method here is the only one that we
> are asking the user to implement, so it's fine -- and maybe even
> preferable -- if it's a more traditional method name like a verb.
> Also, user code will never call this method directly, so it's not even
> going to show up in the nesting of HTML-ish tag words. (That role is
> filled by "to_s" and/or "widget" (which is a noun) and/or "write_via"
> (which makes me cringe and hopefully can be hidden).)
>
>>> (1)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?w.write_via(self)
>>>
>>> (2)
>>> ? ? ?widget DateWidget, :when => Time.now, :title => "Nap Time"
>>>
>>> (3)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?widget w
>>>
>>> (3b)
>>> ? ? ?widget DateWidget.new(:when => Time.now, :title => "Nap Time")
>>>
>>> ((3) and (3b) are the same but I thought I'd show how it looks when
>>> you inline it.)
>>>
>>> So what does everyone think? I think it might be too much to support
>>> both "widget"
>>> and "write_via", but since one actually calls the other under the
>>> hood, it's not
>>> too big a commitment to keep them both around in the public API. I'm
>>> not in love with
>>> the new names, either; other possibilites are "emit" instead of render and ""
>>
>> I think I favor nouns here because they seem more declarative.
>>
>> So I would favor 2 & 3 in this case, though there may be a better term
>> than #widget.
>
>
>>> I've done these in a fork on GitHub (my first!). Please check it out
>>> and tell me what you think.
>>>
>>> GitHub seems to be stale right now but maybe later it'll be visible at
>>> http://github.com/alexch/erector/tree/master
>>> or maybe
>>> http://github.com/alexch/erector/tree/api-cleanup
>>> or you can clone it with
>>> git://github.com/alexch/erector.git
>
> These are working now. I wish GitHub had an indication of how stale it
> is; I wasted a lot of time mucking around and wondering why my changes
> hadn't gotten pushed (when they actually had and GitHub was over an
> hour behind).
Yeah, I wouldn't rely too much on Github being expedient. They are
learning how to deal with scale :-).
Git is pretty good about that though.
You can also use gitx (or gitk) to see what is on origin (github).
>
>> Did you stick your instructions in the README or in CHANGES?
>
> No, I haven't worked on the documentation yet, other than the rdoc comments.
>
>>> Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
>>> getting it
>>> into the various Rails branches. And I don't really understand the
>> Sure thing. Do you want me to go over it with you? Perhaps pairing
>> would be the best way to do this.
>
> The code is easy but I'm a git noob so I'm sure I'd screw something up
> if I tried it on my own... :-)
I primarily checkout the branch I want to merge into and merge in the
source banch.

e.g.

git checkout rails-2-3-2
git merge master
# I then manually resolve conflicts
# Run tests
git add .
git commit -a
git pull origin && git push origin master
>
>>> plan for render_partial.
>>> Shouldn't calling render_partial on a widget just call render (now
>>> "write") on that widget?
>>> Why do we need/want a separate method called render_partial on the widget?
>> Ideally we wouldn't even want to have the concept of partials, since
>> we have nice things such as Widget objects & modules.
>> I figured that render_partial was a good analogy to Rails partials and
>> would hopefully be refactored away.
>
> In my apps, the partial is not a method, it's a whole other class --
> just like in Rails (where it's a whole other template). The only
> difference would be that it's rendered without a layout. Can you show
> me some code that contains a "def render_partial" so I can see what
> I'm missing?
>
>> We could do render, write, or content, etc. with the :partial argument
>> too, however it seems like that would create more branching logic
>> inside that method, and more difficult to refactor.
>
> Be careful--! We only get to write code inside to_s/widget/write_via,
> not render/write/content. That's an abstract method for all intents
> and purposes. But yeah, I think the concept of partialness should be
> confined to the Rails template methods and stay out of Widget
> altogether.
>
> ?- A
>

From brian.takita at gmail.com  Tue Apr 21 03:20:38 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Apr 2009 00:20:38 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
Message-ID: <1d7ddd110904210020l11afa1fcudedf8bc8b1f8bb6e@mail.gmail.com>

On Mon, Apr 20, 2009 at 11:14 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> That sounds good to me. I assume that this means a single widget
>> object can only be accessed in one thread (which also makes sense to
>> me).
>
> Yes, this is still true.
>
>>> I also renamed "render" to "write", which removes confusion/ambiguity
>>
>> I remember complaints that render was a verb and should be a noun instead.
>> The rationale was Erector has methods for the html tag names instead
>> of a verb to create the tag (e.g. div, not write_div).
>> I think I slightly favor this, though I would be swayed by a
>> compelling argument.
>>
>> Maybe something like content?
>
> "content" is ok, but I wouldn't get too caught up in following the
> pattern of the tag methods. This method here is the only one that we
> are asking the user to implement, so it's fine -- and maybe even
> preferable -- if it's a more traditional method name like a verb.
> Also, user code will never call this method directly, so it's not even
> going to show up in the nesting of HTML-ish tag words. (That role is
> filled by "to_s" and/or "widget" (which is a noun) and/or "write_via"
> (which makes me cringe and hopefully can be hidden).)
Thats true. I think that why I'm not really feeling the need to
switch. Though, I do like how 'def content' seems to stick out more
than 'def render' or 'def write' (for me).
http://gist.github.com/98993

I would say in this case, lets find out what is the most intuitive
method name. We could always alias the method to our chosen way.
I wish, if there is an argument about this aesthetic, there were a
good way to determine which is "better". Perhaps a vote?

Also, I'm not really married #content, if (still?) strongly prefer #write.
>
>>> (1)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?w.write_via(self)
>>>
>>> (2)
>>> ? ? ?widget DateWidget, :when => Time.now, :title => "Nap Time"
>>>
>>> (3)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?widget w
>>>
>>> (3b)
>>> ? ? ?widget DateWidget.new(:when => Time.now, :title => "Nap Time")
>>>
>>> ((3) and (3b) are the same but I thought I'd show how it looks when
>>> you inline it.)
>>>
>>> So what does everyone think? I think it might be too much to support
>>> both "widget"
>>> and "write_via", but since one actually calls the other under the
>>> hood, it's not
>>> too big a commitment to keep them both around in the public API. I'm
>>> not in love with
>>> the new names, either; other possibilites are "emit" instead of render and ""
>>
>> I think I favor nouns here because they seem more declarative.
>>
>> So I would favor 2 & 3 in this case, though there may be a better term
>> than #widget.
>
>
>>> I've done these in a fork on GitHub (my first!). Please check it out
>>> and tell me what you think.
>>>
>>> GitHub seems to be stale right now but maybe later it'll be visible at
>>> http://github.com/alexch/erector/tree/master
>>> or maybe
>>> http://github.com/alexch/erector/tree/api-cleanup
>>> or you can clone it with
>>> git://github.com/alexch/erector.git
>
> These are working now. I wish GitHub had an indication of how stale it
> is; I wasted a lot of time mucking around and wondering why my changes
> hadn't gotten pushed (when they actually had and GitHub was over an
> hour behind).
>
>> Did you stick your instructions in the README or in CHANGES?
>
> No, I haven't worked on the documentation yet, other than the rdoc comments.
>
>>> Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
>>> getting it
>>> into the various Rails branches. And I don't really understand the
>> Sure thing. Do you want me to go over it with you? Perhaps pairing
>> would be the best way to do this.
>
> The code is easy but I'm a git noob so I'm sure I'd screw something up
> if I tried it on my own... :-)
>
>>> plan for render_partial.
>>> Shouldn't calling render_partial on a widget just call render (now
>>> "write") on that widget?
>>> Why do we need/want a separate method called render_partial on the widget?
>> Ideally we wouldn't even want to have the concept of partials, since
>> we have nice things such as Widget objects & modules.
>> I figured that render_partial was a good analogy to Rails partials and
>> would hopefully be refactored away.
>
> In my apps, the partial is not a method, it's a whole other class --
> just like in Rails (where it's a whole other template). The only
> difference would be that it's rendered without a layout. Can you show
> me some code that contains a "def render_partial" so I can see what
> I'm missing?
>
>> We could do render, write, or content, etc. with the :partial argument
>> too, however it seems like that would create more branching logic
>> inside that method, and more difficult to refactor.
>
> Be careful--! We only get to write code inside to_s/widget/write_via,
> not render/write/content. That's an abstract method for all intents
> and purposes. But yeah, I think the concept of partialness should be
> confined to the Rails template methods and stay out of Widget
> altogether.
>
> ?- A
>

From brian.takita at gmail.com  Tue Apr 21 03:25:57 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Apr 2009 00:25:57 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
Message-ID: <1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com>

Sorry about the spread out threads. I think I'm getting reply-blindness.

On Mon, Apr 20, 2009 at 11:14 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> That sounds good to me. I assume that this means a single widget
>> object can only be accessed in one thread (which also makes sense to
>> me).
>
> Yes, this is still true.
>
>>> I also renamed "render" to "write", which removes confusion/ambiguity
>>
>> I remember complaints that render was a verb and should be a noun instead.
>> The rationale was Erector has methods for the html tag names instead
>> of a verb to create the tag (e.g. div, not write_div).
>> I think I slightly favor this, though I would be swayed by a
>> compelling argument.
>>
>> Maybe something like content?
>
> "content" is ok, but I wouldn't get too caught up in following the
> pattern of the tag methods. This method here is the only one that we
> are asking the user to implement, so it's fine -- and maybe even
> preferable -- if it's a more traditional method name like a verb.
> Also, user code will never call this method directly, so it's not even
> going to show up in the nesting of HTML-ish tag words. (That role is
> filled by "to_s" and/or "widget" (which is a noun) and/or "write_via"
> (which makes me cringe and hopefully can be hidden).)
>
>>> (1)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?w.write_via(self)
>>>
>>> (2)
>>> ? ? ?widget DateWidget, :when => Time.now, :title => "Nap Time"
>>>
>>> (3)
>>> ? ? ?w = DateWidget.new(:when => Time.now, :title => "Nap Time")
>>> ? ? ?widget w
>>>
>>> (3b)
>>> ? ? ?widget DateWidget.new(:when => Time.now, :title => "Nap Time")
>>>
>>> ((3) and (3b) are the same but I thought I'd show how it looks when
>>> you inline it.)
>>>
>>> So what does everyone think? I think it might be too much to support
>>> both "widget"
>>> and "write_via", but since one actually calls the other under the
>>> hood, it's not
>>> too big a commitment to keep them both around in the public API. I'm
>>> not in love with
>>> the new names, either; other possibilites are "emit" instead of render and ""
>>
>> I think I favor nouns here because they seem more declarative.
>>
>> So I would favor 2 & 3 in this case, though there may be a better term
>> than #widget.
>
>
>>> I've done these in a fork on GitHub (my first!). Please check it out
>>> and tell me what you think.
>>>
>>> GitHub seems to be stale right now but maybe later it'll be visible at
>>> http://github.com/alexch/erector/tree/master
>>> or maybe
>>> http://github.com/alexch/erector/tree/api-cleanup
>>> or you can clone it with
>>> git://github.com/alexch/erector.git
>
> These are working now. I wish GitHub had an indication of how stale it
> is; I wasted a lot of time mucking around and wondering why my changes
> hadn't gotten pushed (when they actually had and GitHub was over an
> hour behind).
>
>> Did you stick your instructions in the README or in CHANGES?
>
> No, I haven't worked on the documentation yet, other than the rdoc comments.
>
>>> Brian, I got the Rails stuff working for 2.3.2 but I'll need your help
>>> getting it
>>> into the various Rails branches. And I don't really understand the
>> Sure thing. Do you want me to go over it with you? Perhaps pairing
>> would be the best way to do this.
>
> The code is easy but I'm a git noob so I'm sure I'd screw something up
> if I tried it on my own... :-)
>
>>> plan for render_partial.
>>> Shouldn't calling render_partial on a widget just call render (now
>>> "write") on that widget?
>>> Why do we need/want a separate method called render_partial on the widget?
>> Ideally we wouldn't even want to have the concept of partials, since
>> we have nice things such as Widget objects & modules.
>> I figured that render_partial was a good analogy to Rails partials and
>> would hopefully be refactored away.
>
> In my apps, the partial is not a method, it's a whole other class --
> just like in Rails (where it's a whole other template). The only
> difference would be that it's rendered without a layout. Can you show
> me some code that contains a "def render_partial" so I can see what
> I'm missing?
>
>> We could do render, write, or content, etc. with the :partial argument
>> too, however it seems like that would create more branching logic
>> inside that method, and more difficult to refactor.
>
> Be careful--! We only get to write code inside to_s/widget/write_via,
> not render/write/content. That's an abstract method for all intents
> and purposes. But yeah, I think the concept of partialness should be
> confined to the Rails template methods and stay out of Widget
> altogether.
Perhaps another object?
_foo.html.erb becomes FooPartial.html.rb? I can see this as being more
appropriate. I think I originally didn't like Partial being appended
to the class name, though I think I'm over it now.

Also, I added a commit to your branch.

http://github.com/pivotal/erector/tree/api-cleanup

To merge these changes in without committing them right away, you can run:
git merge origin/api-cleanup --no-commit
>
> ?- A
>

From alex at pivotallabs.com  Tue Apr 21 10:46:16 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 21 Apr 2009 07:46:16 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com> 
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com> 
	<1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com>
Message-ID: <7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com>

>> Be careful--! We only get to write code inside to_s/widget/write_via,
>> not render/write/content. That's an abstract method for all intents
>> and purposes. But yeah, I think the concept of partialness should be
>> confined to the Rails template methods and stay out of Widget
>> altogether.
>
> Perhaps another object?
>
> _foo.html.erb becomes FooPartial.html.rb? I can see this as being more
> appropriate. I think I originally didn't like Partial being appended
> to the class name, though I think I'm over it now.

I'm still not clear on the use case. Every widget is essentially a
partial already, isn't it? Are you talking about resolving the
potential naming conflict between "foo.rb" and "_foo.rb"... I'm still
being obtuse about the whole picture here though.

> Also, I added a commit to your branch.
>
> http://github.com/pivotal/erector/tree/api-cleanup

http://github.com/pivotal/erector/commit/7cb3043d7bc0f9cc54523aeade64cfad65f2ef2c

Excellent! I see we are continuing the Great Noun/Verb Method Name War
of 2009! (Renaming "prepare" to "context" :-))

I see how removing the to_s caching fixes a prettyprinting nesting
bug. I wonder whether anyone is making use of the cache anyway. If
they are we can add it back in in a smarter way.

Also, I learned at GoGaRuCo that using yield is 6x more efficient than
using &block/block.call, so I'll change that over.

> To merge these changes in without committing them right away, you can run:
> git merge origin/api-cleanup --no-commit

From alex at pivotallabs.com  Tue Apr 21 11:30:05 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 21 Apr 2009 08:30:05 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com> 
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com> 
	<1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com> 
	<7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com>
Message-ID: <7a93bd340904210830h1b6853aco660cd3e8f9874852@mail.gmail.com>

OK, I merged in Brian's changes back to my fork (I think I could get
used to this git insanity), tidied up some documentation, fixed two
small potential performance problems, and renamed #write to #content.

(Though Mike's latest naming suggestion is giving me pause...)

http://github.com/alexch/erector/commit/be98c45ebd46ffec3edb16ac2eff103c2309ff11
http://github.com/alexch/erector/commit/75da94e6e8db8c01ac08fbd6879f2e1cae512003

From brian.takita at gmail.com  Tue Apr 21 12:41:48 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Apr 2009 09:41:48 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
	<1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com>
	<7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com>
Message-ID: <1d7ddd110904210941u1cf974aaj82e96d7fed8017b9@mail.gmail.com>

On Tue, Apr 21, 2009 at 7:46 AM, Alex Chaffee <alex at pivotallabs.com> wrote:
>>> Be careful--! We only get to write code inside to_s/widget/write_via,
>>> not render/write/content. That's an abstract method for all intents
>>> and purposes. But yeah, I think the concept of partialness should be
>>> confined to the Rails template methods and stay out of Widget
>>> altogether.
>>
>> Perhaps another object?
>>
>> _foo.html.erb becomes FooPartial.html.rb? I can see this as being more
>> appropriate. I think I originally didn't like Partial being appended
>> to the class name, though I think I'm over it now.
>
> I'm still not clear on the use case. Every widget is essentially a
> partial already, isn't it? Are you talking about resolving the
> potential naming conflict between "foo.rb" and "_foo.rb"... I'm still
> being obtuse about the whole picture here though.
The use case is when you first generate the partial using the Rails
generator. Thats it.
I'd be just as happy with another solution.
>
>> Also, I added a commit to your branch.
>>
>> http://github.com/pivotal/erector/tree/api-cleanup
>
> http://github.com/pivotal/erector/commit/7cb3043d7bc0f9cc54523aeade64cfad65f2ef2c
>
> Excellent! I see we are continuing the Great Noun/Verb Method Name War
> of 2009! (Renaming "prepare" to "context" :-))
Yeah :-) I felt that a prepare action taking a block didn't make
sense. Maybe prepare_and_revert would be a better name?
>
> I see how removing the to_s caching fixes a prettyprinting nesting
> bug. I wonder whether anyone is making use of the cache anyway. If
> they are we can add it back in in a smarter way.
Probably not.
>
> Also, I learned at GoGaRuCo that using yield is 6x more efficient than
> using &block/block.call, so I'll change that over.
Didn't know that. That's good to know.
>
>> To merge these changes in without committing them right away, you can run:
>> git merge origin/api-cleanup --no-commit
>

From alex at pivotallabs.com  Tue Apr 21 13:07:39 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 21 Apr 2009 10:07:39 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <a6df53300904210917r7f84431bjb9ce17ec0d3f9060@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com> 
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com> 
	<1d7ddd110904210020l11afa1fcudedf8bc8b1f8bb6e@mail.gmail.com> 
	<a6df53300904210917r7f84431bjb9ce17ec0d3f9060@mail.gmail.com>
Message-ID: <7a93bd340904211007h6caa861boff6a552d1eb77433@mail.gmail.com>

On Tue, Apr 21, 2009 at 9:17 AM, Andy Peterson <andy at carbonfive.com> wrote:
> We ended up using the term "render_content", if you want another data point
> on terminology. (This is the method that you have to override in your
> subclass-- it outputs stuff.)

OK, "content," good -- we're on the right track! :-)

> We also ended up adopting "render_" to mean output to the stream (as opposed
> to return it), because of the ambiguities.?eg. render_hd instead of hd,
> render_li, etc.

In the Widget class RDoc, we use the terms "emit" and "return" to
distinguish between methods that write to the stream vs. return a
string. I think aesthetically it hurts to see a bunch of "render_"s
scattered among cleaner, declarative-looking HTML taggy builder code.
So I'm on board with Brian's rename of "render" (verb) or "write"
(verb) to "content" since the implication is that it's just another
builder-y declaration but with a solid, unambiguous name.

> We wrap the erector API to give us some isolation from changes: ?We don't
> descend from Erector::Widget directly. ?We have our own Widget class, useful
> for a portion of a page (formerly known as a partial). This works well and
> we have no need of the rails partial concept. We have a Page and AjaxDialog.
> Subclasser implements a render_content method uniformly.

I've got a Page class I've been propagating from project to project
too. We should compare notes! I'll put mine in a Gist as soon as I
can.

> Like others, we have a view helper method, render_widget, that takes a
> widget class, which is how you include it.
> ??? def render_widget(widget_class, assigns = {})
> ????? widget_class.new(helpers, assigns).render_content
> ??? end
>
> ie. render_widget Posts::ReviewForm

Great. Looks like we can help you shrink your codebase by a few lines
with the enhanced "widget" method. And a few "render_"s. (Another
reason to switch is that it's better with prettyprinting and sets the
"parent" pointer so your child widgets can call methods in the parent
if they want to.)

 - A

From alex at pivotallabs.com  Tue Apr 21 13:07:44 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 21 Apr 2009 10:07:44 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <1d7ddd110904210941u1cf974aaj82e96d7fed8017b9@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com> 
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com> 
	<1d7ddd110904210025s5fef9ce8h4857eba18753f74d@mail.gmail.com> 
	<7a93bd340904210746s7e042206lc9510cb4b6f81c60@mail.gmail.com> 
	<1d7ddd110904210941u1cf974aaj82e96d7fed8017b9@mail.gmail.com>
Message-ID: <7a93bd340904211007i13e6e6b3qdf4f0309764e9@mail.gmail.com>

>> Also, I learned at GoGaRuCo that using yield is 6x more efficient than
>> using &block/block.call, so I'll change that over.
>
> Didn't know that. That's good to know.

See http://gist.github.com/99250 :-) (my first gist! I'm so proud...)

From brian.takita at gmail.com  Wed Apr 29 21:51:45 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 29 Apr 2009 18:51:45 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <D05A52A4-F59B-435A-BFAF-B2D24ACF379D@pivotallabs.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
	<1d7ddd110904210020l11afa1fcudedf8bc8b1f8bb6e@mail.gmail.com>
	<a6df53300904210917r7f84431bjb9ce17ec0d3f9060@mail.gmail.com>
	<7a93bd340904211007h6caa861boff6a552d1eb77433@mail.gmail.com>
	<7a93bd340904291229t632b9e30kc8a1e4ee92c26074@mail.gmail.com>
	<D05A52A4-F59B-435A-BFAF-B2D24ACF379D@pivotallabs.com>
Message-ID: <1d7ddd110904291851x57054623uf9698f672ddf39ce@mail.gmail.com>

On Wed, Apr 29, 2009 at 6:37 PM, Jeff Dean <jdean at pivotallabs.com> wrote:
> I like the move away from render and render_to, and content is what we use
> on Casebook to define the content area, so +1 on that as well.
> I know that deprecation is really the way to go, but I'd love to have
> "render" delegate to helpers, so we could do things like:
> render "my_views_folder/my_partial_name", :foo => "bar"
> Currently we have to write:
> rawtext helpers.render "my_views_folder/my_partial", :foo => "bar"
> It forces people to upgrade their code, instead of just getting deprecation
> warnings, but it makes it much more rails-like. ?Any thoughts?
> In general I like this move a lot. ?No objections here.
+1 and +1
> On Apr 29, 2009, at 3:29 PM, Alex Chaffee wrote:
>
> Any further thoughts on the new API? My goal is to get consensus on the new
> conventions and then start documenting and publicizing it so people aren't
> taken by surprise when "render_to" stops working and "render" starts
> throwing deprecation errors...
> To summarize:
> * a widget's constructor no longer takes helpers and output stream; instead
> it just takes an options hash (and an optional block like before); the
> options become instance variables with accessors (also like before)
> * to render a widget call "widget foo" or "widget Foo" from inside any
> widget; that passes along the helpers and output stream to the nested widget
> before calling its content method
> * the "render" is now named "content" for consistency with the declarative
> noun-y HTML tag method names, and also to remove confusion with Rails'
> various render methods
> http://github.com/alexch/erector/tree/master
> ?- A
>

From alex at pivotallabs.com  Wed Apr 29 22:36:09 2009
From: alex at pivotallabs.com (Alex Chaffee)
Date: Wed, 29 Apr 2009 19:36:09 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <D05A52A4-F59B-435A-BFAF-B2D24ACF379D@pivotallabs.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com> 
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com> 
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com> 
	<1d7ddd110904210020l11afa1fcudedf8bc8b1f8bb6e@mail.gmail.com> 
	<a6df53300904210917r7f84431bjb9ce17ec0d3f9060@mail.gmail.com> 
	<7a93bd340904211007h6caa861boff6a552d1eb77433@mail.gmail.com> 
	<7a93bd340904291229t632b9e30kc8a1e4ee92c26074@mail.gmail.com> 
	<D05A52A4-F59B-435A-BFAF-B2D24ACF379D@pivotallabs.com>
Message-ID: <7a93bd340904291936k3e5f9ee3m6edf85dd91f7c9a8@mail.gmail.com>

> I know that deprecation is really the way to go, but I'd love to have
> "render" delegate to helpers, so we could do things like:
> render "my_views_folder/my_partial_name", :foo => "bar"

Hmm, yeah, that'd be nice... Does anyone know if there's some Ruby
meta-magic that allows us to tell whether the "render" method is the
one defined on RailsWidget instead of the current subclass?

Hmm, maybe something like this...

      if respond_to? :render &&
        self.method(:render).to_s != RailsWidget.new.method(:render).to_s
        raise "Erector's API has changed. You should rename
#{self.class}#render to #content."
      end

(Wow, I must have had way too much coffee today.)

 - A

From brian.takita at gmail.com  Wed Apr 29 22:44:37 2009
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 29 Apr 2009 19:44:37 -0700
Subject: [Erector-devel] API Cleanup
In-Reply-To: <7a93bd340904291936k3e5f9ee3m6edf85dd91f7c9a8@mail.gmail.com>
References: <7a93bd340904201921r58ea53bcn443e1c05d3897955@mail.gmail.com>
	<1d7ddd110904202250l38f20728s935b49117ffbcabe@mail.gmail.com>
	<7a93bd340904202314ob48950el7e930aae6778defd@mail.gmail.com>
	<1d7ddd110904210020l11afa1fcudedf8bc8b1f8bb6e@mail.gmail.com>
	<a6df53300904210917r7f84431bjb9ce17ec0d3f9060@mail.gmail.com>
	<7a93bd340904211007h6caa861boff6a552d1eb77433@mail.gmail.com>
	<7a93bd340904291229t632b9e30kc8a1e4ee92c26074@mail.gmail.com>
	<D05A52A4-F59B-435A-BFAF-B2D24ACF379D@pivotallabs.com>
	<7a93bd340904291936k3e5f9ee3m6edf85dd91f7c9a8@mail.gmail.com>
Message-ID: <1d7ddd110904291944l286f864cga939590c46b2d18c@mail.gmail.com>

On Wed, Apr 29, 2009 at 7:36 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> I know that deprecation is really the way to go, but I'd love to have
>> "render" delegate to helpers, so we could do things like:
>> render "my_views_folder/my_partial_name", :foo => "bar"
>
> Hmm, yeah, that'd be nice... Does anyone know if there's some Ruby
> meta-magic that allows us to tell whether the "render" method is the
> one defined on RailsWidget instead of the current subclass?
>
> Hmm, maybe something like this...
>
> ? ? ?if respond_to? :render &&
> ? ? ? ?self.method(:render).to_s != RailsWidget.new.method(:render).to_s
> ? ? ? ?raise "Erector's API has changed. You should rename
> #{self.class}#render to #content."
> ? ? ?end
>
> (Wow, I must have had way too much coffee today.)
>
> ?- A
>
The only way I can think of is:

unless self.method(:render).to_s.include?("(RailsWidget)")
end

Maybe there is something better?