AjaxLink bug cross origin css, javascript file download file upload home page HttpServletRequest image, favicon mount MyApplication MyApplication.init() MySession page store page parameters validátor wicket verzió

• AjaxLink esetén máshogy kell az ajax hívást megelőző confirm üzenetet beállítani!
  Például ajax hívás előtt egy saját javascript fut, és annak false-sal való visszatérésekor az ajax művelet nem hajtódik végre:

• DateTextField bug (lásd 1.4)

• Rest service készítése esetén a cross origin miatt szükséges, hogy a program visszaadjon egy header bejegyzést: Azonban ezt hiába állítjuk be a http GET kérésre, az OPTIONS típusú kéréskor ez a header hiányzik, mert a wicket az OPTIONS kérésre nem teszi be a header-be, és programból se tudjuk ezt kezelni a GET kéréskor. Akár angular, akár jquery ajax hívás történik a service felé, az előszőr mindig OPTIONS kérést küld.
  
  Megoldás: készíteni kell egy sima szervlet filtert, ami beállítja a header-t minden típusú http kérésre:
  A web.xml-be írjuk be a WicketFilter elé például: A web.xml-ben megnevezett WsFilter osztálynak implementálni kell a javax.servlet.Filter osztályt. Az osztály doFilter() metódusa:

• Css és javascript fájlok weblapokba való beszúrásához kíváló a render-head módszer.
  Ennek lényege, hogy a beszúrandó css és javascript elemeket mindig a WebPage renderHead() metódusaiban állítsuk be.
  Így szabályozható az elemek sorrendje még markup inheritance esetén is. A html lapokon nem kell hivatkozni a css/js-re.
• renderHead() metódus felülírásának általános alakja: A metódusban leírt sorrend megmarad a végső html-ben is!
  A HeaderItem-ek megadása többféle módon lehetséges, lásd alább:
• HeaderItem az alkalmazásban lévő osztályhoz viszonyítva.
  A wicket csak ebben az esetben látja el verziószámmal a css/js-t, a forUrl(), forCSS(), forScript() metódusok esetén nem.
• HeaderItem URL-lel megadva, külső címről:
• HeaderItem URL-lel megadva, az alkalmazásban lévő css/js-re hivatkozva. Ebben az esetben az alkalmazás web pages részébe kell helyezni a css/js fájlt.
  Az URL-ből kihagyható a context path, de jobb beleírni. Az URL nem változik, a végső html-ben is így fog szerepelni a link-href / script-src részben.
• HeaderItem konkrét css/js string megadásával:

• Fájl letöltése egy tetszőleges osztályból:

• Markup: egy vagy több fájl feltöltő mező, melynek ugyanaz a wicket:id -je!
• Java:
• Fontos hogy a model listán végighaladva, ezzel ellenőrizzük hogy volt-e feltöltött fájl: ugyanis a fenti példában mivel 3 fájl feltöltő mező van a képernyőn, ez mindig 3 lesz:

• Home page lekérdezése WebPage osztályon belül:
• Home page lekérdezése tetszőleges helyen:

• HttpServletRequest elérése tetszőleges helyről:

• image:
  Markup: Java:
• favicon:
  Markup: Java:

• Mintapélda: Elso.class hívódik meg ilyen url-ek esetén: Masodik.class hívódik meg ilyen url-ek esetén: A mount nem érvényesül ezekben az esetekben:

• Configuration type beállítása:

• A WebApplication leszármazott MyApplication osztály init() metódusában több beállítás is szükséges!
• Weblapok automatikus létrehozásának letiltása:
  A default true esetén, amikor egy weblap elévül, akkor nem keletkezik PageExpiredException, hanem a lap újra létrejön, méghozzá úgy, hogy paraméter nélkül meghívódik a konstruktora. Ez a default működés nem kívánatos.
• Ajax debug ablak letiltása:
• jQuery egységesítés: Ezzel megadható az a jquery, amit a wicket használni fog a saját eljárásaihoz.
  Így egységesíthetjük a jquery-t, vagyis ugyanazt a jquery-t használhatja a wicket, és a saját javascriptünk is, és a html oldalon sem lesz duplán betöltve!
