Re: pre-populating form fields when called in edit mode.
Paul Benedict wrote: But that of course doesn't make the list persist. Most frameworks heavily rely on the user session and I am now a strong believer that's the better way of doing things. Just as a relevant side-note... I suggest working in a distributed environment for a while and see if your belief persists (pun intended) :) Session replication, especially when your session object grows larger, as they obviously will tend to in a session-heavy framework, becomes more and more of a concern. I seem to remember IBM recommending something like a 32k maximum for session, although I'm not sure how accurate my memory is, the point remains that they are recommending a value that is pretty easy to blow past without much effort. The concern is obviously not as big when your on a single box, but even then you need to think about session persistence, if active, which will still incur a penalty for a larger session. I think request scope still has a definite place in the world. This relatively recent movement to heavy session usage still has its own set of problems. OF course, everyone is trying to make the web more fat client-like, me included, and that's mostly where this drive towards session comes from. It's interesting to me that a fairly short while ago, the use of session for anything other than *very* simple things was a pretty highly discouraged practice... I remember Microsoft used to say you should almost *never* use session (or worse, application scope), everything should be request-based. Now, I don't think *that* extreme is the right answer, but it has been a complete 180 (I guess MS isn't the best example, but your heard very similar recommendations from the Java camp as well). Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
Vikrama Sanjeeva wrote: Having separate Actions for insert, update and delete is better. Why? Do you make separate DAO objects? ie UpdateDao, InsertDao, RetrieveDao? I'm guessing you don't. So, it would help if you backed up your claim that separate Actions are better than a Dispatch action instead of just claiming it's better. Your approch for making SetUpAction is right, but it's better to make separate JSP's instead of writing if-else logic for headers and other related messages. So you would rather duplicate JSPs to make basically identical Edit and Insert pages except for a simple header and possibly a different button? Please explain how in the world that is better. I'm hoping it's just a language barrier that is making you appear so dogmatic in your claims. You might choose to do things differently but it would help if you gave some reasons why you make such bold claims about things being better. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
Hi, Well, i said better due to sake of simplicity. Keeping all the logic in Dispactch action seems complex to me. And right now I've implemented more or less same technique (not exactly Dispatch action) and the code is bit complex to me. Again for JSP's, I don't want to make code complex by putting if-else logic. But it depends how much you have to write if-else? If it is couple of conditions and more resusability, then I would prefer it Regarding the word better, I would suggest don't take it serious. I said better w.r.t me. This is not any claim in support of separate actions. However, being a junior developer, I'm always looking for effecient and recommended development approaches by senior developer's community. Bye, Viki. On 12/28/05, Rick R [EMAIL PROTECTED] wrote: Vikrama Sanjeeva wrote: Having separate Actions for insert, update and delete is better. Why? Do you make separate DAO objects? ie UpdateDao, InsertDao, RetrieveDao? I'm guessing you don't. So, it would help if you backed up your claim that separate Actions are better than a Dispatch action instead of just claiming it's better. Your approch for making SetUpAction is right, but it's better to make separate JSP's instead of writing if-else logic for headers and other related messages. So you would rather duplicate JSPs to make basically identical Edit and Insert pages except for a simple header and possibly a different button? Please explain how in the world that is better. I'm hoping it's just a language barrier that is making you appear so dogmatic in your claims. You might choose to do things differently but it would help if you gave some reasons why you make such bold claims about things being better. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I'm going to have a good lesson that will show exactly what you want, but until then, if you want a quick preview of the Action class, put it here: http://www.reumann.net/misc/EmployeeAction.txt You are following an example where I showed using a separate Action for each behaviour whereas the link above shows a DispatchAction. It's just a short cut for putting related tasks in one action versus using separate actions. Regardless, though, let's assume your separate Action approach which is just fine. I typically would make a SetUpAction that you would call before you forwarded to the JSP page where you would be editing the form. So let's assume you went to edit the Employee from a link you clicked on, the process would be... 1) Click on link, passing something like an employeeID 2) link submits to your SetUpAction 3) In SetUpAction it checks the Request to see if an employeeID was passed to it. If ti was, you go database get your Employee object (EmployeeDTO following your old example) and then you can use BeanUtils like you did before... BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings you to the employeForm.jsp page. 4) employeeForm is now all set up with the employee information and clicking 'submit' would bring you to an UpdateEmployeeAction to do the actual update (just like you did for the InsertEmployeeAction). You can easily reuse the form for doing both inserts and updates. Typically you'll have to do a little bti of logic for some of the verbage to decide what to display (ie is header Insert Employee or Update Employee). You can base your logic to decide what to display on various things (in this case it could be as simple as looking for an employeeID .. if you have one then you know you are doing an update... if you don't than you are doing an insert, but of course there are plenty of other ways to do it as well. On 12/25/05, Vikrama Sanjeeva [EMAIL PROTECTED] wrote: Hi, Here is the sequence: 1: User fill up's employeeForm.jsp which have multiple text fields, radio buttons, text area's and dropdowns. 2: On pressing Submit button in employeeForm.jsp, InsertEmployeeAction is called which do the following: 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm) 2.2) DataBaseService.insertEmployee (employeeDTO) 2.3) return mapping.findForward(success); Now, I want to call same employeeForm.jsp in editable mode, such that all the fields (text fields, radio buttons, text area's and dropdowns) are pre-populated. What approaches are there to achieve this? I'm looking for a way which uses same BeanUtils.copyProperties() and copy the employeeDTO to employeeForm (Bean). Something like this: When user click's Edit Employee Form link, an action (EditEmployeeAction) will be called. Which will do the following: 1. Fetch the employee information from database in employeeDTO. 2. Get the handle of EmployeeForm (ActionForm), lets say employeeForm 3. BeanUtils.copyProperties(employeeForm, employeeDTO) 4. return mapping.findForward(editMode); I'm not sure whether this approach will work or not? And whether I have to make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode ( employeeFormEdit.jsp). If this the case, then I guess, I've to make EmployeeFormEdit.java (ActionForm) as well. It will be great if anybody could help me here. Thanks in advance. Bye, Viki. -- Rick
Re: pre-populating form fields when called in edit mode.
If you treat inserts like updates, things get much easier. When you show employee in edit mode, just pull his data from database into BO/DTO and show it. When you add new employee, create a new empty BO/DTO first. Then show it just like you would do it in edit mode. If user clicks Save, insert data. If user cancels, just dispose the object, this is it. Michael J. On 12/25/05, Vikrama Sanjeeva [EMAIL PROTECTED] wrote: Hi, Here is the sequence: 1: User fill up's employeeForm.jsp which have multiple text fields, radio buttons, text area's and dropdowns. 2: On pressing Submit button in employeeForm.jsp, InsertEmployeeAction is called which do the following: 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm) 2.2) DataBaseService.insertEmployee (employeeDTO) 2.3) return mapping.findForward(success); Now, I want to call same employeeForm.jsp in editable mode, such that all the fields (text fields, radio buttons, text area's and dropdowns) are pre-populated. What approaches are there to achieve this? I'm looking for a way which uses same BeanUtils.copyProperties() and copy the employeeDTO to employeeForm (Bean). Something like this: When user click's Edit Employee Form link, an action (EditEmployeeAction) will be called. Which will do the following: 1. Fetch the employee information from database in employeeDTO. 2. Get the handle of EmployeeForm (ActionForm), lets say employeeForm 3. BeanUtils.copyProperties(employeeForm, employeeDTO) 4. return mapping.findForward(editMode); I'm not sure whether this approach will work or not? And whether I have to make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode ( employeeFormEdit.jsp). If this the case, then I guess, I've to make EmployeeFormEdit.java (ActionForm) as well. It will be great if anybody could help me here. Thanks in advance. Bye, Viki. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I am going to ask a related question... so take your best shot :-) I have an edit form in which I have to load a list from the database. The list is actually based on locale. What's the best solution here? I am using real action forms - not that dynafluff stuff ;) Is it to simply make my form session scope and attach the list to my form? THANKS! Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I would use the Request for such a List and wouldn't even bother putting it in the ActionForm (unless of course the list is something the user is actually editing, then yes, you'd add that List as an ActionForm property). I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. So for example if you were displaying a list of favorite cars for the user to pick from I would just put that list in the Request and the selectedCar would be the property you would concern youself with in the ActionForm. (If you are worried about performance, I'd put the performance concerns on the backend.. let the back end take care of any list caching.) On 12/26/05, Paul Benedict [EMAIL PROTECTED] wrote: I am going to ask a related question... so take your best shot :-) I have an edit form in which I have to load a list from the database. The list is actually based on locale. What's the best solution here? I am using real action forms - not that dynafluff stuff ;) Is it to simply make my form session scope and attach the list to my form? THANKS! Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rick
Re: pre-populating form fields when called in edit mode.
I would use the Request for such a List and wouldn't even bother putting it in the ActionForm But that of course doesn't make the list persist. Most frameworks heavily rely on the user session and I am now a strong believer that's the better way of doing things. I wonder if allowing the developer to be concerned with page/request/session/application scope creates a whole problem in itself; this problem is so unique to Struts and JSP development, but not a thought with Tapestry or JSF. If I remember correctly, I know you promoted a solution of using the validate() method of containing those populated lists. That's on the right track but I think a misuse of the validate() method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that is called before executing mostly everything else. I would like to see this ported into 1.3 because with the ComposableRequestProcessor, you can slam in any cool customization into the processing chain! I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. Ah! You and I really chatted this up a year ago. I was gung-ho for this method, but no longer. I was a very die hard proponent of this but I could only go so far with it; the problem was it made no logical sense to contain some data in the form (which was then put into the request) and then some data in the request. Both end up in the request, so why separate the two? It did not allow me to encapsulate my data --- and it created a very difficult nightmare to track down which request attributes were appropriate for a given form. So in response, I concluded this method was good up to a point, but everything in the action form suited more complex cases. This is my opinion based on experience. Sometimes I just have to travel down the road far enough to see how far the solution will take me -- some solutions are 20 gallon cars, others 30, 50. What seemed like a good solution back then turned out to be the best at that time; now I think everything in the form is a better performing car. Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
I guess it is not surprising that I would do a completely orthogonal thing ;-) ActionForm is an I/O buffer, it aggregates BO/DTO + lists/options for selectboxes + error messages for the aggregated BO. BO exposes properties that are editable and persistable. BO does not care about option lists because actual BO or database row contains only one value. BO is a nested property within session-scoped ActionForm. Whenever error is made and page is reloaded, or a user just navigates a page, it displays BO in its current state and associated messages. ActionForm should be removed from session manually, this is the price to pay. I thought about automating this, but Hubert pointed out that a user can open several browser windows for one app, so I gave up on this. Storing list in the session (session-scoped ActionForm, poteito-potahto) also helps in case the option list itself was changed down on the business/persistent level, so a new instance in request would not match previous one, and current selection would get screwed up. Actually, if the option list is changed very rarely, I'd put it into app context. If it is changed more frequently, then into session scope, to isolate user session from potential changes. Michael. On 12/26/05, Rick Reumann [EMAIL PROTECTED] wrote: I would use the Request for such a List and wouldn't even bother putting it in the ActionForm (unless of course the list is something the user is actually editing, then yes, you'd add that List as an ActionForm property). I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. So for example if you were displaying a list of favorite cars for the user to pick from I would just put that list in the Request and the selectedCar would be the property you would concern youself with in the ActionForm. (If you are worried about performance, I'd put the performance concerns on the backend.. let the back end take care of any list caching.) On 12/26/05, Paul Benedict [EMAIL PROTECTED] wrote: I am going to ask a related question... so take your best shot :-) I have an edit form in which I have to load a list from the database. The list is actually based on locale. What's the best solution here? I am using real action forms - not that dynafluff stuff ;) Is it to simply make my form session scope and attach the list to my form? THANKS! Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
ActionForm should be removed from session manually, this is the price to pay. I thought about automating this, but Hubert pointed out that a user can open several browser windows for one app, so I gave up on this. One of the biggest concerns I had too was that using the session means only one form can exist per session. So if the user had multiple windows open, it would completely mess things up. So I was for 2 years against making any forms in the session -- until Tapestry woke me up =) It is now my opinion that any complex web app form will have BO, DTOs, and lists all together. This merits only ONE of these being editable at once. Got multiple windows open? Sorry user, but you're not going to be able to use my app. Spring Framework's Web Flow is an excellent plugin for these situations; it allows multiple flows until the first one wins. I just had to accept the fact that until Struts allows forms to exist on a per-view basis, the best a complex app can do is limit one form to the session. Simple forms can be request based, but anything editable (and worthwhile to the customer) definitely has to be session. Paul __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pre-populating form fields when called in edit mode.
On 12/26/05, Paul Benedict [EMAIL PROTECTED] wrote: I would use the Request for such a List and wouldn't even bother putting it in the ActionForm But that of course doesn't make the list persist. Most frameworks heavily rely on the user session and I am now a strong believer that's the better way of doing things. I think it depends on the kind of list and each person may have their own preference. For example, I personally would reather persist on the backend with iBATIS or hibernate vs just stuffing things in the Session. For example, what if it's just one form that needs the list and the user only hits the form one time during the whole time using the site? You've now just just stuff a list in Session scope for what gain? If it's a list that actually will *never* change than put in Application scope. I don't see the point of putting most lists in Session scope. For struts apps most people end up stuffing lists in Session scope so that if validation fails their lists persists on the page. I don't call the validate method manually so I don't run into this problem. Also remember we are talking about lists here. Don't think I'm against the Session (if you do a mailing list search you'll see I love the Session maybe too much:) If I remember correctly, I know you promoted a solution of using the validate() method of containing those populated lists. That's on the right track but I think a misuse of the validate() method. Actually you are remembering incorrectly:) I'm assuming you are referring to this article http://reumann.net/struts/articles/request_lists.jsp, but there I stated exactly the OPPOSITE - that you SHOULD NOT use the validate method for setting up those lists. I said I do validation manually. I did show how you can simply call the form's validate method manually (even though I don't even go that far in my own apps), but I never mentioned it's a good idea to set up lists in your validate method. Thankfully it's corrected by Struts 2.0/Webwork by a prepare() method that is called before executing mostly everything else. JSF is great at handling all of this as well so don't leave JSF out. I try to keep my ActionForm with 'only' properties that the user can edit - nothing more. Ah! You and I really chatted this up a year ago. I was gung-ho for this method, but no longer. I was a very die hard proponent of this but I could only go so far with it; the problem was it made no logical sense to contain some data in the form (which was then put into the request) and then some data in the request. Both end up in the request, so why separate the two? It did not allow me to encapsulate my data --- and it created a very difficult nightmare to track down which request attributes were appropriate for a given form. So in response, I concluded this method was good up to a point, but everything in the action form suited more complex cases. Well think about it this way, JSF has it right in that it eliminates the need for an ActionForm. It let's you use your regular Value objects which I think is great (I hate the Struts ActionForm:). JSF gets around the Lists problem, though, by taking a whole different model approach which has been talked about enough on the list here but I do like how JSF handles this. (That being said, there are some things I have found frustrating using JSF(MyFaces) so I'm not ready to jump ship yet.) What seemed like a good solution back then turned out to be the best at that time; now I think everything in the form is a better performing car. I only have one prep method in my Action so anything that needs to get setup in a form goes in that one place and can be called from the other dispatch methods in the Action. I like the approach since it is easy to maintain. I don't really see what putting the Lists in your ActionForm gains you? You are still going to have to populate them from method calls to other backend objects. Even then, I would think you'd want to use a prep method for that as well since you might need to prep those lists in your form from several dispatch methods. I'm not so sure how doing... form.setSomeList(list) gains you anything over request.setAttribute(Constants.SOME_LIST, someList ); especially if both types of setting is done from a centralized place in your Action. Then again, I'm of course not saying it's bad or wrong to put the stuff in the ActionForm (I even like approaches where nest your value object in the ActionForm). Overall though, I'm just not a fan of having to be stuck using ActionForms in the first place, so I try to avoid as much dependency on them as possible (I really do like the managed bean approach of JSF which handles this stuff so nicely). -- Rick
Re: pre-populating form fields when called in edit mode.
Hi, Having separate Actions for insert, update and delete is better. Your approch for making SetUpAction is right, but it's better to make separate JSP's instead of writing if-else logic for headers and other related messages. Bye, Viki. Note: When u'r done with lesson, please sent in this group. Thank you. On 12/27/05, Rick Reumann [EMAIL PROTECTED] wrote: I'm going to have a good lesson that will show exactly what you want, but until then, if you want a quick preview of the Action class, put it here: http://www.reumann.net/misc/EmployeeAction.txt You are following an example where I showed using a separate Action for each behaviour whereas the link above shows a DispatchAction. It's just a short cut for putting related tasks in one action versus using separate actions. Regardless, though, let's assume your separate Action approach which is just fine. I typically would make a SetUpAction that you would call before you forwarded to the JSP page where you would be editing the form. So let's assume you went to edit the Employee from a link you clicked on, the process would be... 1) Click on link, passing something like an employeeID 2) link submits to your SetUpAction 3) In SetUpAction it checks the Request to see if an employeeID was passed to it. If ti was, you go database get your Employee object (EmployeeDTO following your old example) and then you can use BeanUtils like you did before... BeanUtils.copyProperties(yourForm, employeeDTO ); Foward success brings you to the employeForm.jsp page. 4) employeeForm is now all set up with the employee information and clicking 'submit' would bring you to an UpdateEmployeeAction to do the actual update (just like you did for the InsertEmployeeAction). You can easily reuse the form for doing both inserts and updates. Typically you'll have to do a little bti of logic for some of the verbage to decide what to display (ie is header Insert Employee or Update Employee). You can base your logic to decide what to display on various things (in this case it could be as simple as looking for an employeeID .. if you have one then you know you are doing an update... if you don't than you are doing an insert, but of course there are plenty of other ways to do it as well. On 12/25/05, Vikrama Sanjeeva [EMAIL PROTECTED] wrote: Hi, Here is the sequence: 1: User fill up's employeeForm.jsp which have multiple text fields, radio buttons, text area's and dropdowns. 2: On pressing Submit button in employeeForm.jsp, InsertEmployeeAction is called which do the following: 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm) 2.2) DataBaseService.insertEmployee (employeeDTO) 2.3) return mapping.findForward(success); Now, I want to call same employeeForm.jsp in editable mode, such that all the fields (text fields, radio buttons, text area's and dropdowns) are pre-populated. What approaches are there to achieve this? I'm looking for a way which uses same BeanUtils.copyProperties() and copy the employeeDTO to employeeForm (Bean). Something like this: When user click's Edit Employee Form link, an action (EditEmployeeAction) will be called. Which will do the following: 1. Fetch the employee information from database in employeeDTO. 2. Get the handle of EmployeeForm (ActionForm), lets say employeeForm 3. BeanUtils.copyProperties(employeeForm, employeeDTO) 4. return mapping.findForward(editMode); I'm not sure whether this approach will work or not? And whether I have to make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode ( employeeFormEdit.jsp). If this the case, then I guess, I've to make EmployeeFormEdit.java (ActionForm) as well. It will be great if anybody could help me here. Thanks in advance. Bye, Viki. -- Rick
pre-populating form fields when called in edit mode.
Hi, Here is the sequence: 1: User fill up's employeeForm.jsp which have multiple text fields, radio buttons, text area's and dropdowns. 2: On pressing Submit button in employeeForm.jsp, InsertEmployeeAction is called which do the following: 2.1) BeanUtils.copyProperties( employeeDTO, employeeForm) 2.2) DataBaseService.insertEmployee (employeeDTO) 2.3) return mapping.findForward(success); Now, I want to call same employeeForm.jsp in editable mode, such that all the fields (text fields, radio buttons, text area's and dropdowns) are pre-populated. What approaches are there to achieve this? I'm looking for a way which uses same BeanUtils.copyProperties() and copy the employeeDTO to employeeForm (Bean). Something like this: When user click's Edit Employee Form link, an action (EditEmployeeAction) will be called. Which will do the following: 1. Fetch the employee information from database in employeeDTO. 2. Get the handle of EmployeeForm (ActionForm), lets say employeeForm 3. BeanUtils.copyProperties(employeeForm, employeeDTO) 4. return mapping.findForward(editMode); I'm not sure whether this approach will work or not? And whether I have to make seprate JSP's for 1st time fill up (employeeForm.jsp) and edit mode ( employeeFormEdit.jsp). If this the case, then I guess, I've to make EmployeeFormEdit.java (ActionForm) as well. It will be great if anybody could help me here. Thanks in advance. Bye, Viki.
