From alex at pivotallabs.com  Sun May  4 10:50:56 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sun, 4 May 2008 07:50:56 -0700
Subject: [Erector-devel] About the Erector project
In-Reply-To: <37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
Message-ID: <7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>

Rami -

Thanks for the patch! Can you write a unit test (or actually, we
prefer rspecs) for it? I've never used view_paths before and it's
always a good idea to wrap framework code in tests so we're sure it
keeps working even with upgrades to Rails.

Brian, you wrote the action_view_template_handler -- does this patch
look ok to you?

Currently the only full-fledged projects that use Erector are client
project so we can't share the source code. There are examples in the
project (see "examples" dir) and the web site is now generated using
erect so you can see what I did there in the "web" dir.

 - Alex

On Sun, May 4, 2008 at 2:36 AM, Rami Grossman <ramigg at gmail.com> wrote:
> Hi Alex,
>
> I played a bit with the Erector plugin you have created. My project uses
> custom view paths and I saw that you use a fixed standard path only
> (app/views). So I changed a bit the file: action_view_template_handler.rb
> and added dynamic path finder. (See the attached file)
> Please check it out and commit if it's OK.
> Hope there are no other places I forgot.
>
>
> P.S
>
> This is a great plugin - hope it succeeds.
> How are you advancing with it?
> I saw a new website for it. - Great work!!!
>
> Can you send me some more advanced examples?
> A demo project or part of it will help a lot.
>
> Thanks again.
>
>
>
> Regards,
> Rami grossman
> Bnei Baruch
> www.kabbalah.info
>
>
>
>
>
> On Wed, Apr 23, 2008 at 10:42 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> >
> >
> >
> >
> > On Wed, Apr 23, 2008 at 11:46 AM, Rami Grossman <ramigg at gmail.com> wrote:
> >
> > > Thank you for your kind reply, Alex.
> > >
> > > two questions: one is conceptual and one is technical:
> > >
> > > 1. When I render a view - can I pass to it any parameters like with
> regular render? (too lazy to check :) )
> >
> >
> > There are at least three answers to this :-)
> >
> > 1. If you call render from your controller, you won't be passing in
> parameters, you'll be getting instance variables passed through the assigns
> hash, which is accessible from an Erector widget via the "helpers" object.
> >
> > 2. If you call render :partial, I'm not sure what will happen, since we
> just added support for that and haven't tested the :locals behavior. Thanks
> for the todo item!
> >
> > 3. We recommend that you not use render at all, at least once you're in a
> widget, and instead use "OtherWidget.new(params).render_to(self.doc)" in
> which case you can pass in whatever parameters you want since you're the one
> who wrote it :-)
> >
> >
> >
> > >
> > > 2. What is the roadmap of this project? Any strategic plans? When will
> be the first stable version? and what is next?
> > >
> >
> >
> > We're working on Rails integration and documentation right now. Once
> there's documentation (and thanks for providing some FAQ items :-)) we'll
> make an announcement and blog about it and see what happens. That should be
> only a few weeks from now, depending on when we get time to write docs.
> >
> > As for stability, we probably won't radically change things since we're
> pretty happy with the core API. Some things are still in flux (like
> render/render_to/render_for) and we'll be nailing those down soon, probably
> concurrently with writing the docs for them. Some widgets may change,
> hopefully for the better. We're trying to be sensible about not breaking
> things, and if we introduce incompatible changes we'll either be very loud
> about it or deprecate things over 2 releases. We'll probably go to 1.0
> before the end of the year, hopefully by the end of summer.
> >
> > We're not sure how much of a widget framework it will be; for now it's
> mostly a template replacement so just the basic widgets (forms, tables,
> etc.) are on the horizon. The world of reusable widgets seems to be
> happening in JavaScript these days anyway.
> >
> >
> >
> > >
> > > Generally I see a lot of potential with this project and hope it will
> spread.
> > > Good luck!
> > >
> >
> >
> > Thanks! It's encouraging to hear from you.
> >
> >
> > >
> > > p.s
> > > Is there any forum/active mailing list for technical questions?
> > >
> > >
> > >
> > >
> >
> >
> > http://rubyforge.org/mailman/listinfo/erector-devel
> > http://rubyforge.org/pipermail/erector-devel/
> >
> > Once we have actual users, we'll make an erector-users list, but for now
> just use erector-devel.
> >
> >
> >
> >
> > >
> > >
> > >
> > >
> > > On Wed, Apr 23, 2008 at 6:05 PM, Alex Chaffee <alex at pivotallabs.com>
> wrote:
> > >
> > > > It's definitely production worthy -- it's in use in 3 Rails projects
> we developed (I'll check with the clients to see if we can say which ones).
> We haven't done performance tuning yet but it's at least as fast as rhtml.
> As you can tell by browsing the source, there aren't many widgets developed
> for it yet, but it supports all of the Rails helpers and integrates with the
> render method, and you can mix-and-match with other Rails template engines.
> I haven't looked at cells yet but it doesn't seem to do as much as Erector
> does. In fact I can't really tell what it does :-)
> > > >
> > > > We have rudimentary docs right now, covering the basics and how to
> integrate with Rails, and we have a commitment to add more (and since it's
> being supported by Pivotal Labs we actually dedicate engineers to work on
> it, rather than leaving it completely up to the nights-and-weekends crew).
> > > >
> > > > The main appeal of Erector is the combination of HTML-like syntax with
> actual Ruby code -- your views are code, but they kinda look like HTML, but
> with more structure, and the fact that they're code means you can use real
> programming techniques like functions and variables and stuff. We do not try
> to enforce model-view separation or anything like that since in our
> experience, any such restrictions can be subverted and just lead to more
> layering and messier code. Trust the coders, trust the language, is our
> motto (which I just made up :-)).
> > > >
> > > > Does that help?
> > > >
> > > >  - A
> > > >
> > > > P.S. Have you used Markaby already? We used it and liked it but it had
> too much magic for our tastes so we basically rewrote it as Erector.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 23, 2008 at 6:34 AM, Rami Grossman <ramigg at gmail.com>
> wrote:
> > > >
> > > > > Hi,
> > > > > I'm looking for a template enhancer for a large project I'm
> responsible for. It's a CMS. We need some kind of widget framework.
> > > > > We are considering to use Cells. But now I accidentally came across
> this interesting project - Erector.
> > > > >
> > > > >
> > > > > What can you tell me about it?
> > > > > How stable is it?
> > > > > When will it be more documented?
> > > > > What project are using it?
> > > > > Is it stable enough for production?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Rami grossman
> > > > > Bnei Baruch
> > > > > www.kabbalah.info
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alex Chaffee - Pivotal Labs
> > > > alex at PivotalLabs.com
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> > Alex Chaffee - Pivotal Labs
> > alex at PivotalLabs.com
>
>



-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: action_view_template_handler.rb.zip
Type: application/zip
Size: 1140 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080504/82af8202/attachment.zip>

From kingdon at panix.com  Sun May  4 16:20:44 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sun,  4 May 2008 16:20:44 -0400 (EDT)
Subject: [Erector-devel] About the Erector project
In-Reply-To: <7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	(alex@pivotallabs.com)
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
Message-ID: <20080504202044.46038241AF@panix5.panix.com>

> 3. We recommend that you not use render at all, at least once you're in a
> widget, and instead use "OtherWidget.new(params).render_to(self.doc)" in
> which case you can pass in whatever parameters you want since you're the one
> who wrote it :-)

Why not just
  text OtherWidget.new()
?

This has worked for a while, and I just checked in a test for it.

I don't know if "text" as a method name feels very logical here, but
widget.render_to(self) feels backwards to me (and having to pass in
self.doc rather than just self compounds the ugliness), as opposed to
self.<something>(widget)

From alex at pivotallabs.com  Sun May  4 16:59:27 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sun, 4 May 2008 13:59:27 -0700
Subject: [Erector-devel] About the Erector project
In-Reply-To: <20080504202044.46038241AF@panix5.panix.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<20080504202044.46038241AF@panix5.panix.com>
Message-ID: <7a93bd340805041359h22f765a6wb464e9906d8c8b72@mail.gmail.com>

> widget.render_to(self) feels backwards to me (and having to pass in
> self.doc rather than just self compounds the ugliness), as opposed to
> self.<something>(widget)
>

I agree! You know, it evolved to there -- from render_to(doc) to
render_to(doc_or_widget) and it's nice you saw that next logical
refactoring. LoD FTW!


> I don't know if "text" as a method name feels very logical here,


Not to me. In fact it's illogical since the existing "text" method is
defined to htmlescape its parameter, and here it doesn't do that. Let's make
a new method... name suggestions? Maybe just render_widget(Whatever.new)


-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080504/5b2821b4/attachment-0001.html>

From ramigg at gmail.com  Mon May  5 05:50:37 2008
From: ramigg at gmail.com (Rami Grossman)
Date: Mon, 5 May 2008 12:50:37 +0300
Subject: [Erector-devel] About the Erector project
In-Reply-To: <7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
Message-ID: <37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>

Hi Alex,I don't have experience with unit tests. Never did those. I know
it's not good and I now have a programmer that will write unit test for what
we wrote till now, but it will take time.
Anyway I hope you commit this code to repository, without that Erector will
work only in 'app/views' subfolder, and Rails gives the functionality to
customize it, so I think Erector should also support it.

I also found in 'widget.rb' in the 'css' method, that you put the
'erector.css'  directly as the href value.
I changed it in my code from:
    def css(href)
      link :rel => 'stylesheet', :type => 'text/css', :href => 'erector.css'

    end

to:
    def css(href)
      link :rel => 'stylesheet', :type => 'text/css', :href => href
    end

Please commit this small fix to repository



On Sun, May 4, 2008 at 5:50 PM, Alex Chaffee <alex at pivotallabs.com> wrote:

