|jsf| controller?

[Verwijderd]

Ik ben al een aantal weken aan het kijken naar JSF. Ik kom van een asp.net omgeving. Volgens sun is dit geimplementeerd volgens het MVC principe: Je JSF is je view, je bean is je model maar waar in hemelsnaam is je controller?

Stel. Ik wil data tonen op het scherm.
in asp.net deed ik dat als volgt.
view: aspx file

code:

<asp:datagrid id="dgData"/>

controller: codebehind

code:

page_load(){
dgData = model.getDataTable();
dgData.dataBind();
}

model

code:

public DataTable getDataTable(){
 return blabla;
}

Nu in JSF zou dit als volgend zijn
view: jsf file

code:

<datatable value=#{bean.data}>

model: bean

code:

public List getData(){
 return blabla
}

Nu zie ik hier dus geen controller. Ik heb eraan zitten te denken om eigenlijk twee beans te gebruiken: 1 voor je model en 1 voor je controller. Trouwens gebruiken jullie voor de model beans daar rechstreeks je domain model classes voor?

Waar moet ik op letten wanneer ik overschakel van asp.net naar jsf? (ervaring met plain old java is geen probleem)

Ik weet dat er ook een manier is om in jsf je page controller te maken door voor elk UI componentje je binding te specifieren in je bean. Alle tutorials gebruiken het model en controller echter wel door elkaar! Is het aan te raden om in JSF zo te werken: dus met een binding naar je UI component in je controller bean of ...

Graag wat tips hier om trent!

[ Voor 4% gewijzigd door Verwijderd op 22-01-2005 23:14 ]

[Verwijderd]

*kick*
iemand moet er toch iets op te zeggen hebben!

[Gert]

Ik neem aan dat er iets is dat de bean in een of andere scope moet stoppen, dat zou je controller kunnen zijn.

[Alarmnummer]

Gert schreef op maandag 24 januari 2005 @ 01:25:
Ik neem aan dat er iets is dat de bean in een of andere scope moet stoppen, dat zou je controller kunnen zijn.

Ik neem aan dat je entity bean bedoelt? Als dat zo is, dan wil je daar echt geen controller van maken.

Ik heb nog niet gekeken naar JSF, dus ik kan je daar ook niet verder mee helpen. Staat wel ergens op het lijstje : "api`s ooit te bekijken" .. maar kan niet zeggen dat het echt hoog staat.

[ Voor 12% gewijzigd door Alarmnummer op 24-01-2005 08:14 ]

[Peetman]

Moet er niet gewoon nog ergens een servlet tussen?

[Verwijderd]

De Controller is ervoor om een request naar de juiste output te leiden.
Het idee is dat elke request op dezelfde file binnenkomt (je controller) en de controller aan de hand van de parameters in de url beslist welke Action de request verder moet afhandelen.

De code die jij bij je .net voorbeeld als controller laat zien, is eigenlijk geen controller.
Een controller doet namelijk niets met data, dat word door je model gedaan.

Bij .net heb je geen controller zoals dat bij JSF word gebruikt, omdat elke pagina een eigen bestand is, en niet elke pagina een Action is.

[Alarmnummer]

Verwijderd schreef op maandag 24 januari 2005 @ 12:24:
De Controller is ervoor om een request naar de juiste output te leiden.
Het idee is dat elke request op dezelfde file binnenkomt (je controller)

file?

en de controller aan de hand van de parameters in de url beslist welke Action de request verder moet afhandelen.

Dat ligt er dus maar net aan. het is niet ongebruikelijk om 1 centrale servlet-controller te hebben waar alle requests op binnenkomen. En deze servlet controller via een logical mapping te laten uitzoeken welke echte controller aangeroepen moet worden. Spring MVC werkt bv op deze manier...

[Verwijderd]

Als het goed is moet je ergens in je web.xml zo iets hebben staan:

code:

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

Die Faces Servlet is de koppeling (controller) tussen je UI (view) en je backend (model). Zie ook http://java.sun.com/j2ee/.../webapp/FacesServlet.html

