Je suis très nouveau dans le rubis et les rails. J'essaye de sortir toutes les informations whois analysées vers la sortie json. J'ai ce qui suit:
msg = {}
for prop in Whois::Parser::PROPERTIES
msg[prop] = parser.send(prop) if parser.respond_to?(prop)
end
render :json => msg
Sortie:
undefined method `has_attribute?'
Cependant, l'analyseur a BEAUCOUP plus d'informations disponibles .... sans tout savoir les champs disponibles, comment puis-je vider toutes les clés / valeurs dans json?
J'ai essayé:
msg = {}
for x_prop in Whois::Parser::PROPERTIES
parser.has_attribute?(:x_prop)
msg[x_prop] = parser.send(x_prop)
end
render :json => msg
Mais j'ai fini par obtenir: p>
Unable to find a parser for property `registrant_contacts'
EDIT:
J'ai aussi essayé:
class WhoisController < ApplicationController
def index
c = Whois::Client.new
record = c.lookup("google.com")
parser = record.parser
msg = {}
for x_prop in Whois::Parser::PROPERTIES
msg[x_prop] = parser.send(x_prop)
end
render :json => msg
end
end
Mais finit par obtenir une autre erreur:
undefined method `attributes' for #<Whois::Parser:0x00007fc030d74018>
Python et Go (par réflexion) peuvent le faire. Quelle est la manière Ruby pour y parvenir?
EDIT:
parser.attributes.each do |attr_name, attr_value| puts attr_name end
Cela fonctionne UNIQUEMENT si toutes les propriétés existent sur l'analyseur. Cependant, certains noms de domaine n'ont pas toutes les propriétés et entraîneront:
SystemStackError in WhoisController#index
J'essaye alors de le définir uniquement si cette propriété existe:
class WhoisController < ApplicationController
def index
c = Whois::Client.new
record = c.lookup("google.com")
parser = record.parser
msg = {:whois => parser}
render :json => msg
end
end
J'obtiens une autre erreur:
{"created":"1997-09-15T00:00:00.000-07:00"}
EDIT # 3:
J'ai aussi essayé:
class WhoisController < ApplicationController
def index
c = Whois::Client.new
record = c.lookup("google.com")
parser = record.parser
created = parser.created_on
msg = {:created => created}
render :json => msg
end
end
Cela échoue toujours si la propriété est manquante dans l'analyseur. ; (
3 Réponses :
Pour SystemStackError dans WhoisController # index :
Je pense que c'est parce que vous appelez à nouveau whois avec Whois à record = Whois.whois ("google.com") . Essayez record = whois ("google.com") .
Pour méthode non définie `attributes 'for # :
La méthode attributes ne quitte pas l'analyseur whois.
Voir https://whoisrb.org/docs/v3/parser-properties/ .
Whois.whois est valide ... aussi whois.lookup est également valide. Je mixais et assortis. J'ai édité les échantillons.
donc, il n'y a aucun moyen de parcourir tous les champs? En python et allez-y, il existe des moyens de le faire.
@MarissaLevy Je ne dirais pas qu'il n'y a aucun moyen. Mais vous devrez écrire vous-même la boucle pour parcourir les propriétés de l'analyseur. Parfois, certaines bibliothèques présentent des différences mineures entre les fonctions / méthodes qu'elles fournissent pour plusieurs langues.
Vous pouvez utiliser les méthodes ou inspect.
render json: parser.inspect.to_json
c = Whois::Client.new
record = c.lookup("google.com")
parser = record.parser
render json: parser.methods.to_json
begin
msg[x_prop] = parser.send(x_prop)
rescue
# do nothing
end
Sur certains d'entre eux, j'obtiens "Impossible de trouver un analyseur pour la propriété` registrant_contacts '"
parser.has_attribute? (: prop) msg [prop] = parser.send (prop) J'obtiens la méthode non définie `has_attribute? '
@MarissaLevy utilise simplement une capture d'essai, comme ma modification sur réponse
merci pour aider un newb .... une autre prime à venir quand je suis autorisé à le récompenser.
La question ici est: Pourquoi utiliser une boucle for alors que vous pouvez utiliser #each ? Ou #each_with_object a> d'ailleurs.
for ... in est très unidiomatique pour Ruby. Ce n'est pas faux, mais l'utilisation d'itérateurs tels que la suggestion de @ JohanWentholt conduit généralement à un code plus concis et compréhensible. En outre, la vérification de la capacité à effectuer une tâche ( if..else..end ) est généralement plus performante au point que le sauvetage. Rescue est mieux utilisé pour intercepter les exceptions , ce qui est inattendu, et non pour gérer les échecs attendus.
L'autre problème avec for ... in est qu'il ne crée pas de nouvelle portée. Toutes les variables définies dans la portée (y compris x_prop ) sont toujours disponibles après l'itération. Cela peut parfois conduire à un comportement inattendu. Alors que l'utilisation d'un itérateur ajoutera une nouvelle portée sur la portée actuelle, vous permettant d'observer des variables externes ou de définir des variables qui ne sont disponibles que lors de l'itération. Dans certains cas, vous voudrez peut-être utiliser for ... in , mais en général si vous n'avez pas de raison valable d'utiliser #each .