> Rami -
>
> Thanks for the patch! Can you write a unit test (or actually, we
> prefer rspecs) for it? I've never used view_paths before and it's
> always a good idea to wrap framework code in tests so we're sure it
> keeps working even with upgrades to Rails.
>
> Brian, you wrote the action_view_template_handler -- does this patch
> look ok to you?
>
> Currently the only full-fledged projects that use Erector are client
> project so we can't share the source code. There are examples in the
> project (see "examples" dir) and the web site is now generated using
> erect so you can see what I did there in the "web" dir.
>
>  - Alex
>
> On Sun, May 4, 2008 at 2:36 AM, Rami Grossman <ramigg at gmail.com> wrote:
> > Hi Alex,
> >
> > I played a bit with the Erector plugin you have created. My project uses
> > custom view paths and I saw that you use a fixed standard path only
> > (app/views). So I changed a bit the file:
> action_view_template_handler.rb
> > and added dynamic path finder. (See the attached file)
> > Please check it out and commit if it's OK.
> > Hope there are no other places I forgot.
> >
> >
> > P.S
> >
> > This is a great plugin - hope it succeeds.
> > How are you advancing with it?
> > I saw a new website for it. - Great work!!!
> >
> > Can you send me some more advanced examples?
> > A demo project or part of it will help a lot.
> >
> > Thanks again.
> >
> >
> >
> > Regards,
> > Rami grossman
> > Bnei Baruch
> > www.kabbalah.info
> >
> >
> >
> >
> >
> > On Wed, Apr 23, 2008 at 10:42 PM, Alex Chaffee <alex at pivotallabs.com>
> wrote:
> > >
> > >
> > >
> > >
> > > On Wed, Apr 23, 2008 at 11:46 AM, Rami Grossman <ramigg at gmail.com>
> wrote:
> > >
> > > > Thank you for your kind reply, Alex.
> > > >
> > > > two questions: one is conceptual and one is technical:
> > > >
> > > > 1. When I render a view - can I pass to it any parameters like with
> > regular render? (too lazy to check :) )
> > >
> > >
> > > There are at least three answers to this :-)
> > >
> > > 1. If you call render from your controller, you won't be passing in
> > parameters, you'll be getting instance variables passed through the
> assigns
> > hash, which is accessible from an Erector widget via the "helpers"
> object.
> > >
> > > 2. If you call render :partial, I'm not sure what will happen, since
> we
> > just added support for that and haven't tested the :locals behavior.
> Thanks
> > for the todo item!
> > >
> > > 3. We recommend that you not use render at all, at least once you're
> in a
> > widget, and instead use "OtherWidget.new(params).render_to(self.doc)" in
> > which case you can pass in whatever parameters you want since you're the
> one
> > who wrote it :-)
> > >
> > >
> > >
> > > >
> > > > 2. What is the roadmap of this project? Any strategic plans? When
> will
> > be the first stable version? and what is next?
> > > >
> > >
> > >
> > > We're working on Rails integration and documentation right now. Once
> > there's documentation (and thanks for providing some FAQ items :-))
> we'll
> > make an announcement and blog about it and see what happens. That should
> be
> > only a few weeks from now, depending on when we get time to write docs.
> > >
> > > As for stability, we probably won't radically change things since
> we're
> > pretty happy with the core API. Some things are still in flux (like
> > render/render_to/render_for) and we'll be nailing those down soon,
> probably
> > concurrently with writing the docs for them. Some widgets may change,
> > hopefully for the better. We're trying to be sensible about not breaking
> > things, and if we introduce incompatible changes we'll either be very
> loud
> > about it or deprecate things over 2 releases. We'll probably go to 1.0
> > before the end of the year, hopefully by the end of summer.
> > >
> > > We're not sure how much of a widget framework it will be; for now it's
> > mostly a template replacement so just the basic widgets (forms, tables,
> > etc.) are on the horizon. The world of reusable widgets seems to be
> > happening in JavaScript these days anyway.
> > >
> > >
> > >
> > > >
> > > > Generally I see a lot of potential with this project and hope it
> will
> > spread.
> > > > Good luck!
> > > >
> > >
> > >
> > > Thanks! It's encouraging to hear from you.
> > >
> > >
> > > >
> > > > p.s
> > > > Is there any forum/active mailing list for technical questions?
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > http://rubyforge.org/mailman/listinfo/erector-devel
> > > http://rubyforge.org/pipermail/erector-devel/
> > >
> > > Once we have actual users, we'll make an erector-users list, but for
> now
> > just use erector-devel.
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 23, 2008 at 6:05 PM, Alex Chaffee <alex at pivotallabs.com>
> > wrote:
> > > >
> > > > > It's definitely production worthy -- it's in use in 3 Rails
> projects
> > we developed (I'll check with the clients to see if we can say which
> ones).
> > We haven't done performance tuning yet but it's at least as fast as
> rhtml.
> > As you can tell by browsing the source, there aren't many widgets
> developed
> > for it yet, but it supports all of the Rails helpers and integrates with
> the
> > render method, and you can mix-and-match with other Rails template
> engines.
> > I haven't looked at cells yet but it doesn't seem to do as much as
> Erector
> > does. In fact I can't really tell what it does :-)
> > > > >
> > > > > We have rudimentary docs right now, covering the basics and how to
> > integrate with Rails, and we have a commitment to add more (and since
> it's
> > being supported by Pivotal Labs we actually dedicate engineers to work
> on
> > it, rather than leaving it completely up to the nights-and-weekends
> crew).
> > > > >
> > > > > The main appeal of Erector is the combination of HTML-like syntax
> with
> > actual Ruby code -- your views are code, but they kinda look like HTML,
> but
> > with more structure, and the fact that they're code means you can use
> real
> > programming techniques like functions and variables and stuff. We do not
> try
> > to enforce model-view separation or anything like that since in our
> > experience, any such restrictions can be subverted and just lead to more
> > layering and messier code. Trust the coders, trust the language, is our
> > motto (which I just made up :-)).
> > > > >
> > > > > Does that help?
> > > > >
> > > > >  - A
> > > > >
> > > > > P.S. Have you used Markaby already? We used it and liked it but it
> had
> > too much magic for our tastes so we basically rewrote it as Erector.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 23, 2008 at 6:34 AM, Rami Grossman <ramigg at gmail.com>
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > > I'm looking for a template enhancer for a large project I'm
> > responsible for. It's a CMS. We need some kind of widget framework.
> > > > > > We are considering to use Cells. But now I accidentally came
> across
> > this interesting project - Erector.
> > > > > >
> > > > > >
> > > > > > What can you tell me about it?
> > > > > > How stable is it?
> > > > > > When will it be more documented?
> > > > > > What project are using it?
> > > > > > Is it stable enough for production?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Rami grossman
> > > > > > Bnei Baruch
> > > > > > www.kabbalah.info
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alex Chaffee - Pivotal Labs
> > > > > alex at PivotalLabs.com
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Alex Chaffee - Pivotal Labs
> > > alex at PivotalLabs.com
> >
> >
>
>
>
> --
> Alex Chaffee - Pivotal Labs
> alex at PivotalLabs.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080505/bc3c88c1/attachment.html>

From kingdon at panix.com  Mon May  5 08:51:58 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Mon,  5 May 2008 08:51:58 -0400 (EDT)
Subject: [Erector-devel] About the Erector project
In-Reply-To: <7a93bd340805041359h22f765a6wb464e9906d8c8b72@mail.gmail.com>
	(alex@pivotallabs.com)
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<20080504202044.46038241AF@panix5.panix.com>
	<7a93bd340805041359h22f765a6wb464e9906d8c8b72@mail.gmail.com>
Message-ID: <20080505125158.A7DF9241AF@panix5.panix.com>

> In fact it's illogical since the existing "text" method is
> defined to htmlescape its parameter, and here it doesn't do that. 

Not exactly.  The text method htmlescapes when you pass it something
that needs htmlescaping (such as a string).

But when you pass it something which doesn't, it doesn't.  The
canonical example is:

text raw("&some-crazy-thing;")

an alternative to "rawtext", and I consider the latter a bit ugly
although I guess it lets people write fewer parentheses.

The main motivation for this design is that htmlescaping (or not) also
applies to attribute values, as in:

  a :href => "quote-me"
  a :href => raw("do-not-quote-me")

> Let's make a new method... name suggestions? Maybe just
> render_widget(Whatever.new)

Hmm, yeah, "render" is already taken.  As for the behavior, it is just
a synonym for "text" unless I'm missing something.  Perhaps call it
"content"?  (Trying to see how the XML spec uses the word content left
me slightly confused but I think what the spec calls "mixed content"
is roughly what we are talking about here).

From alex at pivotallabs.com  Mon May  5 10:33:50 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Mon, 5 May 2008 07:33:50 -0700
Subject: [Erector-devel] About the Erector project
In-Reply-To: <37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
Message-ID: <7a93bd340805050733g78fc353fg777b2fc76e4ed143@mail.gmail.com>

On Mon, May 5, 2008 at 2:50 AM, Rami Grossman <ramigg at gmail.com> wrote:

> Hi Alex,I don't have experience with unit tests. Never did those. I know
> it's not good and I now have a programmer that will write unit test for what
> we wrote till now, but it will take time.
> Anyway I hope you commit this code to repository, without that Erector
> will work only in 'app/views' subfolder, and Rails gives the functionality
> to customize it, so I think Erector should also support it.
>

I think so too. Let's wait until someone writes a test for it first, though.


>
> I also found in 'widget.rb' in the 'css' method, that you put the
> 'erector.css'  directly as the href value.
>

Oops! Nice catch.

-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080505/dc8a7006/attachment-0001.html>

From kingdon at panix.com  Tue May  6 01:15:36 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Tue,  6 May 2008 01:15:36 -0400 (EDT)
Subject: [Erector-devel] why double-escape on test h("foo")?
Message-ID: <20080506051536.77BE2241AF@panix5.panix.com>

What do people think of the following patch?  I'm hesitating because I
don't know whether people call h and expect a string back.  I'm not
really sure what the use case is for the h method at all.  Maybe we
should just get rid of h?

Index: spec/erector/widget_spec.rb
===================================================================
--- spec/erector/widget_spec.rb	(revision 93)
+++ spec/erector/widget_spec.rb	(working copy)
@@ -252,6 +252,12 @@
       it "does not escape raw strings" do
         @widget.h(@widget.raw("&")).should == "&"
       end
+      
+      it "does not double escape" do
+        Erector::Widget.new() do
+          text h("this&that")
+        end.to_s.should == "this&amp;that"
+      end
     end
 
     describe "#javascript" do
Index: lib/erector/widget.rb
===================================================================
--- lib/erector/widget.rb	(revision 93)
+++ lib/erector/widget.rb	(working copy)
@@ -154,12 +154,11 @@
       __empty_element__(*args, &block)
     end
 
-    # Returns an HTML-escaped version of its parameter. Leaves the HtmlParts stream untouched. Note that
-    # the #text method automatically HTML-escapes its parameter, so be careful *not* to do something like
-    # text(h("2<4")) since that will double-escape the less-than sign (you'll get "2&amp;lt;4" instead of
-    # "2&lt;4").
+    # Returns an HTML-escaped version of its parameter. Leaves the HtmlParts stream untouched.
+    # The returned value will not be HTML-escaped again if you then pass it to a method
+    # such as text which normally HTML-escapes.
     def h(content)
-      content.html_escape
+      raw(content.html_escape)
     end
 
     # Emits an open tag, comprising '<', tag name, optional attributes, and '>'

From alex at pivotallabs.com  Tue May  6 10:04:29 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 6 May 2008 07:04:29 -0700
Subject: [Erector-devel] why double-escape on test h("foo")?
In-Reply-To: <20080506051536.77BE2241AF@panix5.panix.com>
References: <20080506051536.77BE2241AF@panix5.panix.com>
Message-ID: <7a93bd340805060704i29d09266l2066aa407e28b73b@mail.gmail.com>

...or move it to helpers.rb...

Is there a use case where one would actually desire double escaping to
happen? Like making a wiki or something? I see the elegance of your solution
but I'm not sure it's not more confusing...

On Mon, May 5, 2008 at 10:15 PM, Jim Kingdon <kingdon at panix.com> wrote:

