I have a page with a datatable in a CRUD scenario. It seems to me that JSF centers around the concept of a POST instead of GET. I need to populate the datatable when the page is loaded. Where should this population occur? In the constructor? Is there another place? I have not been able to find any examples of this scenario? Can someone point me in the right direction and/or provide some examples? Do I have to actually get the data from another page and put it in the session and then send someone to this page? That seems to be a little much? Am I limited to only letting the page load to an empty datagrid and forcing the user to press a button after the page loads? Is the bean constructor the only place the loading can occur? Can someone please point me in the right direction as this approach is extremely easy in dot.net? [ August 26, 2007: Message edited by: Anthony Sykes ]
Joined: May 26, 2007
You are not limited in any way. One very easy way to do it is to lazy initialize the collection binded to the table: if the collection is empty, query the database. It has nothing to do on JSF being POST based, and I don't think is a problem unless you are very religious about the REST style. [ August 26, 2007: Message edited by: Gabriel Claramunt ]
I think you're viewing the whole concept as a client-server app mechanism. Maybe you could do that in .Net by using an ActiveX client control, but you wouldn't get any business from me, since ActiveX cannot be used on my OS/browser.
JSF is an HTTP function at its root, and as such, you don't set up components and let them chat back and forth the way you would in client/server. Instead, the JSF servlet gets an HTTP request, constructs objects, invokes the object methods, and the result are then converted into an HTTP response stream which is then transmitted back to the user's web browser. Once the final byte of the HTTP response stream has been transmitted, all of the server objects that are not either part of the server object set (application objects) or stored in the user's session are destroyed.
That has absolutely nothing to do with CRUD, however. I have a very nice little architecture for doing basically nothing but CRUD built on JSF. It uses common JEE design patterns and ORM to manage the CRUD, and those parts of the system could care less what's managing the display part of the app. JSF manages the display and talks to the business layers, which in turn talks to the persistence layers and everything's neat and tidy. It's not all rammed into one file like an ASP, but it's a lot easier to maintain all those simple uniform little pieces-parts than it would be to wrestle with large irregular do-everthying files.
Customer surveys are for companies who didn't pay proper attention to begin with.