JSF, standaard werkwijze?

[Verwijderd]

Hallo dames en heren,

ik ben momenteel bezig met het ontwikkelen van een webapplicatie. De bedoeling is om de GUI met JSF te ontwikkelen, in combinatie met IceFaces.

Mijn vraag gaat over het deel van de backing-beans en de actions. Hoe kan dit het beste worden opgezet? Is hier een standaard werkwijze voor? Ik heb voorheen wel met struts gewerkt, waarbij je gedwongen wordt om de paginagegevens in een bean (Form) te stoppen, en waarbij navigatie tussen pagina's, en het vullen van de beans, afgehandeld wordt door een instantie van een Action klasse.

Ik heb een aantal tutorials bekeken over JSF, en hierin werden de beans voor zowel form als action functionaliteit gebruikt. Een bean bevat dus zowel data attributen (en getters en setters) als actiemethoden. Volgens mij wordt het al snel onoverzichtelijk als je alles zo door elkaar heen gaat gooien? (Tenzij je een bean per pagina gebruikt?) In onze applicatie is het echter zo dat er op vrijwel alle schermen informatie wordt getoond over hetzelfde object. (alleen in andere toestanden).Bovendien is het ook niet mogelijk om meerdere pagina's tegelijk open te hebben. Volgens mij zou het in dat geval handiger zijn om voor dat object gewoon 1 bean te definieren, die door verschillende pagina'a kan worden gebruikt, ipv 1 bean voor elke pagina (allemaal beans die op elkaar lijken dus...)

Om de vraag (vragen) concreet te maken;
Hoe worden dit soort zaken standaard in JSF opgepakt? Zien hier standaard werkwijzen voor? Is het handiger om 1 bean per pagina te gebruiken? En zo ja, waarom?
Is het handig om acties in een aparte klasse te definieren, of worden ze gewoonlijk gewoon bij de databean ingestopt?

[Janoz]

Je voorbeeld van die bean die op meerdere pagina's terug komt zou ik inderdaad als typisch voorbeeld van een bean met een session scope zien.

Wat wij hier verder doen is werken met wat wij noemen 'handlers'. Een handler is een requestscope bean waarin de functionaliteit wordt geimplementeerd die je bij struts normaal in een actie zou doen. Het verschil is dat een handler meer functionaliteit bevat. Bij struts bevat de action de functionaliteit die bij 1 request hoort terwijl bij een handler je door de bank genomen de functionaliteit per entiteit of per usecase kunnen hebben.

Voordeel ten opzichte van struts is dat je handler voor meerdere requests gebruikt kan worden, maar dat er per pagina ook meerdere handlers aangeroepen kunnen worden (Op zich kun je natuurlijk met struts vanuit een pagina ook meerdere acties aanroepen, maar bij jsf kun je in de huidige pagina al functionaliteit gebruiken zeg maar).

Ik geef wel toe dat het verhaal nogal onsamenhangend kan klinken. Ikzelf ben ook een tijdje bezig geweest om mijzelf wat los te weken van de oude struts werkwijze om me vervolgens het hele jsf gebeuren eigen te maken. Als ik nog ergens tijd vind dan zal ik eens even kijken of ik een simpel voorbeeldje samen kan stellen om bovenstaand verhaaltje een beetje te kunnen ondersteunen.

Handlers zijn in principe stateless. De state zul je weer moeten opslaan in eerder genoemde sessionscope beans (of application scope beans).

[Verwijderd]

Oke, bedankt voor je toelichting! Ik hou het eerst maar als volgt aan: Voor sommige schermen zijn specifieke beans vereist. Ook voor menu's, die verschillende items kunnen bevatten, maak ik beans. Voor de overige schermen, die eigenlijk dezelfde informatie tonen, maak ik een abstracte klasse, die wordt geextend per pagina. Voordeel hiervan is dat ik eventueel extra properties kan toevoegen, mocht dit later nodig blijken. Nadeel is dat ik met een zooi beans zit...

Voor de acties maak ik een (of meerdere) aparte actieklasse bean.