> What do people think of the following patch?  I'm hesitating because I
> don't know whether people call h and expect a string back.  I'm not
> really sure what the use case is for the h method at all.  Maybe we
> should just get rid of h?
>
> Index: spec/erector/widget_spec.rb
> ===================================================================
> --- spec/erector/widget_spec.rb (revision 93)
> +++ spec/erector/widget_spec.rb (working copy)
> @@ -252,6 +252,12 @@
>       it "does not escape raw strings" do
>         @widget.h(@widget.raw("&")).should == "&"
>       end
> +
> +      it "does not double escape" do
> +        Erector::Widget.new() do
> +          text h("this&that")
> +        end.to_s.should == "this&amp;that"
> +      end
>     end
>
>     describe "#javascript" do
> Index: lib/erector/widget.rb
> ===================================================================
> --- lib/erector/widget.rb       (revision 93)
> +++ lib/erector/widget.rb       (working copy)
> @@ -154,12 +154,11 @@
>       __empty_element__(*args, &block)
>     end
>
> -    # Returns an HTML-escaped version of its parameter. Leaves the
> HtmlParts stream untouched. Note that
> -    # the #text method automatically HTML-escapes its parameter, so be
> careful *not* to do something like
> -    # text(h("2<4")) since that will double-escape the less-than sign
> (you'll get "2&amp;lt;4" instead of
> -    # "2&lt;4").
> +    # Returns an HTML-escaped version of its parameter. Leaves the
> HtmlParts stream untouched.
> +    # The returned value will not be HTML-escaped again if you then pass
> it to a method
> +    # such as text which normally HTML-escapes.
>     def h(content)
> -      content.html_escape
> +      raw(content.html_escape)
>     end
>
>     # Emits an open tag, comprising '<', tag name, optional attributes,
> and '>'
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080506/60eea175/attachment.html>

From alex at pivotallabs.com  Fri May 16 14:35:23 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Fri, 16 May 2008 11:35:23 -0700
Subject: [Erector-devel] Erector doesn't find templates when loaded as gem
Message-ID: <7a93bd340805161135p4d8befd2k2653900e761794e7@mail.gmail.com>

I should log this as a bug, but just FYI: erector seems not to be able to
find .rb files as template files when it's being used as a gem and Rails is
unpacked into vendor. Unpacking erector into vendor/plugins/erector fixes
this problem. My theory is it's a load-order thing since
action_view_template_handler has some conditional code in it that wouldn't
execute if it loads before Rails does.

(This may occur only when the layout is a .rb file too. Haven't done the
trial-and-error to narrow it down.)

-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080516/dcb4038d/attachment.html>

From ramigg at gmail.com  Tue May 20 12:03:33 2008
From: ramigg at gmail.com (Rami Grossman)
Date: Tue, 20 May 2008 19:03:33 +0300
Subject: [Erector-devel] Problem using helpers
Message-ID: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>

Hi Alex,
It seems like there is a problem using helpers.
I try to use javascript_include_tag and I get this error:

*javascript_include_tag '../ext/adapter/ext/ext-base',*



You have a nil object when you didn't expect it!

The error occurred while evaluating nil.javascript_include_tag

RAILS_ROOT: C:/projects/cms

Application Trace <http://hebrew.localhost:3000/> | Framework
Trace<http://hebrew.localhost:3000/>
 | Full Trace <http://hebrew.localhost:3000/>

vendor/plugins/erector/lib/erector/helpers.rb:12:in `send'

vendor/plugins/erector/lib/erector/helpers.rb:12:in `javascript_include_tag'

app/sites/hebmain/layouts/website.rb:32:in `render'

app/sites/hebmain/layouts/website.rb:16:in `render'

app/sites/hebmain/layouts/website.rb:15:in `render'

lib/widget_manager.rb:88:in `render'

app/controllers/sites/templates_controller.rb:55:in `template'

app/controllers/sites/templates_controller.rb:48:in `template'

script\server:3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080520/d7c4ae92/attachment.html>

From alex at pivotallabs.com  Tue May 20 13:06:21 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 20 May 2008 10:06:21 -0700
Subject: [Erector-devel] Problem using helpers
In-Reply-To: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>
References: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>
Message-ID: <7a93bd340805201006v485077ddu232df514f57e4ca5@mail.gmail.com>

Are you using a released version or the version checked in to HEAD? I did
some work on helpers over the weekend...

It looks like the widget you're inside doesn't have the helpers variable
set. If you're instantiating one widget from inside another, make sure to
pass in the helpers variable in the constructor.



On Tue, May 20, 2008 at 9:03 AM, Rami Grossman <ramigg at gmail.com> wrote:

> Hi Alex,
> It seems like there is a problem using helpers.
> I try to use javascript_include_tag and I get this error:
>
> *javascript_include_tag '../ext/adapter/ext/ext-base',*
>
>
>
> You have a nil object when you didn't expect it!
>
> The error occurred while evaluating nil.javascript_include_tag
>
> RAILS_ROOT: C:/projects/cms
>
> Application Trace <http://hebrew.localhost:3000/> | Framework Trace<http://hebrew.localhost:3000/>
>  | Full Trace <http://hebrew.localhost:3000/>
>
> vendor/plugins/erector/lib/erector/helpers.rb:12:in `send'
>
> vendor/plugins/erector/lib/erector/helpers.rb:12:in `javascript_include_tag'
>
> app/sites/hebmain/layouts/website.rb:32:in `render'
>
> app/sites/hebmain/layouts/website.rb:16:in `render'
>
> app/sites/hebmain/layouts/website.rb:15:in `render'
>
> lib/widget_manager.rb:88:in `render'
>
> app/controllers/sites/templates_controller.rb:55:in `template'
>
> app/controllers/sites/templates_controller.rb:48:in `template'
>
> script\server:3
>
>


-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080520/83e27a0a/attachment-0001.html>

From ramigg at gmail.com  Tue May 20 13:15:51 2008
From: ramigg at gmail.com (Rami Grossman)
Date: Tue, 20 May 2008 20:15:51 +0300
Subject: [Erector-devel] Problem using helpers
In-Reply-To: <7a93bd340805201006v485077ddu232df514f57e4ca5@mail.gmail.com>
References: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>
	<7a93bd340805201006v485077ddu232df514f57e4ca5@mail.gmail.com>
Message-ID: <37f8b65c0805201015g7a3cfc7bg46712387ee523eeb@mail.gmail.com>

I tried both versions.The same problem in both.
I don't understand where the helpers variable is initialized first. I saw
that in widget.rb it defaults helpers to nil. So I have to pass it
somewhere.
Can you give a simple example of widget with rails helpers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080520/ccdcb3dd/attachment.html>

From alex at pivotallabs.com  Tue May 20 13:31:58 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Tue, 20 May 2008 10:31:58 -0700
Subject: [Erector-devel] Problem using helpers
In-Reply-To: <37f8b65c0805201015g7a3cfc7bg46712387ee523eeb@mail.gmail.com>
References: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>
	<7a93bd340805201006v485077ddu232df514f57e4ca5@mail.gmail.com>
	<37f8b65c0805201015g7a3cfc7bg46712387ee523eeb@mail.gmail.com>
Message-ID: <7a93bd340805201031w473e3812n83b1a7fe0358a2d4@mail.gmail.com>

If you use

render :widget => MyWidget

or put your widgets in the app/views directory and use normal Rails implicit
rendering (based on controller/action name) or use

render :template => 'foo/bar'

as documented on
http://erector.rubyforge.org/documentation.html#usingerectorfromrubyonrails

...then it will happen automatically. The code inside
erector/extensions/action_controller.rb and action_view_template.rb passes
in the @template or @view object, which is the thing in Railsland that
actually implements all those Rails helper methods.

If you construct your own widget you have to pass in a helpers object inside
the constructor. It defaults to nil because Erector doesn't require Rails so
we don't want to force people to use Rails helpers if they don't want to.

Note that there are lots of helpers we haven't dealt with yet, in part
because we're lazy, and also because each one needs to be examined
individually since the method semantics are inconsistent. (Some html-escape
their first parameter and some don't; some take a block and some don't; some
return a string and some render a string onto the output stream...) So if
you find a helper we don't support yet, please let us know and/or patch it
in to helpers.rb yourself. Ideally we'd create a widget library of our own
to make Rails helpers unnecessary, but I respect the need to keep supporting
Rails helpers for the forseeable future.

One more thing: after my work this weekend, I noticed a bug in one of the
form methods (form_for or form_tag) so be careful about using them until
I've had a chance to track it down. The bug involves the aforementioned
confusion between emitting and returning -- it ends up outputting the
insides of the form before the form tag itself.

 - A

On Tue, May 20, 2008 at 10:15 AM, Rami Grossman <ramigg at gmail.com> wrote:

> I tried both versions.The same problem in both.
> I don't understand where the helpers variable is initialized first. I saw
> that in widget.rb it defaults helpers to nil. So I have to pass it
> somewhere.
> Can you give a simple example of widget with rails helpers?
>



-- 
Alex Chaffee - Pivotal Labs
alex at PivotalLabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080520/01ce971f/attachment.html>

From ramigg at gmail.com  Tue May 20 14:46:19 2008
From: ramigg at gmail.com (Rami Grossman)
Date: Tue, 20 May 2008 21:46:19 +0300
Subject: [Erector-devel] Problem using helpers
In-Reply-To: <7a93bd340805201031w473e3812n83b1a7fe0358a2d4@mail.gmail.com>
References: <37f8b65c0805200903td8a9e6aqb07b5264fe72d2d1@mail.gmail.com>
	<7a93bd340805201006v485077ddu232df514f57e4ca5@mail.gmail.com>
	<37f8b65c0805201015g7a3cfc7bg46712387ee523eeb@mail.gmail.com>
	<7a93bd340805201031w473e3812n83b1a7fe0358a2d4@mail.gmail.com>
Message-ID: <37f8b65c0805201146u578325f8pf55450866502c26b@mail.gmail.com>

Great!Thanks

Now it works.

I did in my controller:
render :text widgetclass.new(myparams).to_s
Thats why helpers was not initialized.
The correct way is to do render :widget => widgetclass, myparams
or render :text widgetclass.new(@template, myparams).to_s

On Tue, May 20, 2008 at 8:31 PM, Alex Chaffee <alex at pivotallabs.com> wrote:

> If you use
>
> render :widget => MyWidget
>
> or put your widgets in the app/views directory and use normal Rails
> implicit rendering (based on controller/action name) or use
>
> render :template => 'foo/bar'
>
> as documented on
> http://erector.rubyforge.org/documentation.html#usingerectorfromrubyonrails
>
> ...then it will happen automatically. The code inside
> erector/extensions/action_controller.rb and action_view_template.rb passes
> in the @template or @view object, which is the thing in Railsland that
> actually implements all those Rails helper methods.
>
> If you construct your own widget you have to pass in a helpers object
> inside the constructor. It defaults to nil because Erector doesn't require
> Rails so we don't want to force people to use Rails helpers if they don't
> want to.
>
> Note that there are lots of helpers we haven't dealt with yet, in part
> because we're lazy, and also because each one needs to be examined
> individually since the method semantics are inconsistent. (Some html-escape
> their first parameter and some don't; some take a block and some don't; some
> return a string and some render a string onto the output stream...) So if
> you find a helper we don't support yet, please let us know and/or patch it
> in to helpers.rb yourself. Ideally we'd create a widget library of our own
> to make Rails helpers unnecessary, but I respect the need to keep supporting
> Rails helpers for the forseeable future.
>
> One more thing: after my work this weekend, I noticed a bug in one of the
> form methods (form_for or form_tag) so be careful about using them until
> I've had a chance to track it down. The bug involves the aforementioned
> confusion between emitting and returning -- it ends up outputting the
> insides of the form before the form tag itself.
>
>  - A
>
>
> On Tue, May 20, 2008 at 10:15 AM, Rami Grossman <ramigg at gmail.com> wrote:
>
>> I tried both versions.The same problem in both.
>> I don't understand where the helpers variable is initialized first. I saw
>> that in widget.rb it defaults helpers to nil. So I have to pass it
>> somewhere.
>> Can you give a simple example of widget with rails helpers?
>>
>
>
>
> --
> Alex Chaffee - Pivotal Labs
> alex at PivotalLabs.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080520/f402fc05/attachment.html>

From alex at pivotallabs.com  Thu May 29 12:37:44 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 09:37:44 -0700
Subject: [Erector-devel] Erector lighthouse account
Message-ID: <7a93bd340805290937p72fed14al5a9d050430d8128@mail.gmail.com>

Brian Takita just set up http://erector.lighthouseapp.com for us.

I'll update the web site and developer guide accordingly. Brian, who's going
to transfer all the Tracker stories over?

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/d801c412/attachment.html>

From alex at pivotallabs.com  Thu May 29 12:58:06 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 09:58:06 -0700
Subject: [Erector-devel] current status of Erector
In-Reply-To: <8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
References: <8d0d70270805281413y4fc10f02i72289260a65728fb@mail.gmail.com>
	<1d7ddd110805281625j6a054c7emc11188d9ee7a38fb@mail.gmail.com>
	<7a93bd340805281654p69feb18ak19b98c28dc546c98@mail.gmail.com>
	<8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
Message-ID: <7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>

(On a separate thread, Nathan mentioned some problems he was having with
Erector; I thought I should move the technical part of the discussion over
to erector-devel.)


> Typical Rails template handling would support both *.html.rb (for explicit
> :format => 'html') and *.rb (for no format) template files.  The Erector gem
> assumed a *.rb format, and would not detect a *.html.rb for implicit render
> situations, situations where a controller did not have any render command at
> all.  I hacked the file grep accordingly.  (the guide assumes you're putting
> a 'render' command in your action)
>

Sounds good. I don't see it in action_view_template_handler.rb though...
Have you checked it in?

And when you do, please update History.txt for release notes.


> Onto incompletely initialized state. Compiled templates, among other
> things, mirror the assigns variables to instance variables on the
> ActionView::Base object.  Because Erector doesn't use compiled templates,
> this step didn't happen.  The assigns variables existed, but not the
> instance variables.. so helpers like error_messages_for didn't have them.
> Adding the appropriate method call solved this issue.
>

I've fixed this on my branch (adding an "assign_locals" method to Widget and
calling it from the render_with_erector method). Again, I can't see where
you've done it.


