Referencing a Layout

My understanding is that Rails generally expects layouts to be files
and any reference to a layout is a path to the appropriate file.
Thus, a layout that is generated at run time and stored only in memory
(as a variable), can only be loaded by first writing the layout to a
temporary disk file and then loading it from there. Am I correct in
my understanding?

TIA.

          ... doug

Doug Jolley wrote:

My understanding is that Rails generally expects layouts to be files
and any reference to a layout is a path to the appropriate file.
Thus, a layout that is generated at run time and stored only in memory
(as a variable), can only be loaded by first writing the layout to a
temporary disk file and then loading it from there. Am I correct in
my understanding?

I believe so. But why would you ever do that? Layouts are designed to
hold the parts of your view that don't change. If they don't change,
you shouldn't need to generate them on the fly.

But why would you ever do that? Layouts are designed to
hold the parts of your view that don't change. If they don't change,
you shouldn't need to generate them on the fly.

What I'd really like to be able to do is to allow for an external
layout. That is, when another site links to the resource, it could
append a parameter to the URL specifying the URL of an alternative
layout to be used. Typically the alternative layout would be located
on the host linking *TO* the resource. I'd have to get the layout
across the network and that's how I wind up with it in a variable.

I mentioned this in another post and from the limited responses that I
received I concluded that almost no one else has any interest in doing
this sort of thing. I find that a bit surprising and it leaves me
wondering if I am not missing some other more popular way of skinning
this cat. Anyway, that's the rationale behind my inquiry. Thanks for
the input.

           ... doug

But why would you ever do that? Layouts are designed to
hold the parts of your view that don't change. If they don't change,
you shouldn't need to generate them on the fly.

What I'd really like to be able to do is to allow for an external
layout. That is, when another site links to the resource, it could
append a parameter to the URL specifying the URL of an alternative
layout to be used. Typically the alternative layout would be located
on the host linking *TO* the resource. I'd have to get the layout
across the network and that's how I wind up with it in a variable.

I hope you're going to cache that layout....

I mentioned this in another post and from the limited responses that I
received I concluded that almost no one else has any interest in doing
this sort of thing. I find that a bit surprising and it leaves me
wondering if I am not missing some other more popular way of skinning
this cat. Anyway, that's the rationale behind my inquiry. Thanks for
the input.

Why not make your third party partners create a special HTML page and include an HTML comment that indicates where the content goes. Something like...

<html>
<head>.....</head>
<body>
   <h1>My Groovy Layout</h1>
   <!-- CONTENT -->
   <div>Footer Stuff</div>
</body>
</html>

Whatever they want as long as that comment is there.

Then you can read in that file, split it on that html comment and assign the first half to @top and the second half to @bottom and then have a layout like:

<%= @top %>
<%= yield %>
<%= @bottom %>

I'd probably pick better names for top/bottom to avoid conflicts, but you get the idea.

I'm ignoring all of the issues surrounding relative/absolute urls to JS, CSS, images and any XSS issues, etc...

And whatever you do... cache it for awhile.

-philip

Doug Jolley wrote:

�But why would you ever do that? �Layouts are designed to
hold the parts of your view that don't change. �If they don't change,
you shouldn't need to generate them on the fly.

What I'd really like to be able to do is to allow for an external
layout. That is, when another site links to the resource, it could
append a parameter to the URL specifying the URL of an alternative
layout to be used. Typically the alternative layout would be located
on the host linking *TO* the resource. I'd have to get the layout
across the network and that's how I wind up with it in a variable.

I mentioned this in another post and from the limited responses that I
received I concluded that almost no one else has any interest in doing
this sort of thing. I find that a bit surprising and it leaves me
wondering if I am not missing some other more popular way of skinning
this cat. Anyway, that's the rationale behind my inquiry. Thanks for
the input.

Yiure going about this backwards. Your site shouldn't be doing your
consumers' layout work. Instead, it sshould provide data that your
consumers can lay out as they please.

           ... doug

Best,

Heh. Exactly what I said the first time :slight_smile:

Consider this scenario:

I go to a site, navigate around, click some link and all of a sudden
the URL in the address bar totally changes to some other site. But
the page appearance stays the same.

