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
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
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.> TIA. > > ... doug-- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
>> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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.> > ... dougBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Tue, Jun 29, 2010 at 2:50 PM, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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 :-) 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 ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hassan Schroeder wrote:> On Tue, Jun 29, 2010 at 2:50 PM, Marnen Laibow-Koser > <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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.> > 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 ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > twitter: @hassan-- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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.> > Thanks for the input. > > ... doug-- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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.> >> >> Thanks for the input. >> >> ... doug > > > -- > Marnen Laibow-Koser > http://www.marnen.org > marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > > Sent from my iPhone-- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.