>
> One simple suggestion I'd have would be to rename the helpers property to
> 'view' on the widget class.
>

Great idea. I'll deprecate "helpers" in favor of "view" soon.


>
> form_tag doesn't work because it relies on ActionView's capture method.
> This method cleans up actionview's buffer of rendered output after it
> captures a string from it.  Unfortunately, it doesn't clean up Erector's
> buffer of rendered output, so extra text shows up.  Jim has some test cases
> that we put together for them.
>

This exemplifies Rails helper nastiness. We need to figure out for all
helpers which ones return a string, which ones render text to the output
stream, and which do some wacky nonsense like form_tag, and make friendly
wrappers for all of them that just do the right thing, erector-style, when
called (i.e. render to the stream). I've started that in helpers.rb and
rails_helpers_spec.rb but it's nowhere near complete or even correct as it
is at present.

> Error_messages_for didn't work, because the
> ActionView::Base class was incompletely initialized.

I was struggling with this last weekend. I got stuck because I couldn't tell
which object "self" was supposed to be, that has an instance variable that's
the named model object, or when to set it. Did you solve it?


> The straw that finally
> broke my back was my attempt to use form_tag.  Form_tag (and form_for)
rely
> on manipulating the output stream directly rather than streaming a string.

I mentioned this bug on erector-devel last week. (This is one of those Rails
API inconsistencies -- sometimes the helpers return a string, sometimes they
emit text to the stream; sometimes they HTML escape their parameter,
sometimes they don't; sometimes they take an options hash, sometimes an
htmloptions hash, sometimes they're merged, sometimes they ignore certain
keys -- that led us to want to replace the Rails helpers with something more
OO.)

> I believe that Erector needs to be split up into multiple open source
projects with more clear definitions.

*> erector-core* - Allows you to create view objects that can stream HTML
anywhere you choose.  Does not make any effort to integrate with any
particular framework such as Rails or MERB.
* > erector-rails* - Defines a Rails adaptor for Erector.  Allows *.rb files
in your views directory to be understood as Erector templates.  Provides
full integration with Rails controllers, view helpers, and model assignment.
*> erector-merb* - Defines a MERB adaptor for Erector.


I agree with your sub-projects but I don't want to split it into different
OS projects yet. That makes versioning a nightmare and we can get the same
feature divisions with optional requires. For instance, to use Rails
integration you'd say "require 'erector/rails'" in environment.rb, which
would reopen Widget and include Helpers (as well as the other Rails stuff).


> The Erector core project is in the best shape right now.  Some
improvements may involve:
>  - working with a stream or buffer object rather than TagList objects


We need to do some performance benchmarks before we decide to rearchitect
the output stream.


  > - supporting indenting (the HTML Erector produces is not human-readable)


Agreed, and this shouldn't be hard to work into to_s.


 > - dropping Rails-isms from the project (see what Pat did with his MERB
integration)


I think if you say "require 'erector'" you should get only core erector, and
if you say "require 'erector/rails'" you get the Rails integration, and
"require 'erector/merb'" you get whatever extra stuff Merb needs.


> The Erector MERB project is likely to be very small and many even be
unnecessary.



> The Erector Rails project is in bad shape.  The architecture of adding
many properties to the widget class to link back to the ActionView doesn't
work well for capturing text, as the view has no idea what widgets are being
rendered when it gets to a capture.  Some other missing things -

  - support for layouts and partials
  - being able to compile your templates
  - supporting multiple formats in your template files (*.js.rb, *.html.rb)


Partials work. Layouts are problematic since there's a big conceptual
mismatch with the whole content_for/yield design, but we have an alternate
mechanism -- make the layout a superclass and use the Template Method
Pattern to call down to the content pieces.

I believe compiling support is unnecessary since we use require and our
templates are ruby files. But I might be wrong cause I don't really know
what it means for Rails to compile a template.


>
> >   - supporting multiple formats in your template files (*.js.rb,
> *.html.rb)
>


> (Brian Takita:) Erector is an Xml builder. I don't think it makes sense for
> it to
> support javascript. That being said, it should follow the normal Rails
> template name conventions.


Yeah, although one thing Erector doesn't support yet is content-type. It
would be nice if a widget could be asked what content type it is (XML or
HTML or XHTML or whatever) and then the Rails render method would write that
to the response.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/027f2d08/attachment-0001.html>

From alex at pivotallabs.com  Thu May 29 13:38:10 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 10:38:10 -0700
Subject: [Erector-devel] About the Erector project
In-Reply-To: <37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
Message-ID: <7a93bd340805291038j8328c4bo9062fcd93fbe5e3d@mail.gmail.com>

On Mon, May 5, 2008 at 2:50 AM, Rami Grossman <ramigg at gmail.com> wrote:

> Hi Alex,I don't have experience with unit tests. Never did those. I know
> it's not good and I now have a programmer that will write unit test for what
> we wrote till now, but it will take time.
> Anyway I hope you commit this code to repository, without that Erector will
> work only in 'app/views' subfolder, and Rails gives the functionality to
> customize it, so I think Erector should also support it.
>

Rami, I've applied your patch (slightly cleaned up) as revision 102. Thanks!

(Still no tests, though. I'm often confused as to how to test Rails
integration stuff since it relies so much on Rails internals.)

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/7aad8b09/attachment.html>

From brian at pivotallabs.com  Thu May 29 14:05:14 2008
From: brian at pivotallabs.com (Brian Takita)
Date: Thu, 29 May 2008 11:05:14 -0700
Subject: [Erector-devel] Erector lighthouse account
In-Reply-To: <7a93bd340805290937p72fed14al5a9d050430d8128@mail.gmail.com>
References: <7a93bd340805290937p72fed14al5a9d050430d8128@mail.gmail.com>
Message-ID: <1d7ddd110805291105v2893fbdbrd9af1de7d64e875d@mail.gmail.com>

On Thu, May 29, 2008 at 9:37 AM, Alex Chaffee <alex at pivotallabs.com> wrote:
>
> Brian Takita just set up http://erector.lighthouseapp.com for us.
>
> I'll update the web site and developer guide accordingly. Brian, who's going
> to transfer all the Tracker stories over?
Thats a good question. I suppose that we could do all of our
planning/prioritization through Lighthouse. I didn't even think about
that.
We can probably remove the Erector project from Tracker and still
prioritize things in Common Effort.

I could go ahead and move stuff over.
>
> --
> Alex Chaffee
> alexch at gmail.com

From alex at pivotallabs.com  Thu May 29 15:59:51 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 12:59:51 -0700
Subject: [Erector-devel] about to release erector
Message-ID: <7a93bd340805291259t622270d2hf4e62fbfbd7e8bdd@mail.gmail.com>

With all the hubbub today I've decided to make a new gem release of erector.
I just spent a couple hours cleaning up the docs and site, too. Any
objections? Let me know within 10 minutes :-)

