Well, I don't personally see it as problematic, since, in your "typical" example, you say you need to remember to call request.setAttribute(). If you just change this to calling getMyBean.setEmployees() instead, it's basically the same thing.
Either way, you need to remember to tell something to set itself. In our JSF applications, we rarely deal with the request directly anymore; we always deal with our managed data beans, which just happen to be *in* the request. And those data beans could exist in a variety of JSPs and they could be access by a variety of actions. Does that make sense? - Brendan -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 3:00 PM To: MyFaces Discussion Subject: Re: more on architecture really confused on something (shocker:) On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > Are you trying to do everything in EmployeeListBean, or do you have an > EmployeeListAction class to handle actions (e.g., looking up an > employee's information, processing "Save") separate from the data? If > you have a separate EmployeeListAction bean that has a managed property > reference to EmployeeListBean, then, when the Action is called with the > "Save", it can invoke a method on the EmployeeListBean to reset its > data, passing the new list of data as an argument. That's exactly what I have since I followed your advice/example, but this is the part that I was running into that I didn't like that you mentioned above: "when the Action is called with the "Save", it can invoke a method on the EmployeeListBean to reset its data, passing the new list of data as an argument." That's where I had the idea in the initial post to add the "populateDataModel" method. I'm not so fond of this approach though since now all your other objects HAVE to become responsible for remembering to call this method to upate the model data. Contrast this with a typical web app where you'd have an Action you would call to get your list ready for the page... EmployeeListAction: getEmployeeList(....) { List list = someBackendServiceClass.getMyList(); request.setAttbribute("list", list ); } In another action when you did the update you are done - you don't need to remind the EmployeeListAction above to do anything. Only the Action responsible for displaying the page (EmployeeListAction) has to ever worry about making sure the request is set up correctly for displaying the list. With the approach I'm seeing us have to do with JSF, some other bean (the one doing the update.. maybe EmployeeAction) has to remember afterwards, "Oh, I need to go tell some other class that it needs to be updated with what we just did so the datat can be refreshed" I'm not so sure I like this tight coupling between separate beans. You (or anyone else) see this as slightly problematic?