Suspicious? You bet. Has "phishing" written all over it. Me likey?
No. Me gone :slight_smile:

And that's aside from the already mentioned XSS/single-site-origin
issues, relative URL refs, etc.

I would never use such a scheme, nor recommend a client do so...

YMMV!

Hassan Schroeder wrote:

I mentioned this in another post and from the limited responses that I
received I concluded that almost no one else has any interest in doing
this sort of thing. �I find that a bit surprising ...

Yiure going about this backwards. �Your site shouldn't be doing your
consumers' layout work. �Instead, it sshould provide data that your
consumers can lay out as they please.

Heh. Exactly what I said the first time :slight_smile:

Consider this scenario:

I go to a site, navigate around, click some link and all of a sudden
the URL in the address bar totally changes to some other site. But
the page appearance stays the same.

Suspicious? You bet. Has "phishing" written all over it. Me likey?
No. Me gone :slight_smile:

See, I don't agree with that objection. There are plenty if hosted
services that can be skinned to look like your own site. That part is
fine. But they don't generally use transient layouts like Doug is
proposing.

Why not make your third party partners create a special HTML page and include
an HTML comment that indicates where the content goes. Something like...

<html>
<head>.....</head>
<body>
<h1>My Groovy Layout</h1>
<!-- CONTENT -->
<div>Footer Stuff</div>
</body>
</html>

So, it looks like what you're proposing is more-less a re-invention of
an alternative layout facility. Notice that if you were to replace
the '<!-- CONTENT -->' in your code with '<%= yield(:layout) %>' the
result would be a typical layout. It's something to consider. I was
just trying to use the existing layout facility. I think that
approach might be a bit more robust and it might integrate better.
Thanks for the input. As I say, it's something to consider.

        ... doug

Your site shouldn't be doing your
consumers' layout work.

I don't think that it is. What I'm trying to do is to come up with a
mechanism that will allow the consumers to do their own layout work.

Instead, it sshould provide data that your
consumers can lay out as they please.

That is clearly the preferred approach. However, it is also the most
labor intensive. I see the external layout approach as a lower
quality alternative that might be acceptable in some circumstances.
One of its big advantages is that (but for problematic issue of
reading the layout from the contents of a variable) it is extremely
easy to implement. I just wish that there were some sort of easy work
around other than taking the brute force tact of writing the data to a
temp file and then reading it from there.

Thanks for the input.

           ... doug

Doug Jolley wrote:

Your site shouldn't be doing your
consumers' layout work.

I don't think that it is.

Do you have a reason for this opinion, or are you just handwaving?

What I'm trying to do is to come up with a
mechanism that will allow the consumers to do their own layout work.

�Instead, it sshould provide data that your
consumers can lay out as they please.

That is clearly the preferred approach. However, it is also the most
labor intensive.

No. It is just as labor-intensive for your consumers to provide a
layout for you as it is for them to do the layout themselves. There's
really no advantage for them, and there's a disadvantage for you.

I see the external layout approach as a lower
quality alternative that might be acceptable in some circumstances.
One of its big advantages is that (but for problematic issue of
reading the layout from the contents of a variable) it is extremely
easy to implement. I just wish that there were some sort of easy work
around other than taking the brute force tact

"tack" -- "tact" is a different word.

of writing the data to a
temp file and then reading it from there.

There is. Stop thinking in terms of layouts and use Philip's
approach...

...except that the whole thing is completely infeasible. How would the
layout be provided? It won't fit in a GET query string, and you can't
supply POST data in a link, so the only way to supply it would be as an
uploaded file. And at that point, you can just go back to Rails' layout
mechanism.

Marnen Laibow-Koser wrote:
[...]

...except that the whole thing is completely infeasible. How would the
layout be provided? It won't fit in a GET query string, and you can't
supply POST data in a link, so the only way to supply it would be as an
uploaded file. And at that point, you can just go back to Rails' layout
mechanism.

Oh, on rereading the original post, I see that you were going to use a
URL, which gets around that particular feasibility problem. Looked at
with that in mind, it seems more like an HTML version of the JSONP
pattern. But I still think it isn't very useful.