One thing I did is rename "documentation" to "user guide" and "motivation"
to "faq". Please please please read the FAQ (once it's live) and tell me if
I said anything patently false or silly.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/00f8b003/attachment.html>

From alex at pivotallabs.com  Thu May 29 18:11:27 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 15:11:27 -0700
Subject: [Erector-devel] Erector bug (... don't know how else to submit
	it)
In-Reply-To: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
Message-ID: <7a93bd340805291511s42604f21x12dcb0d3107aeb53@mail.gmail.com>

Thanks for the bug report. The proper channel at present is the
erector-devel mailing list. See http://erector.rubyforge.org for info. I'm
cc'ing the list for followup.

Indeed, the release I just put out (a minor release, which may add API
calls) has a new "url" convenience method on the Widget class that takes one
parameter. It broke because you're making use of Nick's "crazy
metaprogramming" -- which is actually just method_missing -- that makes it
so you can call methods on the enclosing class from inside the inline
widget. Now that "url" actually exists, method_missing is never called, so
your method is not used.

I've never been comfortable with the inline widget feature for exactly this
reason -- it makes things break in unexpected ways, and also makes it hard
to debug when such things break. One of the design goals of Erector was to
get away from exactly this kind of problem in Markaby.

One solution would be to stop using the "widget" method and instead use
"new" and constuctor-based dependency injection, like this:

class Bar < Erector::Widget
  def initialize(url)
    @url = url
  end
  def render
    p url
  end
end

class Foo < Erector::Widget
  def url
    "whatever"
  end
  def render
    text Bar.new(url)
  end
end

In this case the "text" method notices that its argument is a widget, and is
smart enough to pass the doc stream in and call its render method. Another
way -- which Jim argues should be deprecated -- is to call render_to, as in

def render
  Bar.new(url).render_to(self)
end



On Thu, May 29, 2008 at 2:22 PM, Jonathan Barnes <jonathan at pivotallabs.com>
wrote:

> alexch just committed a change to erector that broke one of our widgets:
> New revision 103 detected in external 'vendor/plugins/erector'
> Revision 103 committed by alexch on 2008-05-29 19:28:03
> Work on docs.  Rename motivation to faq. Also add 'url' convenience method
> to Widget.
> M /trunk/lib/erector/widget.rb
> A /trunk/web/article.rb
> A /trunk/web/article.html
> M /trunk/web/erector.css
> D /trunk/web/motivation.rb
> M /trunk/History.txt
> A /trunk/web/section.rb
> A /trunk/web/section.html
> A /trunk/web/faq.rb
> M /trunk/web/index.html
> M /trunk/web/developers.rb
> M /trunk/web/documentation.rb
> M /trunk/web/developers.html
> M /trunk/web/sidebar.rb
> M /trunk/web/sidebar.html
> M /trunk/web/documentation.html
> M /trunk/spec/erector/widget_spec.rb
> M /trunk/web/page.html
>
> In one of our erector classes we had defined a 'url' helper method without
> any parameters and calling it fine until this commit, but after this commit
> we started getting an error: 'wrong number of arguments (0 for 1)'.
>
> I find it really wierd that calling a method that is defined just a few
> lines earlier would cause such errors, or to put it another way, that
> somehow defining a new method in the superclass would have this kind of
> effect on my subclass.   I cannot replicate what is happening in Erector in
> a simple irb test case so I assume there is some crazy meta programming
> causing this.  Anyway we worked around it for our project but I am curious
> why it happened, and I personally would consider it a bug in Erector.
>
> I believe that the following two classes below would show the behavior we
> are seeing in the M7 project.  I look forward to your response.
>
> class Foo < Erector::Widget
>   def url
>     "http://example.com"
>   end
>
>   def render
>     widget Bar do
>       text url
>      end
>    end
> end
>
> class Bar < Erector::Widget
>   def render
>     super
>   end
> end
>



-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/b47e0d8d/attachment.html>

From alex at pivotallabs.com  Thu May 29 19:02:25 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 16:02:25 -0700
Subject: [Erector-devel] current status of Erector
In-Reply-To: <7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
References: <8d0d70270805281413y4fc10f02i72289260a65728fb@mail.gmail.com>
	<1d7ddd110805281625j6a054c7emc11188d9ee7a38fb@mail.gmail.com>
	<7a93bd340805281654p69feb18ak19b98c28dc546c98@mail.gmail.com>
	<8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
	<7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
Message-ID: <7a93bd340805291602o248d81dcxfffdb41556fe2594@mail.gmail.com>

>
>
>> form_tag doesn't work because it relies on ActionView's capture method.
>> This method cleans up actionview's buffer of rendered output after it
>> captures a string from it.  Unfortunately, it doesn't clean up Erector's
>> buffer of rendered output, so extra text shows up.  Jim has some test cases
>> that we put together for them.
>>
>
Thanks for making those test cases! I've now made them pass :-D

I'll be pushing a new release later today with the fix.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/d22d7ecb/attachment.html>

From alex at pivotallabs.com  Thu May 29 19:49:14 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Thu, 29 May 2008 16:49:14 -0700
Subject: [Erector-devel] Second release of the day
Message-ID: <7a93bd340805291649u3f2da38dx8f4d3c8593ce97ba@mail.gmail.com>

Just released erector 0.3.110 -- a rapid bugfix release.

* support capture from rails helpers, allowing form_for/form_tag to work
right
* fix bug in view_paths support (finding views was hosed)

The view_paths bug was directly due to the lack of functional tests for a
rails app. I think we need to add a functional test suite -- something that
makes a new rails app, runs Selenium tests, and then deletes the app.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080529/41ee7e99/attachment-0001.html>

From kingdon at panix.com  Thu May 29 23:12:42 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Thu, 29 May 2008 23:12:42 -0400 (EDT)
Subject: [Erector-devel] current status of Erector
In-Reply-To: <7a93bd340805291602o248d81dcxfffdb41556fe2594@mail.gmail.com>
	(alex@pivotallabs.com)
References: <8d0d70270805281413y4fc10f02i72289260a65728fb@mail.gmail.com>
	<1d7ddd110805281625j6a054c7emc11188d9ee7a38fb@mail.gmail.com>
	<7a93bd340805281654p69feb18ak19b98c28dc546c98@mail.gmail.com>
	<8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
	<7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
	<7a93bd340805291602o248d81dcxfffdb41556fe2594@mail.gmail.com>
Message-ID: <20080530031242.A0776241FF@panix5.panix.com>

> >> form_tag doesn't work because it relies on ActionView's capture
> >> method.
> . . .
> Thanks for making those test cases! I've now made them pass :-D

Cool!  Turns out I was on the right track in overriding capture in
fake_erbout, just had some details wrong.

Well, "right" in the sense of *something* that would work.  I wouldn't
be surprised if there is a cleaner way to structure this code.

From kingdon at panix.com  Fri May 30 01:00:48 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Fri, 30 May 2008 01:00:48 -0400 (EDT)
Subject: [Erector-devel] Erector bug (... don't know how else to
	submit	it)
In-Reply-To: <7a93bd340805291511s42604f21x12dcb0d3107aeb53@mail.gmail.com>
	(alex@pivotallabs.com)
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
	<7a93bd340805291511s42604f21x12dcb0d3107aeb53@mail.gmail.com>
Message-ID: <20080530050048.ADE49241FF@panix5.panix.com>

Thanks for the well-written bug report.  I've tried to clarify the
documentation for this method accordingly.

I'm inclined to agree with Alex that the inline widget ("crazy
metaprogramming") feature causes more trouble than it is worth.  It
just doesn't seem right to me that every new method in widget.rb
constitutes an incompatible change to the API (and furthermore, one
for which the symptoms of the breakage are not likely to clearly point
to the cause).  Furthermore, I find the code very hard to read - both
the Erector implementation, but more importantly, the client code
which is making use of this feature.  Perhaps if someone wants to
argue for keeping this feature they can supply a better-motivated
example, showing why it would be better than various alternatives.

> Another way -- which Jim argues should be deprecated -- is to call
> render_to, as in
> 
> def render
>   Bar.new(url).render_to(self)
> end

Well, yes, I like the other form better, but this kind of render_to
doesn't bother me as much as the render_to usage which exposes "doc"
to the caller.  As we've seen in the discussion thread about erector
buffering, there is every reason to imagine having erector handle its
buffering differently, and exposing the buffer as part of the API seem
like a bad idea in terms of those possible changes (and just in terms
of clearly defining responsibilities).

From kingdon at panix.com  Fri May 30 01:31:59 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Fri, 30 May 2008 01:31:59 -0400 (EDT)
Subject: [Erector-devel] Erector lighthouse account
In-Reply-To: <1d7ddd110805291105v2893fbdbrd9af1de7d64e875d@mail.gmail.com>
	(brian@pivotallabs.com)
References: <7a93bd340805290937p72fed14al5a9d050430d8128@mail.gmail.com>
	<1d7ddd110805291105v2893fbdbrd9af1de7d64e875d@mail.gmail.com>
Message-ID: <20080530053200.107A6241FF@panix5.panix.com>

> We can probably remove the Erector project from Tracker and still
> prioritize things in Common Effort.

That would be my instinct.  I'm not sure the concept of priorities
makes sense for Erector, as an open source project.  Now, Pivotal
should set its priorities, but most of what I do on Erector is on my
own time and we can only hope that we attract enough non-Pivotal
contributors that this isn't a corner case.

As for lighthouse, I looked at the site for a while but I didn't
really figure out what it means for me as an open source contributor.
Am I supposed to create an account?  Or somehow get added to an
erector account?  So I'm a bit confused about that.

If we want an Erector issue tracker for general use (not just
Pivotal), I would think that read-only access to all
bugs/feature-requests/etc without logging in would be pretty much at
the top of the desiderata.

From kingdon at panix.com  Fri May 30 01:40:08 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Fri, 30 May 2008 01:40:08 -0400 (EDT)
Subject: [Erector-devel] About the Erector project
In-Reply-To: <7a93bd340805291038j8328c4bo9062fcd93fbe5e3d@mail.gmail.com>
	(alex@pivotallabs.com)
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
	<7a93bd340805291038j8328c4bo9062fcd93fbe5e3d@mail.gmail.com>
Message-ID: <20080530054008.23894241FF@panix5.panix.com>

> (Still no tests, though. I'm often confused as to how to test Rails
> integration stuff since it relies so much on Rails internals.)

Well, you've seen spec/rails/standard_helpers_spec.rb and
spec/erector/rails_helpers_spec.rb (which should be combined, or at
least moved to the same directory, incidentally) which is sort of a
mixture of using parts of Rails and mocking out other parts.

Agreed about the (not avoidable in any obvious way) reliance on Rails
internals.  The current tests work with Rails 2.0.2 but I'm not sure I
have a lot of confidence about what would happen with an older or
newer version of Rails.

I suspect we are going to end up both with tests at this level, and
with some kind of integration test(s) which is more of a standard Rails
app.  Both Alex and Brian have said things along those lines.

From thewoolleyman at gmail.com  Fri May 30 04:56:52 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 30 May 2008 01:56:52 -0700
Subject: [Erector-devel] About the Erector project
In-Reply-To: <20080530054008.23894241FF@panix5.panix.com>
References: <37f8b65c0804230634k5693e662u78c6ed8b956f413e@mail.gmail.com>
	<7a93bd340804230805m5fa5f77am8cb00cd0490d4749@mail.gmail.com>
	<37f8b65c0804231146m60df16akcf2dcec844893755@mail.gmail.com>
	<7a93bd340804231242y585b04a7i2054019be6b54033@mail.gmail.com>
	<37f8b65c0805040236m4f73ddbcl6963e9200c24c6cb@mail.gmail.com>
	<7a93bd340805040750i6baf337cs4467507f80b6c6b4@mail.gmail.com>
	<37f8b65c0805050250x390716e8o70a2d270d25f745b@mail.gmail.com>
	<7a93bd340805291038j8328c4bo9062fcd93fbe5e3d@mail.gmail.com>
	<20080530054008.23894241FF@panix5.panix.com>
Message-ID: <e3af97510805300156m1c7c94b3g27c0f98a80ec1f60@mail.gmail.com>

On Thu, May 29, 2008 at 10:40 PM, Jim Kingdon <kingdon at panix.com> wrote:
> Agreed about the (not avoidable in any obvious way) reliance on Rails
> internals.  The current tests work with Rails 2.0.2 but I'm not sure I
> have a lot of confidence about what would happen with an older or
> newer version of Rails.

I predict it will break in unexpected ways :)  It is good to be
proactive about this sort of thing if you care about being compatible
against multiple versions (especially trunk/HEAD).

Using GemInstaller, we've automated testing against multiple versions
of Rails in CI.  You can hook it up so the version is automatically
determined by the name of the cruise.rb project.  This is very handy
for forward- and backward- compatibility testing against multiple
versions of a dependency.  Ask me next week for details if you want,
or check out how I did it for GemInstaller itself (which runs CI
against multiple rubygems versions).

-- Chad

From alex at pivotallabs.com  Fri May 30 11:21:34 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Fri, 30 May 2008 08:21:34 -0700
Subject: [Erector-devel] Erector bug (... don't know how else to submit
	it)
In-Reply-To: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
Message-ID: <7a93bd340805300821i7f3d9f2aie4bf100ce3db9236@mail.gmail.com>

> One solution would be to stop using the "widget" method and instead use
"new" and constuctor-based dependency injection

...of course, an easier fix would be to rename your url method to, like,
my_url.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080530/e6711947/attachment.html>

From brian.takita at gmail.com  Fri May 30 14:38:24 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 11:38:24 -0700
Subject: [Erector-devel] Using GitHub?
Message-ID: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>

I made a git clone of Erector on Github.
http://github.com/pivotal/erector

I'm also using git svn to merge the changes from git to the SVN repo.
I find that git is very effective in encouraging collaboration and
people to merge in changes.

