From jeremyevans0 at gmail.com  Fri Feb  1 21:19:35 2008
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Fri, 1 Feb 2008 18:19:35 -0800
Subject: [Rg 152] Re: Daemonizing mongrel?
In-Reply-To: <47A2199C.6030603@lassoweb.se>
References: <47A2199C.6030603@lassoweb.se>
Message-ID: <5c548e460802011819u78045f7bk48efe5099fd88973@mail.gmail.com>

On Jan 31, 2008 10:55 AM, Lars Olsson <lasso at lassoweb.se> wrote:
> Hi list!
>
> Mongrel supports a daemonized mode. Is it possible to use this mode via
> the Ramaze mongrel adapter?

If you are using ruby-style (gem install ruby-style) for deployment,
it can run ramaze as a daemon using mongrel, evented_mongrel, or scgi:

  style -a ramaze -h mongrel start

I'm the author of ruby-style, so if you have questions, let me know.

Jeremy

From ramaze at tmm1.net  Fri Feb  1 22:31:54 2008
From: ramaze at tmm1.net (Aman Gupta)
Date: Fri, 1 Feb 2008 19:31:54 -0800
Subject: [Rg 153] Re: Daemonizing mongrel?
In-Reply-To: <5c548e460802011819u78045f7bk48efe5099fd88973@mail.gmail.com>
References: <47A2199C.6030603@lassoweb.se>
	<5c548e460802011819u78045f7bk48efe5099fd88973@mail.gmail.com>
Message-ID: <e1c05edd0802011931j6be887a9re3b79893c55090ac@mail.gmail.com>

ruby-style sounds interesting, but I can't find any info on it. Could
you upload some rdocs/README to http://ruby-style.rubyforge.org/

  Aman Gupta

On Fri, Feb 1, 2008 at 6:19 PM, Jeremy Evans <jeremyevans0 at gmail.com> wrote:
> On Jan 31, 2008 10:55 AM, Lars Olsson <lasso at lassoweb.se> wrote:
>  > Hi list!
>  >
>  > Mongrel supports a daemonized mode. Is it possible to use this mode via
>  > the Ramaze mongrel adapter?
>
>  If you are using ruby-style (gem install ruby-style) for deployment,
>  it can run ramaze as a daemon using mongrel, evented_mongrel, or scgi:
>
>   style -a ramaze -h mongrel start
>
>  I'm the author of ruby-style, so if you have questions, let me know.
>
>  Jeremy
>
>
> _______________________________________________
>  Ramaze-general mailing list
>  Ramaze-general at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/ramaze-general
>

From keita.yamaguchi at gmail.com  Sat Feb  2 09:50:53 2008
From: keita.yamaguchi at gmail.com (Keita Yamaguchi)
Date: Sat, 2 Feb 2008 23:50:53 +0900
Subject: [Rg 154]  [PATCH] Ramaze::Gestalt#tag
Message-ID: <7fae95590802020650r206aded1rb879b62f88bc5731@mail.gmail.com>

Hi,

This patch adds the method Ramaze::Gestalt#tag.

Examples:

tags with qualified name
>> Ramaze::Gestalt.build { tag("prefix:local") }
=> "<prefix:local />"

tags with hyphen
>> Ramaze::Gestalt.build { tag("hello-world") }
=> "<hello-world />"

tags with Japanese
>> Ramaze::Gestalt.build { tag("あいうえお") }
=> "<あいうえお />"

Regards,
Keita Yamaguchi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tag.patch.gz
Type: application/x-gzip
Size: 1339 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080202/b5b6669b/attachment.gz 

From lasso at lassoweb.se  Sat Feb  2 11:36:29 2008
From: lasso at lassoweb.se (Lars Olsson)
Date: Sat, 02 Feb 2008 17:36:29 +0100
Subject: [Rg 155] Re: Daemonizing mongrel?
In-Reply-To: <e1c05edd0802011931j6be887a9re3b79893c55090ac@mail.gmail.com>
References: <47A2199C.6030603@lassoweb.se>	<5c548e460802011819u78045f7bk48efe5099fd88973@mail.gmail.com>
	<e1c05edd0802011931j6be887a9re3b79893c55090ac@mail.gmail.com>
Message-ID: <47A49C0D.6070300@lassoweb.se>

Seems there are plenty of options then :)

Thanks for all your answers!

/lasso

-- 
________________________________________
Lars Olsson
lasso at lassoweb.se
http://www.lassoweb.se/

