2008-11-04 6 views
3

Je suis curieux de savoir comment les gens utilisent les to_xml() d'AR pour créer des champs non-entité (comme dans, pas un attribut du modèle que vous numérotez, mais peut-être, en utilisant le attributs dans le processus) à partir d'un contrôleur.Création de champs dynamiques à l'aide de ActiveRecord :: Serialization.to_xml

to_xml semble fournir quelques options pour ce faire. L'un est en passant des références à des méthodes sur l'objet sur lequel on agit: pendant le processus de sérialisation, ces méthodes sont invoquées et leurs résultats sont ajoutés au document généré. Je souhaite éviter ce chemin car certaines des données générées, tout en dépendant des attributs de l'objet, pourraient être en dehors de la portée du modèle lui-même - par exemple, en construisant une URL pour une action "show" d'éléments particuliers. De plus, cela nécessite trop de prévoyance. Je voudrais juste pouvoir changer le document résultant en ajustant le code to_xml du contrôleur. Je ne veux pas non plus avoir à déclarer une méthode dans l'objet.

La même chose vaut pour redéfinir to_xml dans chaque objet. Les deux autres options semblent mieux correspondre à la facture: l'une consiste à passer dans procs dans les options de sérialisation qui génèrent ces champs, et l'autre est de passer dans un bloc qui donnera après la sérialisation les attributs des objets . Ceux-ci fournissent le type de personnalisation au moment de l'invocation que je recherche, et en outre, leurs déclarations lient la portée au contrôleur afin qu'ils aient accès aux mêmes choses que le contrôleur, mais ces les méthodes semblent critiques: AFAICT elles ne contiennent aucune référence à l'objet en cours de sérialisation. Ils contiennent des références à l'objet builder, qui, je suppose que vous pourriez analyser dans le bloc/proc et trouver les attributs qui ont déjà été sérialisés et les utiliser, mais c'est une harangue, ou au moins mal à l'aise et sous-optimale.

Corrigez-moi si je me trompe ici, mais à quoi cela sert-il d'avoir des procs/blocks disponibles lors de la sérialisation d'un ou plusieurs objets si vous devez accéder à l'objet lui-même. Quoi qu'il en soit, s'il vous plaît dites-moi comment je me trompe, car il semble que je doive négliger quelque chose ici. Oh et oui, je sais que je pourrais écrire ma propre opinion. J'essaie d'exploiter respond_to et to_xml pour obtenir un minimum de fichiers/lignes supplémentaires. (Bien que, c'est ce que j'ai eu recours quand je ne pouvais pas comprendre comment faire avec la sérialisation d'AR.)

** EDIT 3.29.09 - Je viens de soumettre un patch pour cela à Rails. Si vous êtes intéressé, montrez un peu de soutien :) https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2373-record-sensitive-procs-for-to_xml

Répondre

1

En fait, le processus Proc est passé les mêmes hachages d'options (moins l'option procs) que vous avez passé à to_xml. Ainsi, vous pouvez passer des objets supplémentaires Proc a besoin pour faire son travail:

proc = Proc.new {|options| options[:builder].tag!('reverse-name', options[:object].name.reverse)} 
object.to_xml :object => object, :procs => [ proc ] 

Puisque vous obtenez le proc obtient les mêmes options to_xml est, cela vous permet de passer dans les options que vous avez besoin.

+1

Ainsi, dans votre exemple, "objet" est une paire de k/v supplémentaire que vous utilisez et qui sera transmise à chaque appel de sérialisation et proc. C'est bon. Cela crée certainement des possibilités. Le défi demeure: comment feriez-vous cela sur un tableau? Passer dans le tableau comme un k/v supplémentaire et itérer en tandem? : / – jmaxyz