How do you guys feel about using git instead of subversion for
Erector? We can also support both too.

Brian

From alex at pivotallabs.com  Fri May 30 15:14:02 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Fri, 30 May 2008 12:14:02 -0700
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
Message-ID: <7a93bd340805301214x385d6b7ej8b9b4609f0f43636@mail.gmail.com>

All the release procedures are based on svn so we need to maintain that but
I'm open to using git too as long as we can go back and forth smoothly. I
haven't used git svn yet -- got a pointer to a tutorial?


On Fri, May 30, 2008 at 11:38 AM, Brian Takita <brian.takita at gmail.com>
wrote:

> I made a git clone of Erector on Github.
> http://github.com/pivotal/erector
>
> I'm also using git svn to merge the changes from git to the SVN repo.
> I find that git is very effective in encouraging collaboration and
> people to merge in changes.
>
> How do you guys feel about using git instead of subversion for
> Erector? We can also support both too.
>
> Brian
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080530/9ac66a6e/attachment.html>

From brian.takita at gmail.com  Fri May 30 17:02:10 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 14:02:10 -0700
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <7a93bd340805301214x385d6b7ej8b9b4609f0f43636@mail.gmail.com>
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
	<7a93bd340805301214x385d6b7ej8b9b4609f0f43636@mail.gmail.com>
Message-ID: <1d7ddd110805301402w1c85f182s467b528ae836b9e6@mail.gmail.com>

On Fri, May 30, 2008 at 12:14 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> All the release procedures are based on svn so we need to maintain that but
> I'm open to using git too as long as we can go back and forth smoothly. I
> haven't used git svn yet -- got a pointer to a tutorial?
Actually, why did you choose to use the svn version? Just curious.

I don't remember there ever being a discussion about it. Was there a
discussion that I don't remember?
>
>
> On Fri, May 30, 2008 at 11:38 AM, Brian Takita <brian.takita at gmail.com>
> wrote:
>>
>> I made a git clone of Erector on Github.
>> http://github.com/pivotal/erector
>>
>> I'm also using git svn to merge the changes from git to the SVN repo.
>> I find that git is very effective in encouraging collaboration and
>> people to merge in changes.
>>
>> How do you guys feel about using git instead of subversion for
>> Erector? We can also support both too.
>>
>> Brian
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>
>
>
> --
> Alex Chaffee
> alexch at gmail.com

From brian.takita at gmail.com  Fri May 30 17:24:23 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 14:24:23 -0700
Subject: [Erector-devel] premature organization is the root of all...
	something
In-Reply-To: <7a93bd340805301216w4d0b69f9p7c0e567622d6f410@mail.gmail.com>
References: <7a93bd340805301216w4d0b69f9p7c0e567622d6f410@mail.gmail.com>
Message-ID: <1d7ddd110805301424i44306c70sb2e1b97c60e9444c@mail.gmail.com>

On Fri, May 30, 2008 at 12:16 PM, Alex Chaffee <alex at stinky.com> wrote:
> I'm worried that with 3 lighthouse projects (subprojects?) it'll be 3 times
> harder to figure out what's going on...
The dashboard allows prints all messages from all of the sub projects.

I think we should split out Erector core from the Rails plugin (in the code).

Splitting the projects on lighthouse means you need to file the ticket
under the appropriate project. Once the ticket is created or modified,
you can see it under the dashboard.
Looking for tickets means you would need to go to the project page
(core, rails, or merb).

We could move it all to a single page and that means all of the
tickets will be in one place. Lighthouse also has tags, so we could
use tags to organize the tickets.

I'll remove the other two repos.
>
> --
> Alex Chaffee
> alexch at gmail.com

From brian.takita at gmail.com  Fri May 30 17:25:31 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 14:25:31 -0700
Subject: [Erector-devel] premature organization is the root of all...
	something
In-Reply-To: <1d7ddd110805301424i44306c70sb2e1b97c60e9444c@mail.gmail.com>
References: <7a93bd340805301216w4d0b69f9p7c0e567622d6f410@mail.gmail.com>
	<1d7ddd110805301424i44306c70sb2e1b97c60e9444c@mail.gmail.com>
Message-ID: <1d7ddd110805301425o42d29342ud71d36d71f5557aa@mail.gmail.com>

On Fri, May 30, 2008 at 2:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Fri, May 30, 2008 at 12:16 PM, Alex Chaffee <alex at stinky.com> wrote:
>> I'm worried that with 3 lighthouse projects (subprojects?) it'll be 3 times
>> harder to figure out what's going on...
> The dashboard allows prints all messages from all of the sub projects.
>
> I think we should split out Erector core from the Rails plugin (in the code).
>
> Splitting the projects on lighthouse means you need to file the ticket
> under the appropriate project. Once the ticket is created or modified,
> you can see it under the dashboard.
> Looking for tickets means you would need to go to the project page
> (core, rails, or merb).
>
> We could move it all to a single page and that means all of the
> tickets will be in one place. Lighthouse also has tags, so we could
> use tags to organize the tickets.
>
> I'll remove the other two repos.
If we want to go back, say something and I can add them back.

Also, I'm going to ask somebody at Pivotal to get a Bronze account on
Lighthouse so we can have more admins.
>>
>> --
>> Alex Chaffee
>> alexch at gmail.com
>

From brian.takita at gmail.com  Fri May 30 18:12:39 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 15:12:39 -0700
Subject: [Erector-devel] premature organization is the root of all...
	something
In-Reply-To: <1d7ddd110805301425o42d29342ud71d36d71f5557aa@mail.gmail.com>
References: <7a93bd340805301216w4d0b69f9p7c0e567622d6f410@mail.gmail.com>
	<1d7ddd110805301424i44306c70sb2e1b97c60e9444c@mail.gmail.com>
	<1d7ddd110805301425o42d29342ud71d36d71f5557aa@mail.gmail.com>
Message-ID: <1d7ddd110805301512m742662e6x37ce5841acba2214@mail.gmail.com>

On Fri, May 30, 2008 at 2:25 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Fri, May 30, 2008 at 2:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> On Fri, May 30, 2008 at 12:16 PM, Alex Chaffee <alex at stinky.com> wrote:
>>> I'm worried that with 3 lighthouse projects (subprojects?) it'll be 3 times
>>> harder to figure out what's going on...
>> The dashboard allows prints all messages from all of the sub projects.
>>
>> I think we should split out Erector core from the Rails plugin (in the code).
>>
>> Splitting the projects on lighthouse means you need to file the ticket
>> under the appropriate project. Once the ticket is created or modified,
>> you can see it under the dashboard.
>> Looking for tickets means you would need to go to the project page
>> (core, rails, or merb).
>>
>> We could move it all to a single page and that means all of the
>> tickets will be in one place. Lighthouse also has tags, so we could
>> use tags to organize the tickets.
>>
>> I'll remove the other two repos.
> If we want to go back, say something and I can add them back.
Hmm, I havn't figured out on how to delete a page. Ill try to find out
how to do that here.
>
> Also, I'm going to ask somebody at Pivotal to get a Bronze account on
> Lighthouse so we can have more admins.
>>>
>>> --
>>> Alex Chaffee
>>> alexch at gmail.com
>>
>

From brian.takita at gmail.com  Fri May 30 18:15:28 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 15:15:28 -0700
Subject: [Erector-devel] premature organization is the root of all...
	something
In-Reply-To: <1d7ddd110805301512m742662e6x37ce5841acba2214@mail.gmail.com>
References: <7a93bd340805301216w4d0b69f9p7c0e567622d6f410@mail.gmail.com>
	<1d7ddd110805301424i44306c70sb2e1b97c60e9444c@mail.gmail.com>
	<1d7ddd110805301425o42d29342ud71d36d71f5557aa@mail.gmail.com>
	<1d7ddd110805301512m742662e6x37ce5841acba2214@mail.gmail.com>
Message-ID: <1d7ddd110805301515r8efa430qe641ab07b9b78fb7@mail.gmail.com>

On Fri, May 30, 2008 at 3:12 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Fri, May 30, 2008 at 2:25 PM, Brian Takita <brian.takita at gmail.com> wrote:
>> On Fri, May 30, 2008 at 2:24 PM, Brian Takita <brian.takita at gmail.com> wrote:
>>> On Fri, May 30, 2008 at 12:16 PM, Alex Chaffee <alex at stinky.com> wrote:
>>>> I'm worried that with 3 lighthouse projects (subprojects?) it'll be 3 times
>>>> harder to figure out what's going on...
>>> The dashboard allows prints all messages from all of the sub projects.
>>>
>>> I think we should split out Erector core from the Rails plugin (in the code).
>>>
>>> Splitting the projects on lighthouse means you need to file the ticket
>>> under the appropriate project. Once the ticket is created or modified,
>>> you can see it under the dashboard.
>>> Looking for tickets means you would need to go to the project page
>>> (core, rails, or merb).
>>>
>>> We could move it all to a single page and that means all of the
>>> tickets will be in one place. Lighthouse also has tags, so we could
>>> use tags to organize the tickets.
>>>
>>> I'll remove the other two repos.
>> If we want to go back, say something and I can add them back.
> Hmm, I havn't figured out on how to delete a page. Ill try to find out
> how to do that here.
Nm, I figured it out. Its done.
>>
>> Also, I'm going to ask somebody at Pivotal to get a Bronze account on
>> Lighthouse so we can have more admins.
>>>>
>>>> --
>>>> Alex Chaffee
>>>> alexch at gmail.com
>>>
>>
>

From brian.takita at gmail.com  Fri May 30 18:19:45 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 15:19:45 -0700
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <7a93bd340805301214x385d6b7ej8b9b4609f0f43636@mail.gmail.com>
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
	<7a93bd340805301214x385d6b7ej8b9b4609f0f43636@mail.gmail.com>
Message-ID: <1d7ddd110805301519w127f33d2y1a7f9280ce4523cc@mail.gmail.com>

On Fri, May 30, 2008 at 12:14 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> All the release procedures are based on svn so we need to maintain that but
> I'm open to using git too as long as we can go back and forth smoothly. I
> haven't used git svn yet -- got a pointer to a tutorial?
http://tsunanet.blogspot.com/2007/07/learning-git-svn-in-5min.html
http://git.or.cz/course/svn.html
>
>
> On Fri, May 30, 2008 at 11:38 AM, Brian Takita <brian.takita at gmail.com>
> wrote:
>>
>> I made a git clone of Erector on Github.
>> http://github.com/pivotal/erector
>>
>> I'm also using git svn to merge the changes from git to the SVN repo.
>> I find that git is very effective in encouraging collaboration and
>> people to merge in changes.
>>
>> How do you guys feel about using git instead of subversion for
>> Erector? We can also support both too.
>>
>> Brian
>> _______________________________________________
>> Erector-devel mailing list
>> Erector-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/erector-devel
>
>
>
> --
> Alex Chaffee
> alexch at gmail.com

From brian.takita at gmail.com  Fri May 30 18:59:48 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 15:59:48 -0700
Subject: [Erector-devel] Changing Erector email from alex@pivotallabs.com to
	erector-devel@rubyforge.org
Message-ID: <1d7ddd110805301559x3ed46332w23405f23d110741e@mail.gmail.com>

Hello, I would like to change the official Erector email from
alex at pivotallabs.com to erector-devel at rubyforge.org. Does anybody have
any objections?

Thanks,
Brian