From keita.yamaguchi at gmail.com  Sun Feb  3 05:25:50 2008
From: keita.yamaguchi at gmail.com (Keita Yamaguchi)
Date: Sun, 3 Feb 2008 19:25:50 +0900
Subject: [Rg 156]  [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
Message-ID: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>

Hi,

This patch adds benchmark scripts for
- Amrita2
- Tenjin
- Liquid
- Builder
- Erubis
- Markaby
- RedCloth

Results at my environment:

====== no_template ======
  Requests per second:    635.75 [#/sec] (mean)
====== template_amrita2 ======
  Requests per second:    38.02 [#/sec] (mean)
====== template_ezamar ======
  Requests per second:    328.97 [#/sec] (mean)
====== template_haml ======
  Requests per second:    360.88 [#/sec] (mean)
====== template_tenjin ======
  Requests per second:    498.26 [#/sec] (mean)
====== template_liquid ======
  Requests per second:    481.54 [#/sec] (mean)
====== template_builder ======
  Requests per second:    301.21 [#/sec] (mean)
====== template_erubis ======
  Requests per second:    524.69 [#/sec] (mean)
====== template_markaby ======
  Requests per second:    644.75 [#/sec] (mean)
====== template_redcloth ======
  Requests per second:    121.35 [#/sec] (mean)

Regards,
Keita Yamaguchi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: benchmarks.patch.gz
Type: application/x-gzip
Size: 1980 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080203/8cdf105d/attachment.gz 

From john at oxyliquit.de  Sun Feb  3 06:06:44 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Sun, 03 Feb 2008 12:06:44 +0100
Subject: [Rg 157] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
Message-ID: <op.t5x3tih5xegpx6@jo.local>

Hi,

> This patch adds benchmark scripts for
> - Amrita2
> - Tenjin
> - Liquid
> - Builder
> - Erubis
> - Markaby
> - RedCloth

those benchmarks look yummy, thank you very much, applied.  ^_^

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From john at oxyliquit.de  Sun Feb  3 06:12:15 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Sun, 03 Feb 2008 12:12:15 +0100
Subject: [Rg 158] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
Message-ID: <op.t5x32paixegpx6@jo.local>

Hi,

please recheck the template_redcloth benchmark.  There seems to be
a leftover from Markaby.

Thank you very much,

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From rff.rff at gmail.com  Sun Feb  3 06:45:11 2008
From: rff.rff at gmail.com (gabriele renzi)
Date: Sun, 3 Feb 2008 12:45:11 +0100
Subject: [Rg 159] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
Message-ID: <828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>

On Feb 3, 2008 11:25 AM, Keita Yamaguchi <keita.yamaguchi at gmail.com> wrote:
> Hi,
>
> This patch adds benchmark scripts for

<snip>

Nice! But this seem strange

> Results at my environment:
>
> ====== no_template ======
>   Requests per second:    635.75 [#/sec] (mean)

ok, fast

> ====== template_markaby ======
>   Requests per second:    644.75 [#/sec] (mean)

faster? Markeaby really is impressive :)

From john at oxyliquit.de  Sun Feb  3 07:03:49 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Sun, 03 Feb 2008 13:03:49 +0100
Subject: [Rg 160] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
	<828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>
Message-ID: <op.t5x6gnc0xegpx6@jo.local>

Hi,

>> ====== no_template ======
>>   Requests per second:    635.75 [#/sec] (mean)
>
> ok, fast
>
>> ====== template_markaby ======
>>   Requests per second:    644.75 [#/sec] (mean)
>
> faster? Markeaby really is impressive :)

yes, it kinda is, I guess the eval() and the following markaby code
is slim enough to not be statistically relevant.

An idea (I recently played with Smarty, a php template engine) would
be to write the compiled templates to a new directory (only updating
if the template file has a newer date) as .rb files.
Have to think more about that....

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From keita.yamaguchi at gmail.com  Sun Feb  3 07:37:31 2008
From: keita.yamaguchi at gmail.com (Keita Yamaguchi)
Date: Sun, 3 Feb 2008 21:37:31 +0900
Subject: [Rg 161] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <op.t5x32paixegpx6@jo.local>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
	<op.t5x32paixegpx6@jo.local>
Message-ID: <7fae95590802030437o5b6b77e0ua20aeb5631674e55@mail.gmail.com>

Hello,

> please recheck the template_redcloth benchmark.  There seems to be
> a leftover from Markaby.

Sorry, this is my mistake. The patch is attached at this mail.

Regards,
Keita Yamaguchi



On Feb 3, 2008 8:12 PM, Jonathan Buch <john at oxyliquit.de> wrote:
> Hi,
>
> please recheck the template_redcloth benchmark.  There seems to be
> a leftover from Markaby.
>
> Thank you very much,
>
>
> Jo
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> Ramaze-general mailing list
> Ramaze-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ramaze-general
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-redcloth-benchmark.path.gz
Type: application/x-gzip
Size: 1800 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080203/46e3cc86/attachment-0001.gz 

From john at oxyliquit.de  Sun Feb  3 07:42:47 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Sun, 03 Feb 2008 13:42:47 +0100
Subject: [Rg 162] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <7fae95590802030437o5b6b77e0ua20aeb5631674e55@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
	<op.t5x32paixegpx6@jo.local>
	<7fae95590802030437o5b6b77e0ua20aeb5631674e55@mail.gmail.com>
Message-ID: <op.t5x79lzmxegpx6@jo.local>

Hi,

>> please recheck the template_redcloth benchmark.  There seems to be
>> a leftover from Markaby.
>
> Sorry, this is my mistake. The patch is attached at this mail.

no worries, that's why we have code reviews.  ;)

Thanks for the quick patch.  :)

Could you run the benchmarks again with redcloth?  That'd be nice. :)

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From keita.yamaguchi at gmail.com  Sun Feb  3 09:40:44 2008
From: keita.yamaguchi at gmail.com (Keita Yamaguchi)
Date: Sun, 3 Feb 2008 23:40:44 +0900
Subject: [Rg 163] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
	<828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>
Message-ID: <7fae95590802030640r2d70fe97x5937190b66a0dd96@mail.gmail.com>

Hello,

> faster? Markeaby really is impressive :)

Sorry, Markaby and Amrita2 benchmark script were wrong. I made
mistakes again :) The patch is attached at this mail.

====== no_template ======
  Requests per second:    576.23 [#/sec] (mean)
====== template_amrita2 ======
  Requests per second:    141.52 [#/sec] (mean)
====== template_ezamar ======
  Requests per second:    180.76 [#/sec] (mean)
====== template_haml ======
  Requests per second:    242.42 [#/sec] (mean)
====== template_tenjin ======
  Requests per second:    302.71 [#/sec] (mean)
====== template_liquid ======
  Requests per second:    469.06 [#/sec] (mean)
====== template_builder ======
  Requests per second:    172.84 [#/sec] (mean)
====== template_erubis ======
  Requests per second:    466.81 [#/sec] (mean)
====== template_markaby ======
  Requests per second:    244.95 [#/sec] (mean)
====== template_redcloth ======
  Requests per second:    57.06 [#/sec] (mean)

This time, Markaby is slower than no_template correctly :)

Oh, RedCloth is very slow... The implementation approach of
Ramaze::Template::RedCloth may be bad. (or the benchmark script is
bad?)

Regards,
Keita Yamaguchi



On Feb 3, 2008 8:45 PM, gabriele renzi <rff.rff at gmail.com> wrote:
> On Feb 3, 2008 11:25 AM, Keita Yamaguchi <keita.yamaguchi at gmail.com> wrote:
> > Hi,
> >
> > This patch adds benchmark scripts for
>
> <snip>
>
> Nice! But this seem strange
>
> > Results at my environment:
> >
> > ====== no_template ======
> >   Requests per second:    635.75 [#/sec] (mean)
>
> ok, fast
>
> > ====== template_markaby ======
> >   Requests per second:    644.75 [#/sec] (mean)
>
> faster? Markeaby really is impressive :)
>
> _______________________________________________
> Ramaze-general mailing list
> Ramaze-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ramaze-general
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-amrita2-mab.patch.gz
Type: application/x-gzip
Size: 1975 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080203/167d31e3/attachment.gz 

From rff.rff at gmail.com  Sun Feb  3 11:48:52 2008
From: rff.rff at gmail.com (gabriele renzi)
Date: Sun, 3 Feb 2008 17:48:52 +0100
Subject: [Rg 164] Re: [PATCH] benchmark scripts for Amrita2, Tenjin, etc.
In-Reply-To: <7fae95590802030640r2d70fe97x5937190b66a0dd96@mail.gmail.com>
References: <7fae95590802030225r6f82d0ceibbc458f1b4b96040@mail.gmail.com>
	<828083e70802030345ld6ddfd6s87df58d018f8e22d@mail.gmail.com>
	<7fae95590802030640r2d70fe97x5937190b66a0dd96@mail.gmail.com>
Message-ID: <828083e70802030848j5c5176balc7b8f3d232542739@mail.gmail.com>

On Feb 3, 2008 3:40 PM, Keita Yamaguchi <keita.yamaguchi at gmail.com> wrote:
> Hello,
>
> > faster? Markeaby really is impressive :)
>
> Sorry, Markaby and Amrita2 benchmark script were wrong. I made
> mistakes again :)

:)

<snip>

> Oh, RedCloth is very slow... The implementation approach of
> Ramaze::Template::RedCloth may be bad. (or the benchmark script is
> bad?)


I believe RedCloth itself is actually a bit slow? It does a huge
amount of text  processing with a lot of differente regexes.

Attached is a patch to load superredcloth if available ( it should be
10 times faster) but I'm not sure it is 100% compatible (at a quick
glance, SuperRedCloth's test suite seems to support textile 2.0 but
not markdown), but all tests pass so maybe there is  a lacking test :)
Or maybe we could add it as a diffferent template altogether?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superredcloth.bundle
Type: application/octet-stream
Size: 4601 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080203/55f9df7c/attachment.obj 

From lasso at lassoweb.se  Sun Feb  3 14:18:16 2008
From: lasso at lassoweb.se (Lars Olsson)
Date: Sun, 03 Feb 2008 20:18:16 +0100
Subject: [Rg 165]  Request -> Current mount path
Message-ID: <47A61378.1080605@lassoweb.se>

Hi list!

Given a Ramaze::Request object, what is the easiest way of finding out 
the mount point for the Controller object that is responding to the 
request? The following seems to work but look hideous to me:

# request is a Ramaze::Request object
Global.mapping.invert[Controller::default(request.request_uri).controller]


Kindly

/lasso

-- 
________________________________________
Lars Olsson
lasso at lassoweb.se
http://www.lassoweb.se/

From john at oxyliquit.de  Sun Feb  3 16:41:41 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Sun, 03 Feb 2008 22:41:41 +0100
Subject: [Rg 166] Re: Request -> Current mount path
In-Reply-To: <47A61378.1080605@lassoweb.se>
References: <47A61378.1080605@lassoweb.se>
Message-ID: <op.t5yw7rroxegpx6@jo.local>

Hi,

> Given a Ramaze::Request object, what is the easiest way of finding out
> the mount point for the Controller object that is responding to the
> request? The following seems to work but look hideous to me:
>
> # request is a Ramaze::Request object
> Global.mapping.invert[Controller::default(request.request_uri).controller]

only from memory:

Ramaze::Controller.current.mapping

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jeremyevans0 at gmail.com  Sun Feb  3 17:50:23 2008
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Sun, 3 Feb 2008 14:50:23 -0800
Subject: [Rg 167] Re: Daemonizing mongrel?
In-Reply-To: <e1c05edd0802011931j6be887a9re3b79893c55090ac@mail.gmail.com>
References: <47A2199C.6030603@lassoweb.se>
	<5c548e460802011819u78045f7bk48efe5099fd88973@mail.gmail.com>
	<e1c05edd0802011931j6be887a9re3b79893c55090ac@mail.gmail.com>
Message-ID: <5c548e460802031450v6a566460k87baa18986874719@mail.gmail.com>

On Feb 1, 2008 7:31 PM, Aman Gupta <ramaze at tmm1.net> wrote:
> ruby-style sounds interesting, but I can't find any info on it. Could
> you upload some rdocs/README to http://ruby-style.rubyforge.org/

I updated the project home page on RubyForge. You can find the README
and Rdoc at http://code.jeremyevans.net/ruby-style.

Jeremy

From keita.yamaguchi at gmail.com  Mon Feb  4 12:03:07 2008
From: keita.yamaguchi at gmail.com (Keita Yamaguchi)
Date: Tue, 5 Feb 2008 02:03:07 +0900
Subject: [Rg 168]  [PATCH] catch :respond in Action#process
Message-ID: <7fae95590802040903l9f68c55ue88ad48f7207489b@mail.gmail.com>

Hi,

The aim of this patch is to apply
filters(Ramaze::Dispatcher::Action::FILTER) to the respondence by
RedirectHelper.respond and FileHelper.send_file etc.

Now it is like this:

Ramaze::Dispatcher::Action::FILTER << proc {|response|
  response.header['Cache-Control'] = 'no-store'
  response
}

class MyController < Ramaze::Controller
  map '/'

  def index
    respond(render_partial Rs(:partial))
  end

  def partial
    "hello"
  end
end

/index => filters are not applied
/partial => filters are applied

This patch enables to apply filters to /index too.

Regards,
Keita Yamaguchi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: catch_respond.patch.gz
Type: application/x-gzip
Size: 2068 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ramaze-general/attachments/20080205/9af3cfaf/attachment-0001.gz 

From john at oxyliquit.de  Mon Feb  4 16:32:44 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Mon, 04 Feb 2008 22:32:44 +0100
Subject: [Rg 169] Re: [PATCH] catch :respond in Action#process
In-Reply-To: <7fae95590802040903l9f68c55ue88ad48f7207489b@mail.gmail.com>
References: <7fae95590802040903l9f68c55ue88ad48f7207489b@mail.gmail.com>
Message-ID: <op.t50rgulyxegpx6@jo.local>

Hi,

> /index => filters are not applied
> /partial => filters are applied
>
> This patch enables to apply filters to /index too.

I'm not yet sure of the implications of this patch, so I'm putting
this off for the moment.

Manv, Aman, feel free to look over this as well and decide.

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jeremyevans0 at gmail.com  Tue Feb  5 15:29:24 2008
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Tue, 5 Feb 2008 12:29:24 -0800
Subject: [Rg 170]  Some questions about overriding layouts inside an action
Message-ID: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>

I'm working on porting my Scaffolding Extensions plugin from Rails to
Ramaze, and while it's mostly working, I'm not sure how to accomplish
the following things:

First, is there an easier way to change which template will be used by
an action than:

  ::Ramaze::Action.current.template = 'path/to/new/template'

Second, If the user provided a layout, I'd like to use it.  If not,
I'd like to use the one provided by Scaffolding Extensions.  Is there
a way to determine if a layout will be used for the action inside of
the action?

Assuming I determine that the user has not provided a layout and I
want to use the one provided by Scaffolding Extensions, is there a way
to change which layout will be used inside of an action?

Depending on the request, an action may or may not use a layout.
Is there a way to stop the use of a layout inside of an action, other
than the ugly "respond(Erubis::Eruby.new(template).result(binding()))"?

Thanks for the help.

Jeremy

From john at oxyliquit.de  Tue Feb  5 16:43:35 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Tue, 05 Feb 2008 22:43:35 +0100
Subject: [Rg 171] Re: Some questions about overriding layouts inside an
 action
In-Reply-To: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
References: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
Message-ID: <op.t52mmx1gxegpx6@jo.local>

Hi,

> I'm working on porting my Scaffolding Extensions plugin from Rails to
> Ramaze, and while it's mostly working, I'm not sure how to accomplish
> the following things:
>
> First, is there an easier way to change which template will be used by
> an action than:
>
>   ::Ramaze::Action.current.template = 'path/to/new/template'

I'm not quire sure what you want to accomplish (as I don't know how
rails scaffolding works).
The only case where I would touch the currents actions template is, if
I had some central 'dispatching' method which has to be able to change
templates on the fly.

You could make yourself a little helper:

module Ramaze::UseTemplateHelper
   def use_template(path)
     ::Ramaze::Action.current.template = name
   end
end

class MyController < Ramaze::Controller
   helper :use_template

   def myaction(param)
     @var = "Hello World"
     use_template(param)
   end
end

That is of course only sugar coating, I don't know what you  mean by
'easier' exactly.  :)

> Second, If the user provided a layout, I'd like to use it.  If not,
> I'd like to use the one provided by Scaffolding Extensions.  Is there
> a way to determine if a layout will be used for the action inside of
> the action?

Again, I'm at a loss here, why not just let the user override the
layout?  Layout can be a file or an action which the user can adapt
as he wishes.
If you provide a default layout, the user will want to either remove
or replace it.  I'm not sure why there should be any additional code
for that.

> Assuming I determine that the user has not provided a layout and I
> want to use the one provided by Scaffolding Extensions, is there a way
> to change which layout will be used inside of an action?

So you not only want to change the template but also the layout at
runtime?  :P
I would provide the default layout as just an action, which gets used
as long as the user doesn't do more.

> Depending on the request, an action may or may not use a layout.
> Is there a way to stop the use of a layout inside of an action, other
> than the ugly "respond(Erubis::Eruby.new(template).result(binding()))"?

Yeah, rather ugly.  You can do the changing in another way:

You could make yourself a little helper again:

module Ramaze::UseLayoutHelper
   def use_layout(*path)
     class_trait[:layout][::Ramaze::Action.current.name] = Rs(*path)
   end
end

class MyController < Ramaze::Controller
   helper :use_layout

   def myaction(param = 'default_layout')
     @var = "Hello World"
     use_layout(param)
   end
end

But that ain't the right style (as it essentially breaks threading).

Without knowing more about how your scaffolding works, I'm not sure
I can actually help.

What my guess is what it does:  Create create/edit/delete/view
actions from an ORM.

How about this approach:


module Ramaze::ScaffoldHelper
   def self.included(klass)
     # create scaffolding methods on klass or whatever
     klass.layout :default_layout
   end
end

# and the user does the following

class MyController < Ramaze::Controller
   helper :scaffold
   layout :my_layout # essentially overriding the default one
end

I hope you see what I'm trying to convey, just let the user override
when necessary.

I hope that helps,

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jeremyevans0 at gmail.com  Tue Feb  5 19:14:56 2008
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Tue, 5 Feb 2008 16:14:56 -0800
Subject: [Rg 172] Re: Some questions about overriding layouts inside an
	action
In-Reply-To: <op.t52mmx1gxegpx6@jo.local>
References: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
	<op.t52mmx1gxegpx6@jo.local>
Message-ID: <5c548e460802051614s4295b70fs14853f9c8f7cb901@mail.gmail.com>

On 2/5/08, Jonathan Buch <john at oxyliquit.de> wrote:
> Hi,
>
> > I'm working on porting my Scaffolding Extensions plugin from Rails to
> > Ramaze, and while it's mostly working, I'm not sure how to accomplish
> > the following things:
> >
> > First, is there an easier way to change which template will be used by
> > an action than:
> >
> >   ::Ramaze::Action.current.template = 'path/to/new/template'
>
> I'm not quire sure what you want to accomplish (as I don't know how
> rails scaffolding works).

I want to provide a default template that the users can override.
Ramaze uses the file template if it exists, or the return value of the
action if it does not.  I could get around the issue by reading the
contents of the template file from the filesystem and using that, I
suppose, though I suspect that would break caching.

Rails makes it easy to override the template used (render :file), I
was just hoping Ramaze had similar functionality.

> The only case where I would touch the currents actions template is, if
> I had some central 'dispatching' method which has to be able to change
> templates on the fly.
>
> You could make yourself a little helper:
>
> module Ramaze::UseTemplateHelper
>   def use_template(path)
>     ::Ramaze::Action.current.template = name
>   end
> end
>
> class MyController < Ramaze::Controller
>   helper :use_template
>
>   def myaction(param)
>     @var = "Hello World"
>     use_template(param)
>   end
> end
>
> That is of course only sugar coating, I don't know what you  mean by
> 'easier' exactly.  :)

Easier was probably a bad word choice.  Supported would be a better
one.  I would prefer not to use an unsupported interface to do what I
need to do, as that risks breakage if the framework changes.  Is there
a supported method for doing what I want, that will work in future
versions?

> > Second, If the user provided a layout, I'd like to use it.  If not,
> > I'd like to use the one provided by Scaffolding Extensions.  Is there
> > a way to determine if a layout will be used for the action inside of
> > the action?
>
> Again, I'm at a loss here, why not just let the user override the
> layout?  Layout can be a file or an action which the user can adapt
> as he wishes.

Your self.included method may work for what I want, ditto for the
layout method override.  However, my layout is going to be outside the
template root, so I'm not sure.  The action's template is relative to
the current directory, not current template_root (understandable as
template_root is now an array), but I'm not sure about the layout.

> If you provide a default layout, the user will want to either remove
> or replace it.  I'm not sure why there should be any additional code
> for that.

I'm not saying there should be.  I'm just used to Rails, which makes
it easy to choose which layout to use inside an action (render
:layout).

> > Assuming I determine that the user has not provided a layout and I
> > want to use the one provided by Scaffolding Extensions, is there a way
> > to change which layout will be used inside of an action?
>
> So you not only want to change the template but also the layout at
> runtime?  :P

Yep.  :)

> I would provide the default layout as just an action, which gets used
> as long as the user doesn't do more.

I'll look into doing this.  I'm used to Rails, where the layout is
merely a template and not a completely separate action.  If it works
the way I think, I should be able to use the template hack to change
the location of the layout.

> > Depending on the request, an action may or may not use a layout.
> > Is there a way to stop the use of a layout inside of an action, other
> > than the ugly "respond(Erubis::Eruby.new(template).result(binding()))"?
>
> Yeah, rather ugly.  You can do the changing in another way:
>
> You could make yourself a little helper again:
>
> module Ramaze::UseLayoutHelper
>   def use_layout(*path)
>     class_trait[:layout][::Ramaze::Action.current.name] = Rs(*path)
>   end
> end
>
> class MyController < Ramaze::Controller
>   helper :use_layout
>
>   def myaction(param = 'default_layout')
>     @var = "Hello World"
>     use_layout(param)
>   end
> end
>
> But that ain't the right style (as it essentially breaks threading).

Then I don't want to do that.

> Without knowing more about how your scaffolding works, I'm not sure
> I can actually help.

Hopefully I've answered some of the questions you have.

> What my guess is what it does:  Create create/edit/delete/view
> actions from an ORM.

Pretty much, with searching, browsing, and merging added, and a lot of
support for associations.

> How about this approach:
>
>
> module Ramaze::ScaffoldHelper
>   def self.included(klass)
>     # create scaffolding methods on klass or whatever
>     klass.layout :default_layout
>   end
> end
>
> # and the user does the following
>
> class MyController < Ramaze::Controller
>   helper :scaffold
>   layout :my_layout # essentially overriding the default one
> end
>
> I hope you see what I'm trying to convey, just let the user override
> when necessary.

Providing the user good defaults and letting them override just what
they want to is definitely the design I aim for.  I think it is just
that Rails allows you to have more rendering control inside the
action, while Ramaze handles it at the class level and doesn't allow
as much control inside the action. Since the plugin was initially
designed for Rails (and the new version needs to still work with
Rails), obviously it isn't a perfect fit for Ramaze's structure.

> I hope that helps,

Definitely.  Thanks for the feedback.

Here's what I came up for the layout (run at the class level when one
of the scaffold methods is used):

      unless trait[:layout][:all]
        layout(:layout)
        define_method(:layout){::Ramaze::Action.current.template =
scaffold_path('layout')}
      end

Here's how the how the rendering works (this is the return value for
the actions that render):

      unless ::Ramaze::Action.current.template
        if render_options.include?(:inline)
          respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))
        else
          ::Ramaze::Action.current.template = scaffold_path(action)
        end
      end

So my questions now are:

1) Is this supported (the template file changing hack)?  If not, is
there a supported way to do what I want?

2) Is there a supported way to turn off the layout for the action, so
I can get rid of the ugly
"respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))"?

Jeremy

From ramaze at tmm1.net  Wed Feb  6 00:26:37 2008
From: ramaze at tmm1.net (Aman Gupta)
Date: Tue, 5 Feb 2008 21:26:37 -0800
Subject: [Rg 173] Re: Some questions about overriding layouts inside an
	action
In-Reply-To: <e1c05edd0802051334r3234d690s8bf23ef42312bf32@mail.gmail.com>
References: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
	<e1c05edd0802051334r3234d690s8bf23ef42312bf32@mail.gmail.com>
Message-ID: <e1c05edd0802052126x5cf7f06fj4657222d9f1b78c5@mail.gmail.com>

On Tue, Feb 5, 2008 at 12:29 PM, Jeremy Evans <jeremyevans0 at gmail.com> wrote:
 > I'm working on porting my Scaffolding Extensions plugin from Rails to
 >  Ramaze, and while it's mostly working, I'm not sure how to accomplish
 >  the following things:
 >
 >  First, is there an easier way to change which template will be used by
 >  an action than:
 >
 >   ::Ramaze::Action.current.template = 'path/to/new/template'

 class MainController
  template :index, :show
 end

 will have the index action use the show template.


 >  Second, If the user provided a layout, I'd like to use it.  If not,
 >  I'd like to use the one provided by Scaffolding Extensions.  Is there
 >  a way to determine if a layout will be used for the action inside of
 >  the action?
 >
 >  Assuming I determine that the user has not provided a layout and I
 >  want to use the one provided by Scaffolding Extensions, is there a way
 >  to change which layout will be used inside of an action?
 >
 >  Depending on the request, an action may or may not use a layout.
 >  Is there a way to stop the use of a layout inside of an action, other
 >  than the ugly "respond(Erubis::Eruby.new(template).result(binding()))"?

 class MainController
  helper :partial
  def index() render_template('template.erb') end
 end



 >
 >  Thanks for the help.
 >
 >  Jeremy
 >  _______________________________________________
 >  Ramaze-general mailing list
 >  Ramaze-general at rubyforge.org
 >  http://rubyforge.org/mailman/listinfo/ramaze-general
 >

From john at oxyliquit.de  Wed Feb  6 07:07:13 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 06 Feb 2008 13:07:13 +0100
Subject: [Rg 174] Re: Some questions about overriding layouts inside an
 action
In-Reply-To: <5c548e460802051614s4295b70fs14853f9c8f7cb901@mail.gmail.com>
References: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
	<op.t52mmx1gxegpx6@jo.local>
	<5c548e460802051614s4295b70fs14853f9c8f7cb901@mail.gmail.com>
Message-ID: <op.t53qmbg6xegpx6@jo.local>

Hi,

> I want to provide a default template that the users can override.
> Ramaze uses the file template if it exists, or the return value of the
> action if it does not.  I could get around the issue by reading the
> contents of the template file from the filesystem and using that, I
> suppose, though I suspect that would break caching.
>
> Rails makes it easy to override the template used (render :file), I
> was just hoping Ramaze had similar functionality.

Well, there is also `render_template()` in `helper :partial`, have a
look at that one.

> Easier was probably a bad word choice.  Supported would be a better
> one.  I would prefer not to use an unsupported interface to do what I
> need to do, as that risks breakage if the framework changes.  Is there
> a supported method for doing what I want, that will work in future
> versions?

Well, the functionality _is_ supported (Action.current.template).  That
feature won't go away.  Like I said, it's just sugar, nothing more nothing
less.  That sugar is only part of your internal API, users wouldn't even
see it.

>> > Second, If the user provided a layout, I'd like to use it.  If not,
>> > I'd like to use the one provided by Scaffolding Extensions.  Is there
>> > a way to determine if a layout will be used for the action inside of
>> > the action?
>>
>> Again, I'm at a loss here, why not just let the user override the
>> layout?  Layout can be a file or an action which the user can adapt
>> as he wishes.
>
> Your self.included method may work for what I want, ditto for the
> layout method override.  However, my layout is going to be outside the
> template root, so I'm not sure.  The action's template is relative to
> the current directory, not current template_root (understandable as
> template_root is now an array), but I'm not sure about the layout.

As far as I know, layouts are looked up in the full ramaze hierarchy.
Meaning, if it is a known template file, it will be used.  So, there
should be a problem using the template_root for layouts.

So yes, why not simply make another template_root where your default
templates/layouts come from?

>> If you provide a default layout, the user will want to either remove
>> or replace it.  I'm not sure why there should be any additional code
>> for that.
>
> I'm not saying there should be.  I'm just used to Rails, which makes
> it easy to choose which layout to use inside an action (render
> :layout).

Well, we are not Rails, so there is bound to be differences.  ;)

>> So you not only want to change the template but also the layout at
>> runtime?  :P
>
> Yep.  :)

Like I said before, if it it just a 'toggle' between the default and a
user defined template, this functionality is overkill and better handled
by how ramaze behaves.

>> I would provide the default layout as just an action, which gets used
>> as long as the user doesn't do more.
>
> I'll look into doing this.  I'm used to Rails, where the layout is
> merely a template and not a completely separate action.  If it works
> the way I think, I should be able to use the template hack to change
> the location of the layout.

Layout is an action.  :)  In ramaze there is little difference between
a full action and a template.  An action can even be a template alone
without a function in a controller attached to it.

So basically you can provide a default template (returned by a function
inside a controller) which the user can then simply monkeypatch or
override by placing a template file into a template root.

>> Without knowing more about how your scaffolding works, I'm not sure
>> I can actually help.
>
> Hopefully I've answered some of the questions you have.

Hmmm... I think I just have a completely different image in my mind,
never having used Rails.

> Providing the user good defaults and letting them override just what
> they want to is definitely the design I aim for.  I think it is just
> that Rails allows you to have more rendering control inside the
> action, while Ramaze handles it at the class level and doesn't allow
> as much control inside the action. Since the plugin was initially
> designed for Rails (and the new version needs to still work with
> Rails), obviously it isn't a perfect fit for Ramaze's structure.

Well, a 1:1 conversion of Rails to Ramaze may be possible, but I'm not
sure if it's the most elegant.  :)
If they need to be useable in exactly the same way, you may have no
choice other than 'hacking' ramaze a little.

I'm just not sure if (in this case) that you _need_ the control, why
not hand a little of that control over to the users.  :P

>> I hope that helps,
>
> Definitely.  Thanks for the feedback.
>
> Here's what I came up for the layout (run at the class level when one
> of the scaffold methods is used):
>
>       unless trait[:layout][:all]
>         layout(:layout)
>         define_method(:layout){::Ramaze::Action.current.template =
> scaffold_path('layout')}
>       end

