On Dec 5, 2011, at 1:55 PM, JavierQQ wrote: > > > On 5 dic, 13:32, Walter Lee Davis <[email protected]> wrote: > >> >> A select can be traversed like any other DOM object, this should be fairly >> close: >> >> #given doc is a Nokogiri::XML or Nokogiri::HTML nodeset >> doc.css('#yourPickerId option').each do |opt| >> foo = opt['value'] >> #whatever else you want to do with foo here >> end >> > > Thanks, in nokogiri example the result is like "link.content" and > that's why I wondering how I can grab that information from the select > group
There are some basic things one can do with nodes once you find them. content() spills out the textual content of any node (in the case of an option, that might give you the same thing as the Option.text attribute in JavaScript, but I wouldn't count on it specifically. In the case of a div, for example, content would give you the textual content of that div, minus any HTML tags, while inner_html would give you the actual HTML code defining all of the content tags as well as their text content. For everything else, any other named attribute on the given node you access simply by putting the name of the attribute in as a key: my_select['label'] or my_select['value'] or my_select['selected'] for example. Behind the scenes, Nokogiri does some elegant metaprogramming with method_missing and gives you what you ask for if it's available. > > >> >> Possible, sure. It's never entirely clear why someone would run an Ajax >> request to populate a page. They may have done it to keep the scrapers out >> (like you), or they may have done it to isolate and accelerate a laggy part >> of the initial page load. If the latter (so they aren't actually >> discouraging you -- did you ask them if you could do this?) then you might >> also want to look into loading the endpoint of that Ajax request instead of >> the surrounding page, as that would eliminate the whole JavaScript >> abstraction entirely. You'd have one HTTP request, and unless that endpoint >> was kinked to only accept requests from within its own domain, you would >> likely have JSON or some other structured data in return, and that could be >> even easier to interpret in your application. >> >> Walter >> >> > > You mean that in order to make a better application I have to deliver > the information as JSON ? I have seen this technique used for this reason, by splitting the application load over time on the same server or across servers. But then I would just throw a cacheing layer at the problem. Much less heartache. I've also seen this technique used to obfuscate the data source, or simply to integrate third-party data sources into an existing site. . > I'm kind of new with rails (not a completly newbie but... sort of :D ) Me too, but I've done quite a lot of Nokogiri recently, so it's all fairly fresh. Walter > > Thanks for your help > > Javier Q > > -- > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
