Rails lack of documentation (render nested layouts)

Rails
1

I’ve posted some days ago about the lack of proper documentation for the
testing framework used by Rails.

Today, among other days, I noted one more method missing documentation.

I’ve read the past year about nested layouts in some blog I don’t
remember.

Today I had to write a new application and needed the nested layouts
again.

First, I looked at the documentation, as I use to do. Didn’t find. Then
I
looked at my other project code and found how, although I couldn’t find
this feature documented.

Into the documentation there are references for:
render (ActionView::TemplateHandlers::Compilable)
render (ActionView::TemplateHandler)

But none of them had any documentation available (although I’m not sure
these are the methods I should be looking for. Maybe it should be
“render
(ActionController::Base)”).

Well, the requirements are quite simple, so is the solution, but finding
it
on documentations is impossible, unless I’m missing something.

To keep it clear, here is the actual case:

I want to have a master layout (application.erb) and another layout
(another.erb) for the AnothersController, based on master layout.

application.erb:

... <%= yield :further_header %> ...

another.erb:
<% content_for :further_header do %>
Further content here
<% end %>

<%= render ‘layouts/application’ %>

Quite simple, don’t you think? So what am I complaining about? This is a
very useful hidden feature. It is not documented. Even worse, the render
method is not documented. And even if I didn’t care about others
reaching
this feature, I would care if this feature will continue working in the
next Rails releases. Once a feature is documented, there is a great
chance
it will continue to be supported…

I would like to help documenting such missing documentation, but I need
some
instructions how can I do that: how to make patches, and need to know
how
do these methods actually work.

Thanks in advance,

Rodrigo.

2

On 2 Sep 2008, at 21:58, Rodrigo Rosenfeld R. wrote:

render (ActionView::TemplateHandlers::Compilable)
render (ActionView::TemplateHandler)

But none of them had any documentation available (although I’m not
sure
these are the methods I should be looking for. Maybe it should be
“render
(ActionController::Base)”).

Which is there as far as I can tell:
http://api.rubyonrails.com/classes/ActionController/Base.html#M000848

application.erb:

next Rails releases. Once a feature is documented, there is a great
chance
it will continue to be supported…

Well the key thing is for there to be tests describing the
functionality. Tests get automatically checked, docs don’t

I would like to help documenting such missing documentation, but I
need some
instructions how can I do that: how to make patches, and need to
know how
do these methods actually work.

lifo’s docrails project on github is the place to go.

Fred

3

could not disagree more. but that’s another issue. :wink:

On Wed, Sep 3, 2008 at 12:40 PM, Rodrigo Rosenfeld R.

4

I agree with you that everybody would be benefited a lot if they know
about
unit tests. But a framework should not expect this from the end user. It
should be up to (s)he to be enlighten…

Besides that, it is much easier to look for a feature in documentation
than
in the test units…

That is what I meant…

Rodrigo.

5

On 3 Sep 2008, at 19:28, Rodrigo Rosenfeld R. wrote:

That’s not what I was getting at: What I meant that it is easy to make
a small change that inadvertently changes how something behaves. At
that point a unit tests guard against such inadvertent changes,
documentation does not.

Fred

6

Frederick C. wrote:

documentation.
find
(ActionController::Base)").

Which is there as far as I can tell:
Peak Obsession

The documentation is there, but if it is the right documentation to look
for, it doesn’t include description about the behaviour of specifying a
string as the “options” param. It only describes action rendering and
partial rendering.

application.erb:

next Rails releases. Once a feature is documented, there is a great
chance
it will continue to be supported…

Well the key thing is for there to be tests describing the
functionality. Tests get automatically checked, docs don’t

This assumes everyone knows about test units. There shouldn’t be the
case.
The documentation should also state the supported features… A change
patch
should group the code change, the documentation change and the test unit
change, when they apply…

I would like to help documenting such missing documentation, but I
need some
instructions how can I do that: how to make patches, and need to
know how
do these methods actually work.

lifo’s docrails project on github is the place to go.

Thanks for pointing that, I’ll look forward that.

Rodrigo.

7

Hi Rodrigo:

I know a screencast from railscasts.com that shows how to contribute
to Rails with patches. In the example, the author contributes some
documentation wich is precisely what you intend to do.

Enjoy.

On Sep 2, 10:58 pm, Rodrigo Rosenfeld R. [email protected]

8

Thanks, Abel. I’ve downloaded and watched it.

Frederick C. has also noted about lifo’s docrails project on github.

It seems more interesting, and now I’m playing a bit with git, before
trying
to contribute.

The next step is to understand the related source code. When trying to
get
the picture, I’ve found the following piece of uncommented code that I
couldn’t understand. I tried to ask on ruby-talk newsgroup, but no one
answered…

def templates_in_path
(Dir.glob("#{@path}//*/") | Dir.glob("#{@path}/**")).each do
|file|
unless File.directory?(file)
yield Template.new(file.split("#{self}/").last, self)
end
end
end

That got me intrigued. What is the difference between
Dir.glob("#{@path}//*/") | Dir.glob("#{@path}/")
and just
Dir.glob("#{@path}/")
?

Thanks,

Rodrigo.