Any reason in getUsers() that you are going directly to request to get the companyID parameter, as opposed to getting it from the form?
It might be worth noting that some people dislike the use of DispatchAction in most cases, me included. This is a fairly minor point as the actual code you wrote would be essentially unchanged without DispathAction, just housed in individual classes. I'm not sure one answer is really better than the other, it's been debated at various points, but as long as people understand there's nothing that says you have to do this in a DispatchAction, then it's all good :) (For any newbies reading this, the difference that matters is that with a DispatchAction, you have a single entry in struts-config, but you have to pass a parameter with each request. With plain Actions, you would have multiple mappings like /setupForAdd, /setupForEdit, /add, /delete and so on in this case, but no parameter to pass around. There are pluses and minuses to each approach, but they get you to the same basic place in the end.) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, July 7, 2005 11:58 am, Rick Reumann said: > I posted this in reply to Tony's post, but figured this stuff comes up > all the time and to those new to Struts, this below might help.... > > You can accomplish 99% of what you want with this simple design > > For the sake of this discussion I'm going to assume you are using a > DispatchAction. In case you don't know, a DispatchAction just lets you > combine similar types of behaviors into one Controller... so rather than > have an UpdateUserAction, DeleteUserAction, etc.. you have one Action... > UserAction with methods in it update(..), delete(...), etc. > > So typically here's what I do and it covers 'almost' all of my > scenarios. I find it easier to work with examples and your "User" is a > good example to work with. Lets say we want to CRUD (create, retrieve, > update, delete) for a User. > > 1) Step 1 Create a UserActionForm > For simplicity it has just two main properties... > String userName; > Integer userID; > Also though we are going to provide the dispatch (or action) as > a property to give it default value of "add" > String dispatch = "add" > This way if we go right to the page it'll have 'add' by default > > 2) Step 2 Have a BusinessObject back reprsenting your User. I like to > pass Business objects (not tied to Struts to my backend), so you'll have > in this case a simple: > > "UserVO" (value object.. could just call it "User" but for this > discussion seeing VO helps you understand what it is) > String userName; > Integer userID; > > //NOTE: it helps if the properties of the VO and the ActionForm have > the same name. Not a requirement but makes things easier which I'll show > > > 3) Create a "UserDispatchAction" > > This will have the following methods: > (all with signature public ActionForward methodName (ActionMapping > mapping, ActionForm form, HttpServletRequest request, > HttpServletResponse response) > > setUpForEdit(..) > setUpForAdd(..) > add(...) > edit(...) > delete(...) > getUsers(...) > > > Before I get to the setUpForEdit() lets just handle the others... > > In all cases you will be submitting either a form or a link but in > the struts-config file this will map to our UserAction where we also > include the name of our UserActionForm, so our UserActionForm is always > populated. > > So our Add method in our Action... > > //**ADD**** > public ActionForward add(ActionMapping mapping, ActionForm form, > HttpServletRequest request, HttpServletResponse response) throws Exception > { > > UserActionForm userForm = (UserActionForm)form; > UserVO user = new UserVO(): > //copy our form properties into the VO > PropertyUtils.copyProperties( user, userForm ); > ourBackendDelegate.addUser( user ); > return mapping.findForward("to_form"); > } > > // UPDATE and DELETE... > Same as above except for use of... > > ourBackendDelegate.deleteUser( user ); > ourBackendDelegate.updateUser( user ); > > // THE SET UP FOR EDIT > > Ok, this is the one you were asking about. Now you have to think about > how you would get here? Typically you'd get to an edit page by clicking > on a user record to say "Hey, I want to edit this guy's user > information" So imagine a case where we have a list of users and > 'userID" for each in the list, they click on the link and they'll come > to this method which will get our user and then forward them to a page > to do the editing. The method will look like... > > public ActionForward setUpForEdit(ActionMapping mapping, ActionForm > form, HttpServletRequest request, HttpServletResponse response) throws > Exception { > > UserActionForm userForm = (UserActionForm)form; > //userID is set in this form when the user clicked on the link > //lets get our real business object of this user, based on ID.. > UserVO user = ourBackendDelegate.addUser( userForm.getUserID() ); > //copy the other way this time, from UserVO to our Form... > PropertyUtils.copyProperties( userForm, user ); > //finally we are going to reuse or form for add and edit, so > //we will set up our dispatch/action parameter > userForm.setDispatch("edit"); > return mapping.findForward("to_form"); > } > > > //The get users - this will display our users on the page > public ActionForward getUsers(ActionMapping mapping, ActionForm form, > HttpServletRequest request, HttpServletResponse response) throws Exception > { > //lets say pass in companyID > Integer companyID = Integer.valueOf( > request.getParameter("companyID")); > > //get our list of users to display on page > List users = ourBackendDelegate.getUsers( companyID ); > request.setAttribute("users", users ); > > return mapping.findForward("to_display"); > } > > 4) sample config... > > > <action path="/userMaintenance" type="com.foobar.UserAction" > name="userActionForm" > scope="request" > validate="false" > parameter="dispatch"> > <forward name="to_form" path="/userForm.jsp"/> > <forward name="to_display" path="/displayUsers.jsp"/> > </action> > > 5) Sample form > > <html:form action="/userMaintenance"> > Name: <html:text property="name"/><br/> > <html:hidden property="userID"/> > <html:hidden property="dispatch"/> > > <html:submit value="${userForm.dispatch}"/> > <!-- above button logic can be done many ways, just for > simplicity i'm using the dispatch name--> > <html:form> > > 6) Sample page displaying users lets them edit and delete them > > <c:forEach items='${users}' var='users'> > <c:url var="editUrl" scope="page" value="/userMaintenance.do"> > <c:param name="dispatch" value="setUpForEdit"/> > <c:param name="userID" value="${user.userID}"/> > </c:url> > <c:url var="removeUrl" scope="page" value="/userMaintenance.do"> > <c:param name="dispatch" value="delete"/> > <c:param name="userID" value="${user.userID}"/> > </c:url> > ${user.name} <a href="${editUrl}">[ EDIT ]</a> <a > href="${removeUrl}">[ DELETE ]</a> > </c:forEach> > > > > > Basically 90% of applications are doing something similar to the above. > Presenting data to users and often letting them click on things to edit. > Personally, this concept works well for me. There are several tweeks I > have to do for more complex things, but this is the 'meat' of most > applications. > > -- > Rick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
