Revidér EL-valideringsindstillinger


De fleste EL-valideringsproblemer kan få deres niveau tilpasset, så det er error, warning eller none. Niveauet none ignorerer fejlen i forbindelse med rapportering.

Indstillinger for EL-problemniveauer

Hvis du vil ændre niveauet for en specifik EL-valideringsproblemtype, skal du åbne dialogboksen Indstillinger ved at klikke på:
Vindue -> Indstillinger... -> Web ->JavaServer Faces Tools -> Validering:


EL-validatorindstillinger

Problemforklaringer


I nedenstående tabel vises de enkelte problemer, hvor niveauet kan tilpasses. Og deres virkning forklares:

BeskrivelseEksempelForklaring
Generel syntaksfejl#{* x}Syntaksfejl er en generel tilsidesættelse af EL-sproget. I dette eksempel forventer multiplikationsoperatoren '*' at have to operander, men der er kun angivet en (x).
Tomt EL-udtryk#{}Angiver, at intet udtryk er angivet.
Udtryk mangler afsluttende parentes#{x + 5Angiver, at der skal tilføjes en afsluttende parentes '}' som i "#{x + 5}"
Anvender operator til metodebinding#{bean.action * 5}Hvis bean.action angiver en metode "action()" på bean, er det ikke gyldig EL at behandle dens resultat som en værdi. I dette eksempel behandles den som en værdi ved at blive multipliceret 5 gange.
Egenskabsnavne med punktummer skal bruge array-syntaks ([]).#{property.name.foo}Hvis name.foo er nøgleværdien i et egenskabsbundtindeks på property, anbefaler EL-specifikationen (men kræver ikke), at du i stedet udtrykker den som property['name.foo'] for at fremhæve det faktum, at name.foo er en nøgle i en tilknytning i modsætning til f.eks. en bean-egenskab.
Variablen findes ikke#{bean property}Hvis bean ikke kan fortolkes som en variabel, bliver dette problem markeret. Da det på designtidspunktet ikke vides med sikkerhed, om alle variabler er aktive ved programkørslen, kan det til tider være nyttigt at undertrykke disse for at reducere falske positiver.
Medlemmet findes ikke#{bean property}Hvis property ikke kan fortolkes som en egenskab til bean, bliver dette problem markeret. Hvis f.eks. bean er en klasse uden metoder getProperty/setProperty. Selv om det er meget mindre sandsynligt, at denne validering vil medføre falske positiver, kan det være nyttigt at ignorere, hvis du bruger mange forskellige kilder til variabler som f.eks. koder.
Egenskab er midlertidig#{property.name}Problemet opstår, fordi EL tillader tegnet '.' i nøglenavne (som i bean['x.y'], men også tillader, at det anvendes som en medlemsoperator (som i bean.property). Dette kan medføre forvirring hos brugeren især i tilfælde (som i dette eksempel), hvor property repræsenterer en tilknytning til et ressourcebundt (dvs. en egenskabsfil). Antag som i dette eksempel, at der er en nøgle til name.foo. Sætningen property.name kan derfor se meningsfuld ud, selv om den ikke har nogen nøgle i bundtet og medfører enten en NULL-værdi eller en runtime-fejl.
Problemer med typeændring til tal ved binær operation#{5 * true}Visse binære operatorer (f.eks. '+', '-', '*', '/' og mod, der anvender to operander som i x + y) forventer, at begge operander kan ændres til tal, før funktionen anvendes på dem. I dette eksempel er true en boolesk konstant, som ikke har en gyldig ændring til en numerisk værdi (selv om nogle implementeringer gennemtvinger en C-lignende ændring). Sådanne talændringsfejl medfører normalt runtime-fejl. Bemærk, at variabler (dvs.bean.booleanProperty) også har de samme problemer med talændring). Det er ikke begrænset til konstanter.
Problemer med typeændring til Boolean ved binær operation#{myBean.integerProperty && true}Visse binære operatorer (like &&, ||) forventer, at begge operander kan ændres til booleske værdier, før funktionen anvendes på dem. I dette eksempel er myBean.integerProperty en bean-egenskab af typen heltal (Integer). EL tillader ændring fra numeriske typer til boleske (selv om visse implementeringer kan gennemtvinge en C-lignende typeændring).
Typeændring ikke tilgængelig ved binær operation#{myBean.stringArrayProperty >= myBean.booleanProperty}Når en binær operator som >= tildeles operander, og der ikke meningsfuldt kan ændres type på disse, vises dette problem. I dette eksempel er hverken stringArrayProperty eller booleanProperty en gyldig værdisammenligning, når operatoren ">=" anvendes.
Binær typeændring af konstant til tal#{'a' + 'b'}EL tillader nogle gange, at strengværdier kan ændres til tal. F.eks. er #{'5' + '6'} gyldigt, da både '5' og '6' kan konverteres til tal med Long.valueOf(). Lignende typeændringer er dog ugyldige, hvis sådanne konverteringer ikke kan foretages. På designtidspunktet kan man kun være sikker på sådanne ugyldige typekonverteringer, hvis en modsat værdi er en konstant (hvis det er en variabel, vides det normalt ikke, før tidspunktet for programkørsel). I dette eksempel er det sikkert, at hverken 'a' eller 'b' kan konverteres til en numerisk type, der forventes af operatoren +.
Problemer med typeændring til tal ved unær operation#{-myBean.mapProperty}Den unære minusoperator forventer, at dens operand kan ændres til en numerisk type, før funktionen anvendes. I dette eksempel er myBean.mapProperty af typen java.util.Map, som ikke gyldigt kan ændres til et tal.
Problemer med typeændring til Boolean ved unær operation#{!myBean.mapProperty}Den unære NOT-operator forventer, at dens operand kan ændres til typen Boolean, før funktionen anvendes. I dette eksempel er myBean.mapProperty af typen java.util.Map, som ikke gyldigt kan ændres til Boolean.
Typeændring til streng ved unær operation kan ikke garanteres#{-myBean.stringProperty} Strenge, der ændres til et tal som forventet med unær minus, garanteres ikke - det afhænger af strengens værdi. Dette problem markerer sådanne mulige problemer.
Begge operander er NULL#{null + null} Når begge operander er NULL, er resultatværdien konstant og kan manuelt foldes (erstattes af konstanten) for at reducere kode.
Binært udtryk evalueres altid til den samme værdi#{x + 5 * 4} Nå begge argumenter i et binært udtryk er konstanter, kan funktionen foldes på designtidspunktet. For eksempel kan dette udtryk forenkles til #{x+20}.
Sammenligning med NULL vha. Lig med evalueres altid til den samme værdi#{myBean.integerProperty == null} EL-lighed og relationelle sammenligninger ('==', '!=', '>=' etc.) med NULL resulterer altid i den samme værdi. Generelt medfører ulighed true, lighed og alle relationelle operatorer medfører false.
Enumerationssammenligning evalueres altid til den samme værdi#{myBean.coins == 'notAValue'} Da de mulige værdier af en enumeration (Java 5 og senere) kendes på tidspunktet for kompileringen, kan vi anvende sammenligninger, som vi ved, altid medfører den samme værdi. I dette eksempel er notAValue ikke et medlem af enumerationen Coins, så vi ved, at ligheden aldrig kan være true.
Unært udtryk evalueres altid til den samme værdi#{empty 'notEmpty'} De unære operatorer har operander, som på designtidspunktet kan registrere, at de altid evalueres til den samme værdi. I dette eksempel medfører operatoren empty altid i false, hvis den anvendes på en ikke-NULL, ikke-empty streng.
Tom operator fortolkes altid som false for type#{empty myBean.integerProperty} Operatoren empty evalueres altid til false, medmindre dens operand er en NULL-værdi, en tom streng, eller en array-, Map- eller Collection-type.
Minus anvendt på NULL evalueres altid til nul#{-null} NULL ændres til 0, når minusoperatoren anvendes.
Første argument kortslutter udtrykket.#{false && someFunc()} EL-betingede operatorer "kortslutter", hvilket betyder, at hvis den første operand angiver nok oplysninger til, at resultatet er sikkert, bliver den anden operand ikke evalueret. I dette eksempel bliver someFunc() aldrig kaldt, da det logiske AND til 'false' er false med alle værdier. Da dette registreres på designtidspunktet, angiver det formodentlig et unødvendigt udtryk, eller et udtryk der kan foldes manuelt.
Andet argument evalueres altid på samme måde#{myBean.booleanProperty && false} Dette ligner ovenstående problem med undtagelse af, at udtrykket ikke er kortsluttet. I dette eksempel er udtrykket altid false.
Anvendelse af dot-operatoren ('.') sammen med NULL returnerer altid NULL #{map[null]} Brug af NULL som medlems-accessor medfører altid NULL.
Muligvis division med nul#{x mod 0} Division og modulo med 0 kan medføre en runtime-fejl.
Indeks kan være uden for grænser#{myBean.stringArrayProperty[-1]} Array-indekser skal være større end eller lig med 0 og mindre end størrelsen på arrayet eller samlingen (det samme som Java). På designtidspunktet bestemmes, om disse betingelser er beskadigede. Der vises en advarsel.
Inkompatibel enumerationssammenligning#{myBean.coins >= myBean.colors} Sammenligning af to enumerationsværdier, som ikke har samme enumerationstype (Java 5 og senere), kan medføre en runtime-undtagelse.
Metodeudtryk forventet<h:commandButton action="#{bean.property}"/> Hvis EL-validatoren indeholder oplysninger om, at en kodeattribut forventer et metodeudtryk (metodebinding før JSF 1.2), markerer den fejl, hvis EL-udtrykket evalueres til et værdiudtryk. I eksemplet er bean.property et værdiudtryk, der evalueres til en Bean-egenskab på bean.
Inkompatibilitet i værdiudtrykstype<h:inputText rendered="#{bean.foo}/> Hvis EL-validatoren indeholder oplysninger om, at en kodeattribut forventer en bestemt værditype, markeres, at der er et problem, hvis udtrykket ikke kan ændres til den pågældende type. I dette eksempel er bean.foo en bean-egenskab af typen "beans Foo". Vilkårlige klassetyper kan generelt ikke ændres til Boolean (gengivne skal være Boolean).
Værdiudtryk forventet<h:inputText value="#{bean.action}/> Hvis en kodeattribut normalt forventer en værdi, markeres der et problem, hvis et metodeudtryk angives i stedet for. I dette eksempel forventer værdiattributten et værdiudtryk, men der angives et metodeudtryk i stedet Bemærk, at det ikke er muligt at bestemme, om det er et metodeudtryk alene ved at se på det. actionbean skal fortolkes for at være sikker.
Inkompatibilitet i metodeudtrykssignatur<h:commandButton action="#{bean.actionTakesArg}" Hvis den forventede signatur til et metodeudtryk kendes, sammenligner validatoren den med det angivne udtryk og markerer, at der er et problem, hvis det ikke passer. I dette tilfælde forventer attributten action en metode, der ikke kan anvende argumenter, men der leveres en med argumenter.
Egenskaben forventes at være læselig, men der er ingen "getter"<h:outputText value="#{bean.writeOnlyProperty}/> Hvis en kodeattribut normalt kræver en læsbar egenskab, og der er angivet en ulæselig, markerer validatoren, at der er opstået et problem.
Egenskaben forventes at kunne skrives, men der er ingen "setter"<h:inputText value="#{bean.readOnlyProperty}/>Hvis en kodeattribut normalt kræver en skrivbar egenskab, og der er angivet en læsbar, markerer validatoren, at der er opstået et problem.

Relaterede opgaver

Validér JSF-programmer