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?
