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 
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
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
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
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.