This is to decide if the user created his own layout method?  And it is
run on _every_ scaffold method use?

Why not simply execute that once on `self.include` time?  (Or whatever
creates scaffolding methods on the controller.)

> Here's how the how the rendering works (this is the return value for
> the actions that render):
>
>       unless ::Ramaze::Action.current.template
>         if render_options.include?(:inline)
>           respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))
>         else
>           ::Ramaze::Action.current.template = scaffold_path(action)
>         end
>       end

Those two problems are quite related, only that one is on class level
(layouts) and one on instance level (templates).

What does :inline contain, the template to be rendered?

If you provide a default template root, you could reduce that probably
to:

if render_options.include?(:inline)
   render_template('default_template.erb')
end

Or at least something along those lines, as you can trust that Ramaze
will just pick the correct default template.

> So my questions now are:
>
> 1) Is this supported (the template file changing hack)?  If not, is
> there a supported way to do what I want?

The Action.current.template won't go way.

> 2) Is there a supported way to turn off the layout for the action, so
> I can get rid of the ugly
> "respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))"?

render_template or render_partial might float your boat.  :)

`deny_layout *actions` might help you too.  But it too is permanent
like the `layout` call.

Hope that helps,

Jo

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jeremyevans0 at gmail.com  Wed Feb  6 12:58:25 2008
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Wed, 6 Feb 2008 09:58:25 -0800
Subject: [Rg 175] Re: Some questions about overriding layouts inside an
	action
