A legtöbb EL érvényesítési problémához személyre lehet szabni a súlyossági szintet, ami lehet hiba, figyelmeztetés vagy nincs. A nincs súlyossági szint beállításával tulajdonképpen figyelmen kívül lehet hagyni a hibákat jelentéskészítés esetén.
Az alábbi táblázat megjeleníti a személyre szabható problémákat és leírja a beállítások hatását:
Leírás | Példa | Magyarázat |
---|---|---|
Általános szintaktikai hiba | #{* x} | A szintaktikai hibák az EL nyelv általános megsértései. A példában a '*' szorzási operátor két operandust vár, de csak egy (x) van megadva. |
Üres EL kifejezés | #{} | Jelzi, hogy nem lett megadva kifejezés. |
Hiányzó záró zárójel a kifejezésben | #{x + 5 | Jelzi, hogy a záró '}' zárójelet hozzá kell adni. Például: "#{x + 5}" |
Operátor alkalmazása metóduskötésre. | #{bean.action * 5} | Ha a bean.action egy bean komponensen végrehajtandó "action()" metódust jelent, akkor az EL nem kezelheti ennek eredményét értékként. A példában az 5-tel szorzási művelet értékként próbálja kezelni azt. |
Pontokat tartalmazó tulajdonságneveknek a tömb ([]) szintaxist kellene használni. | #{property.name.foo} | Ha a name.foo egy érték kulcsa a property tulajdonságköteg indexében, akkor az EL specifikáció ajánlja (bár nem teszi kötelezővé), hogy ezt inkább property['name.foo'] formában fejezze ki annak hangsúlyozására, hogy a name.foo egy leképezésben szereplő kulcs, nem pedig mondjuk egy bean komponens tulajdonsága. |
Változó nem található | #{bean property} | Ha a bean nem oldható fel változóként, akkor ez a probléma jelenik meg. Mivel tervezési időben nem lehet 100% pontossággal ismerni a változókat, amelyek futási időben aktívak lehetnek, ezt hasznos lehet esetenként kikapcsolni a hamis pozitív hibaüzenetek számának csökkentése érdekében. |
Tag nem található | #{bean property} | Ha a property nem oldható fel egy bean tulajdonságaként, akkor ez a probléma jelenik meg. Például ha a bean egy getProperty/setProperty metódusok nélküli osztály. Bár ez az érvényesítés kisebb valószínűséggel ad hamis pozitív eredményt, ha sok különböző lehetséges forrásból származó változót használ (például címkék), akkor hasznos lehet a figyelmen kívül hagyása. |
Köztes tulajdonság | #{property.name} | A probléma azért merülhet fel, mert az EL engedélyezi a '.' karaktert a kulcsnevekben (mint például a bean['x.y'] kifejezésben), de engedélyezi azt is, hogy tag operátorként szerepeljen (mint például a bean.property kifejezésben). Ez zavaró lehet a felhasználó számára, különösen a példához hasonló esetekben, ahol a property egy erőforrásköteg (például tulajdonságfájl) által támogatott leképezést ábrázol. Tegyük fel, hogy a példa esetében van egy name.foo kulcs. A property.name utasítás értelmesnek tűnhet, még ha nincs is kulcsa a kötegben, és null értéket vagy futási kivételt eredményez. |
Kétváltozós művelet szám kényszerítési problémái | #{5 * true} | Néhány kétváltozós operátor (mint például a '+', '-', '*', '/' és a mod, amelyek két operandust igényelnek, mint az x + y kifejezésben), elvárják, hogy mindkét operandus számra legyen kényszeríthető, mielőtt alkalmaznák a műveletet. A példában a true egy logikai karaktersorozat, amelynek nincs legális kényszerítése egy numerikus értékre (bár néhány megvalósítás elvégez egy C stílusú kényszerítést). Az ilyen kényszerítési hibák általában futási kivételt okoznak. Vegye figyelembe, hogy a változóknak (például a bean.booleanProperty) ugyancsak megvannak a hasonló kényszerítési problémáik; ez nem csak a literálokra korlátozódik. |
Kétváltozós művelet logikai kényszerítési problémái | #{myBean.integerProperty && true} | Néhány kétváltozós operátor (mint a &&, ||) elvárja, hogy mindkét operandus kényszeríthető legyen logikai értékekre, mielőtt alkalmaznák a műveletet. A példa esetén a myBean.integerProperty egy Integer típusú bean tulajdonság. Az EL nem engedélyezi a kényszerítést numerikus típusokból logikaira (bár néhány megvalósítás elvégez egy C stílusú kényszerítést). |
Kétváltozós művelethez nincs elérhető kényszerítés | #{myBean.stringArrayProperty >= myBean.booleanProperty} | Amikor egy kétváltozós operátor, mint a >= olyan operandusokat kap, amelyek közül egyik sem kényszeríthető értelmesen úgy, hogy az operandusok típusa származzon belőle, akkor ez a probléma jelenik meg. A példában sem a stringArrayProperty, sem pedig a booleanProperty nem ">=" operátor használatával összehasonlító érvényes érték. |
Literálból szám kétváltozós kényszerítés | #{'a' + 'b'} | Az EL néha megengedi karaktersorozat értékek kényszerítését számokra. Például a #{'5' + '6'} egy legális kifejezés, mert az '5' és a '6' egyaránt átalakítható számokra a Long.valueOf() függvény segítségével. Viszont az ehhez hasonló kényszerítések illegálisak, ha ilyen átalakítás nem végezhető. Tervezési időben az ilyen érvényes átalakításokban csak akkor lehetünk biztosak, ha a szóban forgó érték egy literál (ha változó, akkor általában csak futási időben lesz ismert). A példában biztosan meg tudjuk mondani, hogy sem az 'a', sem a 'b' nem alakítható át a + operátor által várt numerikus típussá. |
Egyváltozós művelet szám kényszerítési probléma | #{-myBean.mapProperty} | Az egyváltozós mínusz operátor elvárja, hogy az operandusa kényszeríthető legyen egy numerikus típusra a művelet alkalmazása előtt. A példában a myBean.mapProperty java.util.Map típusú, amelynek nincs érvényes kényszerítése számra. |
Egyváltozós művelet logikai kényszerítési probléma | #{!myBean.mapProperty} | Az egyváltozós not operátor elvárja, hogy az operandusa kényszeríthető legyen egy logikai típusra a művelet alkalmazása előtt. A példában a myBean.mapProperty java.util.Map típusú, amelynek nincs érvényes kényszerítése logikai értékre. |
Egyváltozós művelet String kényszerítése nem garantált | #{-myBean.stringProperty} | A karaktersorozatok kényszerítése számra, amint azt az egyváltozós mínusz operátor várná, nem garantálható a karaktersorozat értékének függvényében. Ez a probléma egy ilyen lehetséges hibát jelez. |
Mindkét operandus null | #{null + null} | Amikor mindkét operandus nullérték, az eredményül kapott érték egy konstans, és kézzel elrejthető (lecserélhető egy literál konstansra) a kód mennyiségének csökkentése érdekében. |
Kétváltozós kifejezés mindig ugyanarra az értékre értékelődik ki | #{x + 5 * 4} | Amikor egy kétváltozós kifejezés mindkét argumentuma egy literál, a műveletet el lehet rejteni tervezési időben. Például ez a kifejezés leegyszerűsíthető a #{x+20} kifejezésre. |
Egyenlőség összehasonlítás nullértékkel mindig ugyanarra az értékre értékelődik ki | #{myBean.integerProperty == null} | Az EL egyenlőségi és relációs összehasonlítások ('==', '!=', '>=' stb.) nullértékkel mindig ugyanazt az értéket eredményezik. Általánosságban az egyenlőtlenség igaz értéket eredményez, az egyenlőség és a többi relációs operátor hamisat. |
Felsorolási összehasonlítás mindig ugyanarra az értékre értékelődik ki | #{myBean.coins == 'notAValue'} | Mivel egy felsorolás (Java 5 és újabb) lehetséges értékei ismertek fordítási időben, elvethetjük azokat az összehasonlításokat, amelyekről tudjuk, hogy mindig ugyanazt az értéket fogják eredményezni. A példában a notAValue nem a Coins felsorolás tagja, tehát tudjuk, hogy az egyenlőség sosem lesz igaz. |
Egyváltozós kifejezés mindig ugyanarra az értékre értékelődik ki | #{empty 'notEmpty'} | Az egyváltozós operátoroknak olyan operandusaik vannak, amelyekről tervezési időben észre lehet venni, hogy mindig ugyanarra az értékre értékelődnek ki. A példában az empty operátor mindig hamis értéket eredményez, ha egy nem null, nem üres karaktersorozatra van alkalmazva. |
Az empty operátor a típushoz mindig hamis értékre van feloldva | #{empty myBean.integerProperty} | Az empty operátor mindig hamis értéket eredményez, ha az operandusa nem nullérték, üres karaktersorozat vagy egy tömb, Map vagy Collection típus. |
A null értékre alkalmazott mínusz mindig nullára értékelődik ki | #{-null} | A null eredményes kényszerítése a 0 számra mínusz operátor alkalmazása esetén. |
Az első argumentum rövidre zárja a kifejezést | #{false && someFunc()} | Az EL feltételes operátorok "rövidre vannak zárva", ami azt jelenti, hogy ha az első operandus elegendő információt tartalmaz az egyértelmű eredményhez, ezután a második operandus nincs kiértékelve. A példában a someFunc() függvény hívására sosem kerül sor, mivel a 'false' (hamis) logikai AND kapcsolata bármely értékkel ugyancsak hamis lesz. Mivel ez már tervezési időben észlelhető, ez valószínűleg egy haszontalan vagy kézzel elrejthető kifejezést jelöl. |
A második argumentum mindig ugyanarra az értékre értékelődik ki | #{myBean.booleanProperty && false} | Ez hasonló a fenti problémához, csak a kifejezés nincs rövidre zárva. A példában a kifejezés mindig hamis értéket eredményez. |
A pont ('.') operátor nullal történő használatkor mindig nullt ad vissza | #{map[null]} | A null használata tag hozzáférőként mindig nullt eredményez. |
Lehetséges nullával történő osztás | #{x mod 0} | Az osztás és a modulo operátor használata 0 értékkel futási kivételt okozhat. |
Lehetséges határon kívüli index | #{myBean.stringArrayProperty[-1]} | A tömb indexek csak 0-nál nagyobb vagy egyenlő értékek lehetnek, és kisebbnek kell lenniük, mint a tömb vagy gyűjtemény mérete (ugyanúgy, mint a Java nyelvben). Amikor tervezési időben el lehet dönteni, hogy ez a megszorítás sérülhet, akkor a felhasználó figyelmeztetést kap. |
Inkompatibilis felsorolási összehasonlítás | #{myBean.coins >= myBean.colors} | Két felsorolási érték összehasonlítása, amelyek nem azonos felsorolási típushoz tartoznak (Java 5 és később változatok) kivételt okozhat futási időben. |
Metódus kifejezés szükséges | <h:commandButton action="#{bean.property}"/> | Ha egy EL érvényesítőnek olyan információi vannak, hogy egy címke attribútum egy metódus kifejezést vár (metóduskötés JSF 1.2 előtt), akkor hibát fog jelezni, ha az EL kifejezés egy érték kifejezésre értékelődik ki. A példában a bean.property egy érték kifejezés, amely a bean egy bean tulajdonságára oldható fel. |
Érték kifejezés típus inkompatibilitás | <h:inputText rendered="#{bean.foo}/> | Ha egy EL érvényesítőnek olyan információi vannak, hogy egy címke attribútum egy adott értéktípust vár, akkor problémát fog jelezni, ha a kifejezés nem kényszeríthető arra a típusra. A példában a bean.foo a bean Foo típus bean tulajdonsága. Tetszőleges osztálytípusok általában nem kényszeríthetők logikai értékekre (lefordítva logikai típusnak kell lennie). |
Érték kifejezés szükséges | <h:inputText value="#{bean.action}/> | Ha egy címke attribútumról ismert, hogy egy értéket vár, akkor probléma jelenik meg, ha ehelyett egy metódus kifejezés van megadva. A példában a value attribútum egy érték kifejezést vár, de ehelyett egy metódus kifejezés van megadva. Figyelje meg, hogy ránézésre nem lehet eldönteni, hogy ez egy metódus kifejezés. Ki kell értékelni az action műveletet a bean elemen, hogy biztosak legyünk benne. |
Metódus kifejezés szignatúra inkompatibilitás | <h:commandButton action="#{bean.actionTakesArg}" | Ha egy metódus kifejezés várt szignatúrája ismert, akkor az érvényesítő össze fogja azt hasonlítani a megadott kifejezéssel, és ha nem egyezik, akkor problémát jelez. Ebben az esetben az action attribútum egy argumentumok nélküli metódust vár, de egy olyan metódus lett megadva, amelynek vannak argumentumai. |
A tulajdonságnak olvashatónak kellene lennie, de nincs lekérdező | <h:outputText value="#{bean.writeOnlyProperty}/> | Ha egy címke attribútumról ismert, hogy egy olvasható tulajdonságot igényel, de egy nem olvasható tulajdonság van megadva, akkor az érvényesítő problémát jelez. |
A tulajdonságnak írhatónak kellene lennie, de nincs beállító | <h:inputText value="#{bean.readOnlyProperty}/> | Ha egy címke attribútumról ismert, hogy egy írható tulajdonságot igényel, de egy nem írható tulajdonság van megadva, akkor az érvényesítő problémát jelez. |