From brian.takita at gmail.com  Fri May 30 20:17:39 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 17:17:39 -0700
Subject: [Erector-devel] Erector bug (... don't know how else to submit
	it)
In-Reply-To: <b6bf28ec0805301556q70c13a7at13135a415f0053c9@mail.gmail.com>
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
	<7a93bd340805300821i7f3d9f2aie4bf100ce3db9236@mail.gmail.com>
	<b6bf28ec0805301556q70c13a7at13135a415f0053c9@mail.gmail.com>
Message-ID: <1d7ddd110805301717u135198d5j9b5428d731473f44@mail.gmail.com>

On Fri, May 30, 2008 at 3:56 PM, Jonathan Barnes
<jonathan at pivotallabs.com> wrote:
> I did that.  I have to say we use the widget method all the time, and I
> really like it.  The alternative that Alex posted I think is much uglier and
> when dealing with view code you really want to minimize the ugliness.
>
> Often the way we use this code is to create custom view components like
> Blocks and Block.  Blocks for us are essentially Unordered list wrappers
> with a bunch of custom styling.  A Block is a container that has a few
> sections like a Title, and Behaviors plus the body etc.
>
> The crazy meta programming widget method allows me to do things like the
> following:
>
> widget Blocks do
>   widget Block, :title => "Bock 1", :behaviors => buttons do
>     p "my crazy blocks example"
>   end
>   widget Block, :title => "Bock 2", :behaviors => other_buttons do
>     div do
>       text "and here is another"
>       span "crazy block"
>   end
> end
>
> The widget method allows me to use my custom blocks in the same way I would
> div's, or span's or whatever.
>
> just my ?2
+1 I think the widget method does make the view code more declarative.
>
> -Jonathan
>
> On Fri, May 30, 2008 at 8:21 AM, Alex Chaffee <alex at pivotallabs.com> wrote:
>>
>> > One solution would be to stop using the "widget" method and instead use
>> > "new" and constuctor-based dependency injection
>>
>> ...of course, an easier fix would be to rename your url method to, like,
>> my_url.
>>
>> --
>> Alex Chaffee
>> alexch at gmail.com
>

From kingdon at panix.com  Fri May 30 23:35:48 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Fri, 30 May 2008 23:35:48 -0400 (EDT)
Subject: [Erector-devel] Erector bug (... don't know how else to
	submit	it)
In-Reply-To: <1d7ddd110805301717u135198d5j9b5428d731473f44@mail.gmail.com>
	(brian.takita@gmail.com)
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
	<7a93bd340805300821i7f3d9f2aie4bf100ce3db9236@mail.gmail.com>
	<b6bf28ec0805301556q70c13a7at13135a415f0053c9@mail.gmail.com>
	<1d7ddd110805301717u135198d5j9b5428d731473f44@mail.gmail.com>
Message-ID: <20080531033548.1D1FE241FF@panix5.panix.com>

> > Often the way we use this code is to create custom view components like
> > Blocks and Block.

I have completed this example at:

http://erector.rubyforge.org/svn/trunk/examples/blocks-via-widget.rb

I had to guess on some parts, and might have missed some important
piece.

I've posted a rewrite at:

http://erector.rubyforge.org/svn/trunk/examples/blocks-via-methods.rb

In this specific example, it generates the same output and seems
simpler.  Which probably means I've missed some subtlety of the
#widget solution.  If so, please speak up or elaborate the example.

From kingdon at panix.com  Sat May 31 00:05:24 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sat, 31 May 2008 00:05:24 -0400 (EDT)
Subject: [Erector-devel] Changing Erector email from
	alex@pivotallabs.com to	erector-devel@rubyforge.org
In-Reply-To: <1d7ddd110805301559x3ed46332w23405f23d110741e@mail.gmail.com>
	(brian.takita@gmail.com)
References: <1d7ddd110805301559x3ed46332w23405f23d110741e@mail.gmail.com>
Message-ID: <20080531040524.9786E241FF@panix5.panix.com>

> Hello, I would like to change the official Erector email from
> alex at pivotallabs.com to erector-devel at rubyforge.org. Does anybody have
> any objections?

Of course not.  I'm surprised it has taken us this long to get around
to changing this.

Alex, of course, is encouraged to reply via the mailing list.

From kingdon at panix.com  Sat May 31 00:56:34 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sat, 31 May 2008 00:56:34 -0400 (EDT)
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
	(brian.takita@gmail.com)
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
Message-ID: <20080531045634.E1F9B241FF@panix5.panix.com>

> How do you guys feel about using git instead of subversion for
> Erector? We can also support both too.

Oh, my herd instinct says git, although I suspect my own life would
probably be easier with svn, unless there is something I don't know
about using git in an svn-like way (that is, frequent checkins and
little branching).

> I made a git clone of Erector on Github.

When I try to clone it, I get the following error:

$ git-clone http://github.com/pivotal/erector
Initialized empty Git repository in
/home/kingdon/zwork/git-erector/erector/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
$ 

From brian.takita at gmail.com  Sat May 31 01:12:39 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 30 May 2008 22:12:39 -0700
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <20080531045634.E1F9B241FF@panix5.panix.com>
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
	<20080531045634.E1F9B241FF@panix5.panix.com>
Message-ID: <1d7ddd110805302212u6fb56f1bp6b6ab36ad9531381@mail.gmail.com>

On Fri, May 30, 2008 at 9:56 PM, Jim Kingdon <kingdon at panix.com> wrote:
>> How do you guys feel about using git instead of subversion for
>> Erector? We can also support both too.
>
> Oh, my herd instinct says git, although I suspect my own life would
> probably be easier with svn, unless there is something I don't know
> about using git in an svn-like way (that is, frequent checkins and
> little branching).
>
>> I made a git clone of Erector on Github.
>
> When I try to clone it, I get the following error:
>
> $ git-clone http://github.com/pivotal/erector
> Initialized empty Git repository in
> /home/kingdon/zwork/git-erector/erector/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
git clone git at github.com:pivotal/erector.git

You will need to be added as a collaborator first though. What is your
github account name?
> $
>

From kingdon at panix.com  Sat May 31 01:51:32 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sat, 31 May 2008 01:51:32 -0400 (EDT)
Subject: [Erector-devel] current status of Erector
In-Reply-To: <7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
	(alex@pivotallabs.com)
References: <8d0d70270805281413y4fc10f02i72289260a65728fb@mail.gmail.com>
	<1d7ddd110805281625j6a054c7emc11188d9ee7a38fb@mail.gmail.com>
	<7a93bd340805281654p69feb18ak19b98c28dc546c98@mail.gmail.com>
	<8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
	<7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
Message-ID: <20080531055132.9F787241FF@panix5.panix.com>

> Layouts are problematic since there's a big conceptual mismatch with
> the whole content_for/yield design, but we have an alternate mechanism
> -- make the layout a superclass and use the Template Method Pattern to
> call down to the content pieces.

That alternate mechanism only works if both the layout and the content
piece are in Erector.  But there are reasons to mix and match, for
example:

* You are writing a plugin, but you don't want your users to have to
use the same rendering library that you do.

* You are converting a codebase from one rendering library to
another.  It would be nice to convert each piece as you feel like it
and get around to it, rather than having to follow an arbitrary order
like "layouts must be done first" or "layouts must be done last".

It currently works to have a HAML layout and an Erector content
piece.  I haven't looked into what would be required to do the
reverse, but based on my limited knowledge to date, I'm not sure why
it would be impossible (especially if "yield" wouldn't have to be
spelled "yield" in an erector layout).

From kingdon at panix.com  Sat May 31 02:18:09 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sat, 31 May 2008 02:18:09 -0400 (EDT)
Subject: [Erector-devel] Using GitHub?
In-Reply-To: <1d7ddd110805302212u6fb56f1bp6b6ab36ad9531381@mail.gmail.com>
	(brian.takita@gmail.com)
References: <1d7ddd110805301138r29d5281cs7e18be43692fc944@mail.gmail.com>
	<20080531045634.E1F9B241FF@panix5.panix.com>
	<1d7ddd110805302212u6fb56f1bp6b6ab36ad9531381@mail.gmail.com>
Message-ID: <20080531061809.7A634241FF@panix5.panix.com>

> git clone git at github.com:pivotal/erector.git
> You will need to be added as a collaborator first though. What is your
> github account name?

Uh, OK, although I don't yet have enough git (or github) understanding
to do anything useful as a collaborator.

The command I was really looking for (for the moment, anyway) was:
git clone git://github.com/pivotal/erector.git

From alex at pivotallabs.com  Sat May 31 09:58:52 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 31 May 2008 06:58:52 -0700
Subject: [Erector-devel] current status of Erector
In-Reply-To: <20080531055132.9F787241FF@panix5.panix.com>
References: <8d0d70270805281413y4fc10f02i72289260a65728fb@mail.gmail.com>
	<1d7ddd110805281625j6a054c7emc11188d9ee7a38fb@mail.gmail.com>
	<7a93bd340805281654p69feb18ak19b98c28dc546c98@mail.gmail.com>
	<8d0d70270805281824q15c305cal7b3ab1dca93308f1@mail.gmail.com>
	<7a93bd340805290958t36b04fdfu19628766d97b2ec2@mail.gmail.com>
	<20080531055132.9F787241FF@panix5.panix.com>
Message-ID: <7a93bd340805310658n2970e992xa60762ada05e76c2@mail.gmail.com>

Here's all the docs we have on mixing layouts and templates from different
systems:
http://erector.rubyforge.org/userguide.html#layoutinheritance
(near the bottom of the section).

On Fri, May 30, 2008 at 10:51 PM, Jim Kingdon <kingdon at panix.com> wrote:

> > Layouts are problematic since there's a big conceptual mismatch with
> > the whole content_for/yield design, but we have an alternate mechanism
> > -- make the layout a superclass and use the Template Method Pattern to
> > call down to the content pieces.
>
> That alternate mechanism only works if both the layout and the content
> piece are in Erector.  But there are reasons to mix and match, for
> example:
>
> * You are writing a plugin, but you don't want your users to have to
> use the same rendering library that you do.
>
> * You are converting a codebase from one rendering library to
> another.  It would be nice to convert each piece as you feel like it
> and get around to it, rather than having to follow an arbitrary order
> like "layouts must be done first" or "layouts must be done last".
>
> It currently works to have a HAML layout and an Erector content
> piece.  I haven't looked into what would be required to do the
> reverse, but based on my limited knowledge to date, I'm not sure why
> it would be impossible (especially if "yield" wouldn't have to be
> spelled "yield" in an erector layout).
>



-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080531/5a79611f/attachment.html>

From alex at pivotallabs.com  Sat May 31 10:02:41 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 31 May 2008 07:02:41 -0700
Subject: [Erector-devel] Changing Erector email from
	alex@pivotallabs.com to erector-devel@rubyforge.org
In-Reply-To: <20080531040524.9786E241FF@panix5.panix.com>
References: <1d7ddd110805301559x3ed46332w23405f23d110741e@mail.gmail.com>
	<20080531040524.9786E241FF@panix5.panix.com>
Message-ID: <7a93bd340805310702q1494cfa1yfded5c23421c1a37@mail.gmail.com>

Go for it. "rake web publish_web" will redo the site.

On Fri, May 30, 2008 at 9:05 PM, Jim Kingdon <kingdon at panix.com> wrote:

> > Hello, I would like to change the official Erector email from
> > alex at pivotallabs.com to erector-devel at rubyforge.org. Does anybody have
> > any objections?
>
> Of course not.  I'm surprised it has taken us this long to get around
> to changing this.
>
> Alex, of course, is encouraged to reply via the mailing list.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080531/fca3a9d4/attachment.html>

From alex at pivotallabs.com  Sat May 31 14:17:56 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 31 May 2008 11:17:56 -0700
Subject: [Erector-devel] Erector bug (... don't know how else to submit
	it)
In-Reply-To: <20080531033548.1D1FE241FF@panix5.panix.com>
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
	<7a93bd340805300821i7f3d9f2aie4bf100ce3db9236@mail.gmail.com>
	<b6bf28ec0805301556q70c13a7at13135a415f0053c9@mail.gmail.com>
	<1d7ddd110805301717u135198d5j9b5428d731473f44@mail.gmail.com>
	<20080531033548.1D1FE241FF@panix5.panix.com>
Message-ID: <7a93bd340805311117p25d4d753j724a7a8c043c1ca1@mail.gmail.com>

Jim -

I love your example and it makes my point much better than I did. The idiom
is classic Ruby: pass in a block to a method, and invoke it with yield. It
also allows use of enclosing-class scope naturally, without use of
method-missing and passing down a reference to @parent.

You did miss a feature: use of enclosing-class scope. I've just added that
so the svn links below now have a "username" property.

 - A

On Fri, May 30, 2008 at 8:35 PM, Jim Kingdon <kingdon at panix.com> wrote:

> > > Often the way we use this code is to create custom view components like
> > > Blocks and Block.
>
> I have completed this example at:
>
> http://erector.rubyforge.org/svn/trunk/examples/blocks-via-widget.rb
>
> I had to guess on some parts, and might have missed some important
> piece.
>
> I've posted a rewrite at:
>
> http://erector.rubyforge.org/svn/trunk/examples/blocks-via-methods.rb
>
> In this specific example, it generates the same output and seems
> simpler.  Which probably means I've missed some subtlety of the
> #widget solution.  If so, please speak up or elaborate the example.
> _______________________________________________
> Erector-devel mailing list
> Erector-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/erector-devel
>



-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080531/c2dcad7b/attachment.html>

From brian.takita at gmail.com  Sat May 31 15:20:23 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 12:20:23 -0700
Subject: [Erector-devel] Erector bug (... don't know how else to submit
	it)
In-Reply-To: <20080531033548.1D1FE241FF@panix5.panix.com>
References: <b6bf28ec0805291422l6d24e3bbn2a4e2c6baddd70d1@mail.gmail.com>
	<7a93bd340805300821i7f3d9f2aie4bf100ce3db9236@mail.gmail.com>
	<b6bf28ec0805301556q70c13a7at13135a415f0053c9@mail.gmail.com>
	<1d7ddd110805301717u135198d5j9b5428d731473f44@mail.gmail.com>
	<20080531033548.1D1FE241FF@panix5.panix.com>
Message-ID: <1d7ddd110805311220r3f63c61eh1bc8a462f9ea3ff9@mail.gmail.com>

On Fri, May 30, 2008 at 8:35 PM, Jim Kingdon <kingdon at panix.com> wrote:
>> > Often the way we use this code is to create custom view components like
>> > Blocks and Block.
>
> I have completed this example at:
>
> http://erector.rubyforge.org/svn/trunk/examples/blocks-via-widget.rb
>
> I had to guess on some parts, and might have missed some important
> piece.
>
> I've posted a rewrite at:
>
> http://erector.rubyforge.org/svn/trunk/examples/blocks-via-methods.rb
>
> In this specific example, it generates the same output and seems
> simpler.  Which probably means I've missed some subtlety of the
> #widget solution.  If so, please speak up or elaborate the example.
>
The widget solution offers composition as a solution rather than
mixins (which is what we would need to do to reuse the blocks and
block method).
We are all pretty familiar over the strengths and weaknesses of
composition vs the mixin as a pattern.

In the case of Erector, you cannot namespace methods, so the widget
composition approach seems like it would lend itself to better named
domain view objects and clearer responsibilities.

Jon, what has your experience been?

----

One thing that Nick pointed out is Erector's core methods should be
prepended with '__' so users can define any method without having a
conflict.

From brian.takita at gmail.com  Sat May 31 17:20:56 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 14:20:56 -0700
Subject: [Erector-devel] Splitting Erector to a Gem and a Rails Plugin
Message-ID: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>

Ok, I was thinking that we should go ahead and split out Erector Core
and Erector Rails.
That will cause some changes in our repo.

I propose that we have:
http://erector.rubyforge.org/svn/erector-core/trunk
http://erector.rubyforge.org/svn/erector-rails/trunk

The Erector Rails project will have a Rails app thats either generated
or checked into the specs directory.

The erector-rails branch can either use the Erector gem, or load
Erector core into using externals or Piston.
I'd rather not use externals because I think it would cause issues
with git/svn and another when installing the plugin. It may be
technically feasible, but will require more work to manage in this
way.

The thing is alot of people do not like the Piston style workflow. I
don't mind it, but I'm not sure what you guys think.
The Piston workflow is:
You have 2 separate "projects". If you need to make a change to core,
you change core. You would then need to update the copy of core in
Erector rails. This seems somewhat clunky, especially since the core &
rails are in the same repo*.

* In the case of Git, they would be in 2 separate repos.

From brian.takita at gmail.com  Sat May 31 17:28:50 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 14:28:50 -0700
Subject: [Erector-devel] Going to switch @doc to use an IO stream
Message-ID: <1d7ddd110805311428i1183afd5o4628e6118acb2c2a@mail.gmail.com>

FYI, I'd like to switch @doc to be an IO stream. Jim had a great idea
to write directly to the ActionView::Base stream, when integrating
with Rails. This will bring up a step closer to trying that
experiment.

From brian.takita at gmail.com  Sat May 31 18:46:38 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 15:46:38 -0700
Subject: [Erector-devel] Going to switch @doc to use an IO stream
In-Reply-To: <1d7ddd110805311428i1183afd5o4628e6118acb2c2a@mail.gmail.com>
References: <1d7ddd110805311428i1183afd5o4628e6118acb2c2a@mail.gmail.com>
Message-ID: <1d7ddd110805311546y66dcb8f6ud71dcb727c7c6480@mail.gmail.com>

On Sat, May 31, 2008 at 2:28 PM, Brian Takita <brian.takita at gmail.com> wrote:
> FYI, I'd like to switch @doc to be an IO stream. Jim had a great idea
> to write directly to the ActionView::Base stream, when integrating
> with Rails. This will bring up a step closer to trying that
> experiment.
>
I checked the changes into Rev. 122.
On github its, http://github.com/pivotal/erector/commit/5cca3a67e8cd1bb5599e7e249ae825e37be95284

I hope there aren't breakages from this. :)

Brian

From alex at pivotallabs.com  Sat May 31 20:22:45 2008
From: alex at pivotallabs.com (Alex Chaffee)
Date: Sat, 31 May 2008 17:22:45 -0700
Subject: [Erector-devel] Splitting Erector to a Gem and a Rails Plugin
In-Reply-To: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>
References: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>
Message-ID: <7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>

On Sat, May 31, 2008 at 2:20 PM, Brian Takita <brian.takita at gmail.com>
wrote:

> Ok, I was thinking that we should go ahead and split out Erector Core
> and Erector Rails.


I still haven't heard a convincing argument why this is necessary. I want to
keep the rails stuff inside the erector library but make it optional.
Splitting it into two projects will just make versioning and maintenance
harder.

-- 
Alex Chaffee
alexch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20080531/a237c2e2/attachment.html>

From brian.takita at gmail.com  Sat May 31 20:44:26 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 17:44:26 -0700
Subject: [Erector-devel] Splitting Erector to a Gem and a Rails Plugin
In-Reply-To: <7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>
References: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>
	<7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>
Message-ID: <1d7ddd110805311744k32d801ccu798b5b8c693de757@mail.gmail.com>

On Sat, May 31, 2008 at 5:22 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
> On Sat, May 31, 2008 at 2:20 PM, Brian Takita <brian.takita at gmail.com>
> wrote:
>>
>> Ok, I was thinking that we should go ahead and split out Erector Core
>> and Erector Rails.
>
> I still haven't heard a convincing argument why this is necessary. I want to
> keep the rails stuff inside the erector library but make it optional.
> Splitting it into two projects will just make versioning and maintenance
> harder.
Sounds good to me. We can have an optional Rails and Merb support from
within the library.

The thing I'd like to avoid is coupling Erector core to Rails.

So if you're using Erector with Rails, you will need to do:
require 'erector'
require 'erector/rails'

or just:
require 'erector/rails'
>
> --
> Alex Chaffee
> alexch at gmail.com

From brian.takita at gmail.com  Sat May 31 20:45:35 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 31 May 2008 17:45:35 -0700
Subject: [Erector-devel] Splitting Erector to a Gem and a Rails Plugin
In-Reply-To: <1d7ddd110805311744k32d801ccu798b5b8c693de757@mail.gmail.com>
References: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>
	<7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>
	<1d7ddd110805311744k32d801ccu798b5b8c693de757@mail.gmail.com>
Message-ID: <1d7ddd110805311745h8d283e0ja6f5dc68dc8dfcae@mail.gmail.com>

On Sat, May 31, 2008 at 5:44 PM, Brian Takita <brian.takita at gmail.com> wrote:
> On Sat, May 31, 2008 at 5:22 PM, Alex Chaffee <alex at pivotallabs.com> wrote:
>> On Sat, May 31, 2008 at 2:20 PM, Brian Takita <brian.takita at gmail.com>
>> wrote:
>>>
>>> Ok, I was thinking that we should go ahead and split out Erector Core
>>> and Erector Rails.
>>
>> I still haven't heard a convincing argument why this is necessary. I want to
>> keep the rails stuff inside the erector library but make it optional.
>> Splitting it into two projects will just make versioning and maintenance
>> harder.
> Sounds good to me. We can have an optional Rails and Merb support from
> within the library.
>
> The thing I'd like to avoid is coupling Erector core to Rails.
>
> So if you're using Erector with Rails, you will need to do:
> require 'erector'
> require 'erector/rails'
>
> or just:
> require 'erector/rails'
or we can check to see if RAILS_ENV exists and require the appropriate files.
>>
>> --
>> Alex Chaffee
>> alexch at gmail.com
>

From kingdon at panix.com  Sat May 31 20:48:26 2008
From: kingdon at panix.com (Jim Kingdon)
Date: Sat, 31 May 2008 20:48:26 -0400 (EDT)
Subject: [Erector-devel] Splitting Erector to a Gem and a Rails Plugin
In-Reply-To: <7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>
	(alex@pivotallabs.com)
References: <1d7ddd110805311420i5bcfaa2bt1c1a09493af0380f@mail.gmail.com>
	<7a93bd340805311722r7f6a1a0cv7fde9a6ee3a7e010@mail.gmail.com>
Message-ID: <20080601004826.275EC241F8@panix5.panix.com>

> I still haven't heard a convincing argument why this is necessary. I want to
> keep the rails stuff inside the erector library but make it optional.
> Splitting it into two projects will just make versioning and maintenance
> harder.

I think I like Alex's solution.  One gem to install, just two
different 'require' invocations to get one part or another.

At least, I haven't thought of any fatal flaw with that, and it does
seem to avoid a certain number of problems.