In-Reply-To: <op.t53qmbg6xegpx6@jo.local>
References: <5c548e460802051229w6c711a4ejbc85903286c2e0d1@mail.gmail.com>
	<op.t52mmx1gxegpx6@jo.local>
	<5c548e460802051614s4295b70fs14853f9c8f7cb901@mail.gmail.com>
	<op.t53qmbg6xegpx6@jo.local>
Message-ID: <5c548e460802060958s7cd18f9aq7d6a1798d145fb42@mail.gmail.com>

On 2/6/08, Jonathan Buch <john at oxyliquit.de> wrote:
> Well, there is also `render_template()` in `helper :partial`, have a
> look at that one.

I've used that in another Ramaze application.  I could use that in
Scaffolding Extensions to provide the template, which will just be
overriden if the user has provided a template.  The downside is that
it forces the rendering of the default scaffold template even if the
user has provided their own.  Also, I'm not sure what happens when you
do:

  def example
    render_template('example2.rhtml')
  end

Does render_template return the template string, or the output of the
template?  I'm guessing the output, since you use it with respond
(which ignores templates).  If it returns the output of the the
template, won't that also be considered a template since it is the
return value of example (as long as a template file for example
doesn't exist)?

> > Easier was probably a bad word choice.  Supported would be a better
> > one.  I would prefer not to use an unsupported interface to do what I
> > need to do, as that risks breakage if the framework changes.  Is there
> > a supported method for doing what I want, that will work in future
> > versions?
>
> Well, the functionality _is_ supported (Action.current.template).  That
> feature won't go away.  Like I said, it's just sugar, nothing more nothing
> less.  That sugar is only part of your internal API, users wouldn't even
> see it.

That is good to know.  I certainly feel better about using that
method.  This is a nice change from Rails where you know that the
internals can change at any time, and deprecating and then removing
methods from the public API is not uncommon.

> > Your self.included method may work for what I want, ditto for the
> > layout method override.  However, my layout is going to be outside the
> > template root, so I'm not sure.  The action's template is relative to
> > the current directory, not current template_root (understandable as
> > template_root is now an array), but I'm not sure about the layout.
>
> As far as I know, layouts are looked up in the full ramaze hierarchy.
> Meaning, if it is a known template file, it will be used.  So, there
> should be a problem using the template_root for layouts.
>
> So yes, why not simply make another template_root where your default
> templates/layouts come from?

I would have done that, but the templates usually have different
names.  The recommended use of the plugin is to scaffold all models in
a single controller.  So the actions are edit_model1/new_model2/etc..
The generic templates are just named edit and new.

> >> If you provide a default layout, the user will want to either remove
> >> or replace it.  I'm not sure why there should be any additional code
> >> for that.
> >
> > I'm not saying there should be.  I'm just used to Rails, which makes
> > it easy to choose which layout to use inside an action (render
> > :layout).
>
> Well, we are not Rails, so there is bound to be differences.  ;)