• Expired és error page beállítása: A MyExpired oldalon tájékoztassuk a felhasználót, és írjuk ki a session timeout időt:
  A művelet végrehajtása sikertelen, mivel a weboldal érvényessége lejárt!
  Ennek egyik lehetséges oka, hogy lejárt a bejelentkezése (több mint ... percig nem használta a rendszert).
  majd egy "Tovább" gombbal lehessen továbblépni a homepage-re: A MyExpired működésének teszteléséhez nem szükséges a session timeout időt rövidre állítani, elég az url-ben lévő page verziót nemlétezőre állítani.
  
  Így is be lehetne állítani az expired és error page-et, de ezzel az a baj, hogy a MyError-nak nem lehet átadni az exception objektumot.
  A módszert a wicket fórumon sem ajánlották:

• Konstruktor. A bind()-del állítsuk be hogy a session ne legyen temporális!
• get() metódus. Így tetszőleges helyről hozzáférhető a session egy MySession.get() hívással.

• A weblapok stateful illetve stateless állapotúak lehetnek.
  A stateful lapokat a page store tárolja melynek 3 szintje van.
  A page store a MyApplication.init() metódusban lekérdezhető, illetve beállítható.
• 1. level store (session scoped cache)
  Memóriában lévő tár, ez a leggyorsabb, de ebben mindig csak 1 weblap van, a legutolsó request-hez tartozó lap. Nem állítható.
• 2. level store (application scoped cache)
  Memóriában lévő tár, kicsit lassabb mint a 1. level store. Ebben a weblapok darabszáma kérdezhető le, illetve állítható be:
• 3. level store (persistent store disk)
  Fájlrendszer tár. Ebben beállítható hogy maximum mekkora legyen a fájl melyben a weblapok tárolódnak. Ha a fájl mérete elérte a maximumot akkor a fájl elejéről kezdi ismét a terület felhasználását. Figyelem: 0 beállításánál a fájl mérete nincs korlátozva ! Ezenkívül lekérdezhető és beállítható hogy a 3. level store hol legyen:

• A kapott PageParameters elemei különbőző adattípusként olvasható be.
  A táblázatban például long-típusként szeretnénk az "a" paraméterhez hozzáférni:

  Metódus parameters.get("a")	"a" nincs megadva a= a=&a=7	a=bb	a=7 a=7&a=8&a=
  .toLong()	NumberFormatException	NumberFormatException	7 (primitív long)
  .toLongObject()	NumberFormatException	NumberFormatException	7 (Long)
  .toLong(default)	default	default	7 (primitív long)
  .toOptionalLong()	null	NumberFormatException	7 (Long)

  A táblázatból látszik hogy ha több paraméter jön, akkor a beolvasó metódus mindig az első paramétert olvassa be, a többi figyelmen kívül marad!
• Kivételt képeznek a String-ként beolvasó metódusok.
  Egyformán működnek, sosem keletkezik exception, null-t adnak vissza ha nincs a paraméter megadva:
• Ha több paraméter jön ugyanazzal a névvel, például a=7&a=8 akkor így lehet beolvasni az összes értéket:
• Indexelt paraméterek:
  Ezeket a paramétereket az URL-ben elfoglalt pozíciójuk alapján lehet elérni.
  Például ha az mnt névre van mount-olva egy oldal akkor: url esetén 2 indexelt paraméter van: ezek lekérdezése:
• Az indexelt paraméterek kombinálhatók a nevesített paraméterrekkel, mindegyik paraméter lekérdezhető:
• A hívó oldalon nevesített paraméter készíthető a PageParameters add() illetve set() metódusával.
  Indexelt paraméter a PageParameters set() metódusával készíthető.
• Indexelt paraméterben ne használjunk semmi speciálisat, a+b esetén a "+" jel nem szóközként értelmeződik mint a nevesített paraméterben, a %2F sem működik!

• A saját validátor osztálynak az IValidator interface-t kell implementálni, és felülírni a validate() metódust.
  Ebben lehet hivatkozni a MyApplication.properties -ben lévő kulcsra, és beállíthatók a kulcshoz tartozó szövegben lévő $-változók is.
  Például egy MyApplication.properties bejegyzés: Saját validátor validate() metódusa:

• Wicket keretrendszer verziószámának lekérdezése: