make_methodp - En ligne dans le Cloud

PROGRAMME:

Nom

make_method - Transforme le code Perl en une description XML pour RPC::XML::Server

SYNOPSIS

make_method --name=system.identification --helptext='Chaîne d'ID système'
--signature=chaîne --code=ident.pl --output=ident.xpl

make_method --base=méthodes/identification

DESCRIPTION

Il s'agit d'un outil simple pour créer les fichiers descriptifs XML pour spécifier les méthodes à
publié par un RPC::XML::Serveurserveur basé.

Si un serveur est écrit de telle sorte que les méthodes qu'il exporte (ou publie) font partie du
exécuter du code, alors il n'y a pas besoin de cet outil. Cependant, dans les cas où le serveur peut
être séparé et distinct du code (comme un serveur RPC basé sur Apache), en spécifiant
les routines et le remplissage des informations justificatives peuvent être fastidieux.

Une solution que le RPC::XML::Serveur les offres de packages sont le moyen de charger les publiables
code à partir d'un fichier externe. Le fichier est dans un dialecte XML simple qui délimite clairement le
nom visible de l'extérieur, les signatures de méthode, le texte d'aide et le code lui-même. Ces
les fichiers peuvent être créés manuellement, ou cet outil peut être utilisé comme une aide.

EST REQUIS ARGUMENTS

Il n'y a pas d'arguments requis, mais s'il n'y a pas suffisamment d'options passées, vous
être averti par un message d'erreur.

OPTIONS

L'outil reconnaît les options suivantes :

--Aidez-moi
Imprime un bref résumé des options.

--name=CHAINE
Spécifie le nom publié de la méthode en cours de codage. C'est le nom par lequel il
sera visible pour les clients du serveur.

--namespace=CHAINE
Spécifie un espace de noms dans lequel le code de la méthode sera évalué, lorsque le XPL
fichier est chargé par une instance de serveur.

--type=CHAINE
Spécifiez le type du fichier résultant. « Type » désigne ici si le conteneur
La balise utilisée dans le XML résultant spécifiera un procédure ou méthode. La valeur par défaut est
méthode. La chaîne est traitée indépendamment de la casse, et seul le premier caractère ("m" ou
"p") est en fait considéré.

--version=CHAINE
Spécifiez un tampon de version pour la routine de code.

--caché
Si cela est réussi, le fichier résultant inclura une balise qui indique au démon du serveur
de ne pas rendre la routine visible à travers des interfaces d'introspection.

--signature=CHAÎNE [ --signature=CHAÎNE ... ]
Spécifiez une ou plusieurs signatures pour la méthode. Les signatures doivent être les noms de type comme
présenté dans la documentation en RPC::XML, avec les éléments séparés par deux points. Tu
peut également les séparer par des espaces, si vous citez l'argument. Cette option peut être
spécifié plus d'une fois, car certaines méthodes peuvent avoir plusieurs signatures.

--helptext=CHAINE
Spécifiez le texte d'aide de la méthode sous la forme d'une simple chaîne sur la ligne de commande. Pas
adapté aux chaînes d'aide terriblement longues.

--helpfile=FICHIER
Lisez le texte d'aide de la méthode à partir du fichier spécifié.

--code=FICHIER
Lisez le code réel de la routine à partir du fichier spécifié. Si cette option n'est pas
donné, le code est lu à partir du descripteur de fichier d'entrée standard.

--output=FICHIER
Écrivez la représentation XML résultante dans le fichier spécifié. Si cette option n'est pas
donné, alors la sortie va au descripteur de fichier de sortie standard.

--base=NOM
Il s'agit d'une option spéciale "tout-en-un". Si elle est passée, toutes les autres options sont ignorées.

La valeur est utilisée comme élément de base pour lire les informations d'un fichier nommé
BASE.base. Ce fichier contiendra la spécification du nom, de la version, du statut caché,
signatures et autres informations sur la méthode. Chaque ligne du fichier doit ressembler à l'une des
ce qui suit:

Nom : STRING
Spécifiez le nom de la routine en cours de publication. Si cette ligne n'apparaît pas,
alors la valeur du --base argument avec tous les éléments de répertoire supprimés sera
utilisé.

Version: STRING
Fournissez un tampon de version pour la fonction. Si aucune ligne correspondant à ce modèle n'est
présent, aucune balise de version ne sera écrite.

Caché: STRING
Si présent, STRING doit être soit "oui" soit "non" (cas sans importance). Si c'est
"oui", alors la méthode est marquée pour être cachée de toute API d'introspection.

Signature: STRING
Cette ligne peut apparaître plusieurs fois et est traitée de manière cumulative. Autres options
remplacer les valeurs précédentes si elles apparaissent plus d'une fois. La partie suivant le
La partie « Signature : » est considérée comme une signature publiée pour la méthode, avec
éléments séparés par des espaces. Chaque méthode doit avoir au moins une signature, donc
un manque de tout provoquera une erreur.