Naturally.  That's not a problem.  I'm guessing the developers just
haven't needed to do what I'm doing.

> >> So you not only want to change the template but also the layout at
> >> runtime?  :P
> >
> > Yep.  :)
>
> Like I said before, if it it just a 'toggle' between the default and a
> user defined template, this functionality is overkill and better handled
> by how ramaze behaves.

If the template names were always the same, it would definitely be
simpler, unfortunately, that's not the case.

> >> I would provide the default layout as just an action, which gets used
> >> as long as the user doesn't do more.
> >
> > I'll look into doing this.  I'm used to Rails, where the layout is
> > merely a template and not a completely separate action.  If it works
> > the way I think, I should be able to use the template hack to change
> > the location of the layout.
>
> Layout is an action.  :)  In ramaze there is little difference between
> a full action and a template.  An action can even be a template alone
> without a function in a controller attached to it.

Having layout be an action instead of just a template is actually a
very powerful feature.

> So basically you can provide a default template (returned by a function
> inside a controller) which the user can then simply monkeypatch or
> override by placing a template file into a template root.

I probably would do that if Ramaze was the only web framework I was
attempting to support, since that's the most natural way to handle
things within Ramaze.

> > Providing the user good defaults and letting them override just what
> > they want to is definitely the design I aim for.  I think it is just
> > that Rails allows you to have more rendering control inside the
> > action, while Ramaze handles it at the class level and doesn't allow
> > as much control inside the action. Since the plugin was initially
> > designed for Rails (and the new version needs to still work with
> > Rails), obviously it isn't a perfect fit for Ramaze's structure.
>
> Well, a 1:1 conversion of Rails to Ramaze may be possible, but I'm not
> sure if it's the most elegant.  :)
> If they need to be useable in exactly the same way, you may have no
> choice other than 'hacking' ramaze a little.

