[JSF]Clientside een converterException detecteren

[SilentStorm]

In mijn jsf 1.1 applicatie zit een zoekpagina. Bovenaan staan een aantal criteria velden, met daaronder een zoekknop. Als er gezocht wordt, verschijnen de resultaten in een tabel eronder.

Voor een aantal zoekvelden bestaan converters, om ze meteen om te zetten naar identificatienummers, date's, etc.

Als bij een tweede zoekopdracht, 1 van de gegevens ongeldig is, volgt een exceptie (jvalidate) bij de instantiatie van het corresponderende object. Deze exceptie wordt in de converter afgevangen en gewrapped in een ConverterException. So far, so good

Aan de client kant, wil ik in dat geval echter nog wel de vorige zoekresultaten weghalen, om verwarring te voorkomen. Dit zou moeten door ergens de lijst met resultaten leeg te maken, of ergens een variabele op te halen, waaruit blijkt dat er een converterException is geweest en in dat geval de tabel te hiden.

Hoe doe ik dat op een nette manier?
(Door de exceptie word de lifecycle phase, waarin de action of actionListener op mijn zoekknop zit, overgeslagen.)

Mijn beste poging tot nu toe is om in mijn converter, voor het throwen van de exceptie, een variabele toe te voegen aan de requestMap en deze clientside weer uit te lezen. Dat werkt, maar ik wil dat eigenlijk niet voor alle converters doen (2x per stuk zelfs, getAsObject en getAsString). Bovendien twijfel ik of zoiets niet al in jsf zelf zit, of dat er al een andere manier bestaat om dit gegeven te benaderen.


Ik wil mensen niet ontmoedigen met een enorm lange startpost, dus ik zal het verhaal over mijn eigen ideeen en pogingen kort houden:

• met ajax: de lijst met resultaten staat in request scope. Als ik de lijst clear voor de POST op de knop, verwijder ik de verkeerde versie van de lijst. Met een ver-ajax-de zoekknop, komt nog steeds de vorige lijst terug (ik verwacht een vorm van caching). apply_request_values wordt niet uitgevoerd.

• door geen exceptie te gooien, maar enkel een facesmessage toe te voegen: werkt, maar ik kom later in de problemen, omdat ik niet kan zien of de gebruiker daadwerkelijk niets heeft ingevoerd (-> nog een foutmelding, die ik niet wil), of dat er iets mis ging.

• lelijke oplossingen:
- de waarde van het criteriumveld vervangen door 'INVALID'
- een 'listToClear' veld toevoegen aan de converters
- een phaseListener maken die de variabele voor mij zet (deze wordt aangeroepen op elke pagina. De extra load zal vast meevallen, maar pagina-specifieke code in een phaselistener vind ik ook niet kloppen.. daarnaast weet ik niet zeker of de koppeling tussen de facesmessage en de converter daar nog terug te vinden is.
- in javascript de facesmessage uitlezen en adhv de waarde van het tekstveld de tabel hiden
- een property toevoegen aan elk datatype dat in een zoekveld voor kan komen 'isValid' ofzo, evt inclusief interface.
- een boel onchange listeners maken, die de waarde valideren bij het verlaten van het invoerveld

[ Voor 0% gewijzigd door SilentStorm op 15-09-2011 18:36 . Reden: typo ]

[Erik Jan]

Ik vind JSF (1) een vreselijk systeem, o.a. door zulke beperkingen. Ik heb in het verleden ook wel eens dergelijke hacks overwogen, en allemaal waren ze waardeloos. Volgens mij vereist de enige nette oplossing aanpassing van de workflow:
• Na een zoekactie alle invoervelden "disabled" (grijs) maken.
• "Zoek" knop veranderen in "wijzig zoekopdracht" of zoiets.
• Deze knop verwijderd alle resultaten en maakt de invoervelden weer toegankelijk (met oude waarden er nog in).

[SilentStorm]

Thanks voor de reactie
Ik heb het idee dat een hoop beperkingen in JSF te maken hebben met het feit dat het 'usermodel' en het model dat de developers van JSF voor ogen hebben, niet helemaal overeen komen. Soms moet je net even weten hoe 'ze het bedacht hebben'. Dit maakt dat sommige, ogenschijnlijk triviale zaken als deze, veel moeilijker zijn (lijken?) dan ze zouden moeten zijn.
Tot nu toe heb ik nog steeds de overtuiging dat er een meer praktische oplossing voor mijn probleem bestaat, maar dat ik er 'verkeerd' tegenaan kijk. Ik hoop eigenlijk op een reactie als 'Oh! maar dat is toch simpel?' Iets in de richting van 'maak een getter die die [een of andere property] uit de facescontext haalt, en je weet het'.

Over je oplossing: Hij lost het probleem wel op, maar zo'n grote aanpassing voor zo'n kleine verandering.. Ik zou toch liever een van de vieze hacks hierboven hanteren, dan de functionele werking van de pagina te beinvloeden/compliceren, voor een reden als dit.