Fichier d'aide : STRING
Spécifie le fichier à partir duquel lire le texte d'aide. Ce n'est pas une erreur si aucune aide
le texte est spécifié.

Fichier de code : STRING
Spécifie le fichier à partir duquel lire le code. Le code est supposé être Perl, et
sera étiqueté comme tel dans le fichier résultant.

Fichier de code[lang] : un magnifique
Spécifie le fichier à partir duquel lire le code, tout en identifiant également la langue
dans lequel se trouve le code. Cela permet la création d'un XPL fichier qui comprend
implémentations en plusieurs langages de la méthode ou de la procédure donnée.

Toutes les autres lignes que les modèles ci-dessus sont ignorées.

Si aucun code n'a été lu, l'outil se fermera avec un message d'erreur.

La sortie est écrite dans BASE.xpl, en préservant les informations de chemin afin que le
le fichier résultant est juste à côté des fichiers source. Cela permet des constructions telles que :

make_method --base=méthodes/introspection

DOSSIER Format ET DTD

Le format de fichier de ces routines publiées est un dialecte XML très simple. C'est moins
en raison du fait que XML est un format idéal que la disponibilité de l'analyseur, étant donné que le
RPC::XML::Serveur class aura déjà le code de l'analyseur dans core. Écrire un tout nouveau
le format n'y aurait rien gagné.

La déclaration de type de document pour le format peut être résumée par :

<!ELEMENT proceduredef (nom, espace de noms ?, version ?, caché ?,
signature+, aide ?, code)>
<!ELEMENT methoddef (nom, espace de noms ?, version ?, caché ?,
signature+, aide ?, code)>
<!ELEMENT functiondef (nom, espace de noms ?, version ?, caché ?,
signature+, aide ?, code)>









Le fichier "rpc-method.dtd" fourni avec la distribution contient des commentaires en plus
à la spécification réelle.

Un fichier est (pour l'instant) limité à une définition. Cela commence par celui de l'ouverture
Mots clés " ", " " ou " ". Ceci est suivi d'exactement un
" " conteneur spécifiant le nom de la méthode, un tampon de version facultatif, un
indicateur de dissimulation d'introspection, un ou plusieurs " " conteneurs spécifiant les signatures,
une option " " contenant le texte d'aide, puis le " container with the " " container with the
code de programme réel. Tout le texte doit utiliser un codage d'entité pour les symboles :

& C<&> (esperluette)
E C<<> (inférieur à)
E C<>> (supérieur à)

Le processus d'analyse au sein de la classe serveur décodera les entités. Pour faire des choses
plus facile, l'outil scanne tous les éléments de texte et encode les entités ci-dessus avant d'écrire le
fichier.

La Spécification of Code
Ce n'est pas "La programmation 101, ni n'est-ce "Perl en le Quelque peu Faible". Le code qui est
transmis via l'un des fichiers "*.xpl" est transmis à "eval" sans pratiquement aucune modification
(voir ci-dessous). Ainsi, un code mal écrit ou malveillant peut très bien faire des ravages sur votre
serveur. Ce n'est pas la faute du code serveur. Le prix de la flexibilité de ce système
offres est la responsabilité du développeur de s'assurer que le code est
testé et sûr.

Le code lui-même est traité aussi textuellement que possible. Certaines modifications peuvent survenir côté serveur,
car cela rend le code adapté à la création d'un sous-programme anonyme à partir de. Les make_method
l'outil tentera d'utiliser une section "CDATA" pour intégrer le code dans le document XML, donc
qu'il n'est pas nécessaire d'encoder des entités ou autres. Cela permet le résultat *.xpl
les fichiers doivent être syntaxiquement testables avec "perl -cx". Vous pouvez y contribuer en vous assurant que le code
ne contient aucune des deux séquences de caractères suivantes :

]]>

__DATA__

Le premier est le terminateur "CDATA". Si cela se produit naturellement dans le code, cela déclenchera
la fin de section dans l'analyseur. Le second est le jeton Perl familier, qui est inséré
afin que le reste du document XML n'encombre pas l'analyseur syntaxique Perl.

EXEMPLES

La RPC::XML distribution est livré avec un certain nombre de méthodes par défaut dans un sous-répertoire appelé
(assez cryptiquement) "méthodes". Chacun d'eux est exprimé comme un ensemble de ("*.base",
"*.code", "*.help"). Le fichier Makefile.PL configure le Makefile résultant tel
que ceux-ci sont utilisés pour créer des fichiers "*.xpl" à l'aide de cet outil, puis les installer.

DIAGNOSTIC

La plupart des problèmes se présentent sous la forme de messages d'erreur suivis d'une sortie brutale.

EXIT STATUT

L'outil se termine avec un état de 0 en cas de succès et de 255 dans le cas contraire.

MISES EN GARDE

Je n'aime pas beaucoup cette approche pour spécifier les méthodes, mais j'ai même aimé mes autres idées
Moins.

Utilisez make_methodp en ligne à l'aide des services onworks.net