Actually, with the way things are set up, Scaffolding Extensions works
pretty much exactly the same way in both frameworks.  It's currently
around 1700 lines of code, and about 200 lines are framework specific
(100 for Rails, and 100 for Ramaze), and 700 lines are ORM specific
(currently only ActiveRecord is supported).

> I'm just not sure if (in this case) that you _need_ the control, why
> not hand a little of that control over to the users.  :P

In Rails-land, you decide for the users and if they don't like it you
tell them it is "opinionated". ;)

> > Here's what I came up for the layout (run at the class level when one
> > of the scaffold methods is used):
> >
> >       unless trait[:layout][:all]
> >         layout(:layout)
> >         define_method(:layout){::Ramaze::Action.current.template =
> > scaffold_path('layout')}
> >       end
>
> This is to decide if the user created his own layout method?  And it is
> run on _every_ scaffold method use?

No, it is run once at the controller level when one of the scaffold
class methods that creates actions (instance methods) is called.

> Why not simply execute that once on `self.include` time?  (Or whatever
> creates scaffolding methods on the controller.)

Because the class methods are included in Ramaze::Controller, so they
can be used by any controller.

> > Here's how the how the rendering works (this is the return value for
> > the actions that render):
> >
> >       unless ::Ramaze::Action.current.template
> >         if render_options.include?(:inline)
> >           respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))
> >         else
> >           ::Ramaze::Action.current.template = scaffold_path(action)
> >         end
> >       end
>
> Those two problems are quite related, only that one is on class level
> (layouts) and one on instance level (templates).
>
> What does :inline contain, the template to be rendered?