[ Voor 23% gewijzigd door Verwijderd op 24-01-2005 14:12 ]

[Verwijderd]

Je kan van je Controller ook een Managed-bean maken. In die Controller kan je vervolgens bijvoorbeeld je domein model klassen terug geven. Op deze manier voorkom je in ieder geval al dat je voor elke domeinklasse een managed-bean mapping aan hoeft te maken in je faces-config.xml. Het aanmaken van iedere domeinklasse is te doen zolang je applicatie weinig van deze klassen heeft, alleen bij 20 > wordt het geheel enigszins overzichtelijk (de reden dat ik dit dus ook niet doe ).

Voorbeeld:
Boek (Domein)
- auteur
- naam
- isbn

Controller (Managed-bean) heeft een methode getBoeken(), deze geeft dan een Collection terug met alle boeken die er binnen je applicatie voorkomen. Vervolgens maak je van deze klasse een managed-bean in je faces-config.xml, die kan er ongeveer zo uitzien:

code:

<managed-bean>
    <managed-bean-name>controller</managed-bean-name>
    <managed-bean-class>package.Controller</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

In JSF zou je dan het volgende kunnen doen:

code:

<dataTable value=#{controller.boeken} var="boek">
    <h:column>
         <h:outputText value="#{boek.naam} />
    </h:column>
</h:dataTable>

Wat doet de bovenstaande code nu?

code:

value=#{controller.boeken}

Dit zorgt ervoor dat Controller.getBoeken() uitgevoerd wordt en vangt deze waarde op.

code:

var="boek"

Hier zorgen we er vervolgens voor dat je ieder boek simpel kan aanroepen met de variabele boek. Dit houdt de code wat overzichtelijker naarmate het groter wordt.
De column tags zorgen er vervolgens voor dat het geheel in een kolom geplaatst wordt. Zo zou je bijvoorbeeld een tweede kolom met het isbn-nummer op kunnen nemen.

code:

<h:outputText value="#{boek.naam} />

Dit print de naam van het boek.

Maar dit is hoe ik het momenteel aanpak, er zijn natuurlijk ook andere opties.

De Controller is ervoor om een request naar de juiste output te leiden.
Het idee is dat elke request op dezelfde file binnenkomt (je controller) en de controller aan de hand van de parameters in de url beslist welke Action de request verder moet afhandelen.

Bedoel je hier nu de Faces Servlet en zijn navigation-rules?

[ Voor 18% gewijzigd door Verwijderd op 24-01-2005 19:37 . Reden: Je moet niet met /quote beginnen ;) ]

[Verwijderd]

Ok dat van die datatable hebben we nu ook zo opgelost.

Nu voorbeeld:
-login.jsf met login formulier: login, paswoord en ok.

Login value is gekoppeld met loginBean.username
paswoord value is gekoppeld met loginBean.paswoord

ok action is gekoppeld met loginbean.isSuccesVol (methode)

Deze methode zoekt op in de repository of het een geldige login is en geeft de value "geldig" of "ongeldig" terug.

In de navigtion rule hebben we een rule toegevoegd: van outcome geldig naar viewMain.

Is dit de juiste manier van te programmeren?

[Verwijderd]

Verwijderd schreef op maandag 24 januari 2005 @ 20:44:
......
Is dit de juiste manier van te programmeren?

Het is een manier om in JSF zo te werken. Of het de juiste manier van programmeren is is natuurlijk moeilijk te bepalen. Iedereen heeft hierin zijn eigen voorkeuren en voor verschillende dingen zullen ook verschillende manieren zijn om het te programmeren die ieder hun voordeel hebben in een situatie.
Het is overigens wel een manier die in boeken en tutorials wordt gebruikt dus niet 100% fout .

[Verwijderd]

Ik lees hier dat er mensen zijn die daadwerkelijk jsf gebruiken. Nu zou het mischien een apart topic kunnen zijn, maar toch maar even hier vragen:

Hoe bevalt jsf nou in de praktijk?