J'écris un script Groovy (dans le cadre d'un greffon Grails) et je veux obtenir une liste de propriétés pour un GrailsDomainClass qu'un utilisateur de mon plugin pourrait définir. Je peux le faire en utilisant domainClass.properties
(où domainClass est un GrailsDomainClass).Distinguer entre les champs de domaine de Grails et les méthodes getBlah() via GrailsDomainClassProperty
Cependant, supposons qu'un utilisateur a la classe de domaine de Grails:
class Example {
String name
static constraints = {
}
def getSomeNonExistingProperty(){
return "Not-a-real-property"
}
}
Dans ce cas, domainClass.properties
retourne une liste avec les deux name
et someNoneExistingProperty
Je comprends que ce soit à cause de Grails génère un propriété en lecture seule à la volée à utiliser lorsque quelqu'un a une méthode getBlah(). C'est génial, mais dans mon script, je veux effectuer quelques actions avec les propriétés "réelles" seulement (ou au moins des propriétés non-lecture seule). C'est-à-dire, je voudrais un moyen de distinguer ou d'identifier someNonExistingProperty
comme une propriété en lecture seule, ou, en variante, comme une propriété générée par Grails et non explicitement entré comme un champ dans la domainClass par l'utilisateur de mon plugin .
J'ai regardé la classe GrailsDomainClassProperty et il a une gamme de méthodes fournissant des informations sur la propriété. Cependant, aucun d'entre eux ne semble me dire si une propriété est en lecture seule ou non, ou me permettre de distinguer entre un champ défini dans domainClass et un champ créé à la volée par Grails à la suite d'un getSomeNonExistingProperty()" méthode.
Est-ce que je manque quelque chose d'évident ici? Est-il possible d'obtenir une liste des champs explicitement définis par l'utilisateur (par exemple, le nom, dans l'exemple ci-dessus)?
Renommer les méthodes getX() fonctionnerait, sauf qu'il s'agit d'un plugin, donc ce n'est pas (en général) mon code sur lequel le script agit - je ne veux pas insister sur le fait que toute personne utilisant le plugin devrait éviter Méthodes getX(). L'idée d'utiliser la réflexion mérite d'être suivie, merci. Je verrai si cela aide - mais je suis douteux car il y aura alors le problème inverse de ne pas exclure les propriétés "réelles" qui, néanmoins, ont une méthode getX() qui leur est associée. – Glennn