Yes.  :inline is only used for responses that don't require a layout.

> If you provide a default template root, you could reduce that probably
> to:
>
> if render_options.include?(:inline)
>   render_template('default_template.erb')
> end
>
> Or at least something along those lines, as you can trust that Ramaze
> will just pick the correct default template.

As mentioned above, I can't do that because the templates have
different names.  For example, a user could create a controller and
scaffold all models within it.  Inside that controller, they could
also have an edit action with an edit.erb template, which may
correspond to something completely different.  If that was the case,
then render_template('edit.erb') would get their template instead of
the one provided by the plugin.

> > So my questions now are:
> >
> > 1) Is this supported (the template file changing hack)?  If not, is
> > there a supported way to do what I want?
>
> The Action.current.template won't go way.

Good, that's makes me feel much better about using it.

> > 2) Is there a supported way to turn off the layout for the action, so
> > I can get rid of the ugly
> > "respond(Erubis::Eruby.new(render_options[:inline]).result(binding()))"?
>
> render_template or render_partial might float your boat.  :)

render_template renders a template file, and render_partial renders a
completely separate action, correct?  render_options[:inline] is the
string containing the template itself, so I'm not sure if I can use
either.

> `deny_layout *actions` might help you too.  But it too is permanent
> like the `layout` call.

Initially, I thought I couldn't use that because I thought that some
actions may or may not use the layout depending on the request format.
 I'm not sure that is the case, so deny_layout may work for the
actions.  Maybe it is worth the effort to use that and get rid of the
ugly.

> Hope that helps,

It does.  Thank you very much.

Jeremy

From john at oxyliquit.de  Wed Feb  6 16:17:24 2008
From: john at oxyliquit.de (Jonathan Buch)
Date: Wed, 06 Feb 2008 22:17:24 +0100
Subject: [Rg 176]  [ANN] mailing list changes to google groups
Message-ID: <op.t54f3arzxegpx6@jo.local>

Hi,

since some time all discussion goes to ramaze google groups.

http://groups.google.com/group/ramaze

As the synchronization does not work correctly, please all jump ship,
cease and desist, etc and start using the GG.  :P

We're very sorry for the inconvenience,

Jonathan Buch

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/