Hi -- I''ve got some ESI variables in a template, and am trying to assign their values to Ruby variables. Strangely, it seems to work and not work at the same time. Here''s the relevant part of the template, with some comments and followed by explanation: <esi:vars> <% state = "$(GEO{''region_code''})" %> <% city = "$(GEO{''city''})" %> State: <%= state %><br/> # CT City: <%= city %><br/> # NEWHAVEN Massaged city: <%= CITIES[state][city] %> # Uses the literal EIS strings </esi:vars> The CITIES hash provides corrected city names when the ESI value lacks spaces -- so, for example, CITIES["CT"]["NEWHAVEN"] is "New Haven". The state and city variables display correctly in those middle lines -- but when addressing the CITIES hash with those same variables, they''re evaluated as the literal ESI strings ("$(GEO..."). The evidence for this is that I''ve seeded the hash: CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] = "KEYING LITERAL ESI STRINGS" and that "KEYING..." string appears next to "Massaged city". So, strange as it sounds, the variables seem to be differently bound depending on which line is being evaluated. So far I''ve not been able to puzzle through the sequence of events in such a way as to come up with a way to inject the state and city values into a call to the CITIES hash. I''d be interested in any ideas or solutions people might have. David -- David A. Black The Well-Grounded Rubyist -- http://www.manning.com/black2 The Compleat Rubyist -- http://www.compleatrubyist.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.
hi david! David A. Black [2011-07-20 15:24]:> <esi:vars> > <% state = "$(GEO{''region_code''})" %> > <% city = "$(GEO{''city''})" %> > > State: <%= state %><br/> # CT > City: <%= city %><br/> # NEWHAVEN > > Massaged city: <%= CITIES[state][city] %> # Uses the literal EIS > strings > > </esi:vars>well, as far as ruby/erb is concerned there is no ESI, right? it simply produces: <esi:vars> State: $(GEO{''region_code''}) City: $(GEO{''city''}) Massaged city: whatever-the-value-of-CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"]-is </esi:vars> the hash lookup occurs before ESI gets any chance to replace the variables. so i don''t think there''s any way to achieve what you want (other than going back to the server by some means after ESI processing has happened). i''m totally unfamiliar with ESI, though, so i might be off. cheers jens -- 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.
Hi David,>I''ve got some ESI variables in a template, and am trying to assign >their values to Ruby variables. Strangely, it seems to work and not >work at the same time.Why mixing them anyway?> <esi:vars> > <% state = "$(GEO{''region_code''})" %> > <% city = "$(GEO{''city''})" %> > > State: <%= state %><br/> # CT > City: <%= city %><br/> # NEWHAVEN<% # becomes: %> State: $(GEO{''region_code''}) City: $(GEO{''city''}) <% # so the ESI processor replaces them after ERB %>> Massaged city: <%= CITIES[state][city] %> # Uses the literal EIS strings<% # becomes: %> Massaged city: <%= CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] # => "KEYING LITERAL ESI STRINGS" %> <% # so the ESI processor replaces ... nothing. %>> </esi:vars>>So, strange as it sounds, the variables seem to be differently bound >depending on which line is being evaluated. So far I''ve not been able >to puzzle through the sequence of events in such a way as to come up >with a way to inject the state and city values into a call to the >CITIES hash. I''d be interested in any ideas or solutions people might >have.You can: process the template with the ESI proc before it''s evaluated by erb or drop erb and define your mapping as ESI variables by writing a script that writes the complete mapping into an esi:include''d file or drop ESI and expose the GEO server variables to erb... or define class ESIlabeth < Struct.new(:name, :words) def initialize(name, *words) super name, words.flatten end def [](word) self.class.new name, words + [ word ] end def to_s ugh = words.map { |word| "[#{ word.inspect }]" }.join %Q''<% #{ name }#{ ugh } %>'' end # or implement to_s in a way it resolves the http vars and then # accesses the real CITIES storage. end CITIES = ESIlabeth.new ''CITIES'' # puts CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] # => CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] and parse it again after ESI did its stuff... :) or implement your own ESI processor and embed it into ruby, ... It''s a matter of the problems environment. Hope I could help. best Florian -- Florian Aßmann Fork Unstable Media -- 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.
Hi -- On Wed, Jul 20, 2011 at 11:51 AM, Jens Wille <jens.wille-31N1O1AsgN5n68oJJulU0Q@public.gmane.org>wrote:> hi david! > > David A. Black [2011-07-20 15:24]: > > <esi:vars> > > <% state = "$(GEO{''region_code''})" %> > > <% city = "$(GEO{''city''})" %> > > > > State: <%= state %><br/> # CT > > City: <%= city %><br/> # NEWHAVEN > > > > Massaged city: <%= CITIES[state][city] %> # Uses the literal EIS > > strings > > > > </esi:vars> > well, as far as ruby/erb is concerned there is no ESI, right? it > simply produces: > > <esi:vars> > > State: $(GEO{''region_code''}) > City: $(GEO{''city''}) > > Massaged city: > whatever-the-value-of-CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"]-is > > </esi:vars> > > the hash lookup occurs before ESI gets any chance to replace the > variables. so i don''t think there''s any way to achieve what you want > (other than going back to the server by some means after ESI > processing has happened). i''m totally unfamiliar with ESI, though, > so i might be off. > >What''s odd is that both behaviors seem to happen: the Ruby variables being bound to the literal GEO strings, and the Ruby variables being bound to the ESI interpolations of those strings. So state and city display as CT and NEWHAVEN... but when used as hash keys, those same variables behave as the literal GEO strings. We solved the problem by doing it all in JavaScript :-) David -- The Ruby training with Black/Brown/McAnally Compleat Stay tuned for next event! Rubyist http://www.compleatrubyist.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.
Hi -- On Wed, Jul 20, 2011 at 12:03 PM, "Florian Aßmann" <florian.assmann@email.de> wrote:> > > Hi David, > > >I''ve got some ESI variables in a template, and am trying to assign > >their values to Ruby variables. Strangely, it seems to work and not > >work at the same time. > > Why mixing them anyway?We need to correct/normalize the cities that have spaces removed, like NEWYORK.> > <esi:vars> > > <% state = "$(GEO{''region_code''})" %> > > <% city = "$(GEO{''city''})" %> > > > > State: <%= state %><br/> # CT > > City: <%= city %><br/> # NEWHAVEN > <% # becomes: %> > State: $(GEO{''region_code''}) > City: $(GEO{''city''}) > <% # so the ESI processor replaces them after ERB %> > >But they display CT and NEWHAVEN, which suggests that they''ve already been ESI-processed.> > Massaged city: <%= CITIES[state][city] %> # Uses the literal EIS strings > <% # becomes: %> > Massaged city: <%= CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] > # => "KEYING LITERAL ESI STRINGS" %> > <% # so the ESI processor replaces ... nothing. %>I''m still mystified as to why/how the same variables can behave in both ways (literal strings and interpolated strings).> > > </esi:vars> > > >So, strange as it sounds, the variables seem to be differently bound > >depending on which line is being evaluated. So far I''ve not been able > >to puzzle through the sequence of events in such a way as to come up > >with a way to inject the state and city values into a call to the > >CITIES hash. I''d be interested in any ideas or solutions people might > >have. > > You can: >[ideas snipped] As I mentioned in my last response we''re going to do it in JavaScript, but I''ll have a look at your ideas which will probably increase my ESI understanding. David -- The Ruby training with Black/Brown/McAnally Compleat Stay tuned for next event! Rubyist http://www.compleatrubyist.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.
David Black [2011-07-20 21:08]:> What''s odd is that both behaviors seem to happen: the Ruby > variables being bound to the literal GEO strings, and the Ruby > variables being bound to the ESI interpolations of those strings.no, it''s not. the ruby variables are replaced with the string values you initialized them with - in *both* places. the ESI processing kicks in *after* that (it operates on what the application sends as HTML response; just like SSI in principle). so there''s nothing unusual going on at all. it''s just that both processors (ruby/erb and ESI) operate in the opposite order than you seem to have assumed. but now that you found a different solution this is all moot, of course ;) -- 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.
Hi David, I''d prefer getting the values from request.env[]. I''d reduce complexity across your application. It also reduces the number of times the document is processed. As Jens said ERB comes before ESI. App (erb) => Server (esi) => World Did you try accessing those HTTP vars (HTTP_GEO) in your Rails app? Do you use Varnish using a pimped version of the GeoIP plugin? best Florian David Black schrieb:> Hi -- > > On Wed, Jul 20, 2011 at 12:03 PM, "Florian Aßmann"<florian.assmann@email.de >> wrote: > >> >> Hi David, >> >>> I''ve got some ESI variables in a template, and am trying to assign >>> their values to Ruby variables. Strangely, it seems to work and not >>> work at the same time. >> Why mixing them anyway? > > > We need to correct/normalize the cities that have spaces removed, like > NEWYORK. > > >>> <esi:vars> >>> <% state = "$(GEO{''region_code''})" %> >>> <% city = "$(GEO{''city''})" %> >>> >>> State:<%= state %><br/> # CT >>> City:<%= city %><br/> # NEWHAVEN >> <% # becomes: %> >> State: $(GEO{''region_code''}) >> City: $(GEO{''city''}) >> <% # so the ESI processor replaces them after ERB %> >> >> > > But they display CT and NEWHAVEN, which suggests that they''ve already been > ESI-processed. > > >>> Massaged city:<%= CITIES[state][city] %> # Uses the literal EIS strings >> <% # becomes: %> >> Massaged city:<%= CITIES["$(GEO{''region_code''})"]["$(GEO{''city''})"] >> # => "KEYING LITERAL ESI STRINGS" %> >> <% # so the ESI processor replaces ... nothing. %> > > > I''m still mystified as to why/how the same variables can behave in both ways > (literal strings and interpolated strings). > > >>> </esi:vars> >>> So, strange as it sounds, the variables seem to be differently bound >>> depending on which line is being evaluated. So far I''ve not been able >>> to puzzle through the sequence of events in such a way as to come up >>> with a way to inject the state and city values into a call to the >>> CITIES hash. I''d be interested in any ideas or solutions people might >>> have. >> You can: >> > [ideas snipped] > > As I mentioned in my last response we''re going to do it in JavaScript, but > I''ll have a look at your ideas which will probably increase my ESI > understanding. > > > David >-- 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.
Hi -- On Wed, Jul 20, 2011 at 3:24 PM, Jens Wille <jens.wille-31N1O1AsgN5n68oJJulU0Q@public.gmane.org> wrote:> David Black [2011-07-20 21:08]: > > What''s odd is that both behaviors seem to happen: the Ruby > > variables being bound to the literal GEO strings, and the Ruby > > variables being bound to the ESI interpolations of those strings. > no, it''s not. the ruby variables are replaced with the string values > you initialized them with - in *both* places. the ESI processing > kicks in *after* that (it operates on what the application sends as > HTML response; just like SSI in principle). so there''s nothing > unusual going on at all. it''s just that both processors (ruby/erb > and ESI) operate in the opposite order than you seem to have assumed >What I''m not seeing is why this: CITIES[state][city] doesn''t undergo the same evaluation/interpolation as this: <%= state %> Whatever happens, I would expect "state" to end up representing the same thing every time, instead of representing the string "CT" at one point and the string "$(GEO{''region_code''})" at another point. Why doesn''t the EIS processing ensure that we get CITIES["CT"]["NEWHAVEN"]?> but now that you found a different solution this is all moot, of > course ;)True :-) except I hate letting things slip away without fully understanding them. David --> 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. > >-- The Ruby training with Black/Brown/McAnally Compleat Stay tuned for next event! Rubyist http://www.compleatrubyist.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.
Hi David, I''ll describe two scenarios and I hope I can clarify the problem. First of all the Mapping: BAZ = { ''GEO_foo'' => { ''GEO_bar'' => ''GEO_baz'' }, "$(GEO{foo})" => { "$(GEO{bar})" => ''KEYING LITERAL ESI STRINGS'' } } Second the default order of processing... 1. source: ------------------------------------------------------------------- <% foo = "$(GEO{''foo''})" %> <% bar = "$(GEO{''bar''})" %> Foo: <%= foo %> Bar: <%= bar %> Baz: <%= BAZ[foo][bar] %> # ... up to this point nothing was evaluated. 2. erb''d: -------------------------------------------------------------------- Foo: $(GEO{''foo''}) Bar: $(GEO{''bar''}) Baz: KEYING LITERAL ESI STRINGS # ... the time erb evaluates the five expressions the first two assign their # values, which still contain the ESI instructions. In the following # expressions these instructions are written to the document. # As for the last expression Ruby tries to resolve the key `$(GEO{''foo''})` in # the BAZ hash. # At this time the BAZ hash has no member with this name resulting in nil # unless otherwise defined. # In the first line you see the assignment I made to produce this - kinda # unwanted - result. 3. ESI: ---------------------------------------------------------------------- Foo: GEO_foo Bar: GEO_bar Baz: KEYING LITERAL ESI STRINGS # Assuming that GEO[''foo''] contains the string GEO_foo and GEO[''bar''] contains # GEO_bar the values are correctly replaced. # But since ''KEYING LITERAL ESI STRINGS'' is not in any way an esi instruction # nothing happens here. *snip* *********************************************************************** So, what happens when we switch 2 and 3? First of all I think this could either suck performance wise or improve it. I don''t know ''cause I''m not so much into socket communication. That aside: 3. ESI: ---------------------------------------------------------------------- <% foo = "GEO_foo" %> <% bar = "GEO_bar" %> Foo: <%= foo %> Bar: <%= bar %> Baz: <%= BAZ[foo][bar] %> # ... the ESI instructions were replaced correctly as intended. 2. erb''d: -------------------------------------------------------------------- Foo: GEO_foo Bar: GEO_foo Baz: GEO_baz # ... well, I think this is the result you expected. Mapping is done # correctly, and Foo: & Bar: show the correct values. *snip* *********************************************************************** Switching step 2 and 3 could be a problem depending on your setup, but not impossible. But still I''d not mix two templating engines as I still think that it is possible to expose, if not already exposed, the GEO variables to your Rack::Request object. They should be members of the #env property. If not you could, if you use VCL and the GeoIP library, modify the plugin in a way it exposes them. best Florian -- 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.
Hi -- On Wed, Jul 20, 2011 at 7:33 PM, Florian Aßmann <florian.assmann-htSm2yLGOjU@public.gmane.org>wrote:> Hi David, > > I''ll describe two scenarios and I hope I can clarify the problem. >[snip explanation] Thanks for the explanation. I think I was over-thinking (or under-thinking :-) it. In the end I think doing it with JavaScript is indeed a better way. David -- The Ruby training with Black/Brown/McAnally Compleat Stay tuned for next event! Rubyist http://www.compleatrubyist.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.