I guess I'd have to have a fuller description of your specific example to answer the question. Too many hypotheticals at this point. ;-) I'm not sure what the purpose is for the new list bean that you mention.
- Brendan -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005 3:53 PM To: MyFaces Discussion Subject: Re: more on architecture really confused on something (shocker:) On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > 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. I'm proabably missing something but I don't think it is the same thing. Here, I think is a good example... Imagine you have a table on a JSP that uses "EmployeeListBean" to get it's TableData model in order to display the list. You also still have your EmployeeAction for dealing with the CRUD stuff. In EmployeeAction after an update is done, you remember to call employeeListBean.setEmployees() to repopulate your list. Now later on, a new JSP page is used to display some employees and a slightly different ListBean is needed.. call it EmployeeOtherListBean. You still want to be able to do an update of an employee from that page by clicking on a link. What does this now mean for your EmployeeAction? *You now need to alter your EmployeeAction to accomodate the new managed bean 'EmployeeOtherBeanList.* You need to add a new managedBean property and a reference in the Action to EmployeeOtherListBean. You'll also need logic to figure out which listBean to pull the row from and which on to reset the employees for. You see how tightly coupled they are? JSF is supposed to make things easier, and yet in this case I think it's now made a lot more work simply because I wanted to do an Update of an Employee from a page using a differen type of DataModel. Hate to use Struts again as my frame of reference, but in Struts my "EmployeeAction" wouldn't be touched at all. All it cared about was that it got an "ID" to look up to get an employee, calls a service class to get Employee from backend, and forwards you to the page to edit the employee. All that would change in this example is a different Action might be used to populate the initial list, but the CRUD Action (EmloyeeAction) remainds unaltered. > 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? Head is too clouded right now to know if it makes sense, I'll get back to you:)
