Je n'ai trouvé aucune raison de l'existence de quelques-unes des classes du moteur d'application. Il y a un phonenumber, un lien, une postaladdress, une Geopt, une note, etc. Pourquoi ces traitements sont-ils donnés? Ils ne semblent pas avoir de SMARTS - E.G. Recherche géographique. Je sais que le lien a plus d'espace qu'une propriété à cordes, mais le reste?
Voir: http://code.google.com/appengine/docs/java/dataStore /dataclasses.html
4 Réponses :
Je pense qu'ils sont surtout là pour couvrir les cas communs et économiser du temps des développeurs. Si beaucoup d'applications utilisent un champ de numéro de téléphone, pourquoi demander à chaque développeur de devoir les écrire? Un développeur peut toujours écrire leur propre si elles ont besoin / veulent.
D'accord, sauf que le coût semble être ajouté à l'API avec très peu d'avantages. Nous n'avons pas besoin d'un type de téléphone - String fonctionne parfaitement et maintenant, nous devons gettoir hors du phonenumber.
Vraiment? La chaîne peut-elle gérer les différences entre les numéros de téléphone américains et britanniques sans code extérieur? Disclaimer: N'utilisez jamais ces classes, vous ne pouvez donc pas dire si elles le font non plus.
Macha, malheureusement, ils ne le font pas, ce qui est tout le point. Ils sont juste des wrappers pour les cordes.
Ces types sont des types «sémantiques». Ils sont présents dans l'API Java pour la parité avec l'API Python. Dans l'API Python, ils définissent un comportement spécial en ce qui concerne la méthode .TO_XML () - par exemple, une phonenumberproperty Serialise comme ceci:
<property name="foo" type="gd:phonenumber"><gd:phoneNumber>12345-678</gd:phoneNumber></property>
Diriez-vous qu'il y a un avantage dans l'utilisation? Devons-nous importer les classes dans les requêtes?
Je ne me dérangerais pas avec eux, personnellement. Les requêtes n'utilisent pas du tout les classes, autant que je sache.
+1 à ce que Nick a dit. La frappe sémantique dans le magasin de données a été une forte concentration au début du développement de l'App moteur, mais elle est devenue moins prioritaire plus tard. Au moment où nous avons lancé, c'était une mineure agréable à avoir, pas beaucoup plus.
Utiliser essentiellement que ces types de modèles permettent d'ajouter des métadonnées indirectes à votre code. Cela peut être utile si vous travaillez avec n'importe quel type de rendu universel pour vos classes de modèle ou si vous effectuez une validation de la saisie de l'utilisateur sur vos modèles.
Par exemple, si vous utilisez le type de phonénumber pour un champ nommé USERERNUMBUMBER, le rendu basé sur la réflexion peut comprendre qu'elle devrait affecter automatiquement le validateur correspondant au champ de texte qui le représentera.
Cordialement, Pavel.
Pas sûr de Java, mais en Python, le modèle / code suivant (testé sur Dev Server) lancera BadvalueError, avec le message "URL invalide: Stackoverflow.com"
bar.link = 'http://stackoverflow.com'