Whew! Thank you all for responses. I am sorry that I confuse some of you. Now I kind of got confused myself, because there are some usages I did not even thought of :)
First, the things that I can state for sure. * I started to use Struts when I had rather vague knowledge about servlets/JSPs, so it was easier and simpler for me to understand the idea, that a form bean belongs to action, and if I want to obtain data or to dislpay data, I should put it in the bean. It seemed... observable. Putting it somewhere out of the form bean seemed like shooting it in the outer space :) Thus, I got used to #4. Then, when I felt that I had too much different data in one bean, I came up with #5. * Reloading a page in case of error by forwarding to "input" location does not mean that a form bean is used as "output". Error handling is kind of special case, which allows to retain form values and redisplay them along with errors. But it is still an "input" form bean for me. * for me, using form bean as "output" means, that you do not stick your DTO or business delegate directly to request or session, but either put a reference to it in the form bean, or copy it field by field into the form bean. Then you display whatever is accessible from the form bean. > For Input, I take the details in via a form, like most > I assume; For Viewing/Editing or Amending I take a POJO > from Hibernate and then using PropertyUtils copy the data > from the POJO to the Form and then use the form to display > as either text (for Viewing) or as objects (for Editing). > This ensures that I do not have to cater for two types > of object (POJO and Form) within the JSP; This is so different from what I do :) I use what is called BTO, I guess. I do not use plain DTOs, do not see point in them. I need not just data, but business rules as well available on web layer, so I use normal business objects to handle my input and output data. I do not really care is it viewing or editing or creating a new object. I just create a new business object (or load a copy of it from database) and stick it in the session. I can update it, no problem. Even if input data is wrong and object cannot be persisted, I still update it with input data, because it is a _copy_ or real persistent object. Then I either discard it or persist it. Viewing or editing mode is basically limited by JSP. > I would think the essential question is whether people use ActionForms to > > 1) Harvest or populate only the default values of form controls. > 2) Populate other page members, such as the items displayed on > a drop-down lists. I used to use it for (2) as well. But now I store all my object data including lists in a single business object. And I usually have a reference to this business object from a form bean. > Some of you needs a struts mentor ;-) > > You use display any bean or collection in struts, if it's RO, > you don't use formBeans and you use JSTL/displaytag. > If you edit, update, insert, etc, you have to use and map > a form bean and html tag. I don't want to use two sets of tags. I know Struts tags and I use them. I do not use JSTL. > Michael, is #4 clear?? I think people are misunderstanding it. > Developers can use a form for input and output (#4/1), > but not put display (pure output) data in there (#4/2). > The difference is between an edit and view page. Um... I personally do not differentiate between edit and view model in the application. For me, this is just object. Whatever you can do with it, depends on particular JSP and its tags. So, for me edit and view is the same ;) Of course, I usually do not use HTML form for viewing, but I access my object in the same manner as for editing, that is, through the reference on a form bean. It just seems simple and more uniform to me. > It might be helpfult to clarify whether by output we mean > output that is being used within the <html:form> tags, > or any arbitrary dynamic output. I thought, both. I do not know how to treat the "border" case, when you have all your data in business object or DTO, but have a reference to this object on a form bean, thus using nested properties. I consider this as using form bean for output as well. I usually use this approach. > This is my point too. I think the majority of people > answered #4 because data within <html:form> tags is I/O, > but it's not the type of output (i.e., arbitrary display > output) I think Michael was trying to convey. If you can access the object, that you display on the result page, from the form bean either as a simple property or as a nested property, this is still "using form bean for output" for me. I do not care is it in the form or not ;) > Most people I think agree with the idea of a single object > communicating between the control and the model, i.e., > I don't see too many people saying we should have one object > that goes TO a business delegate and one > that comes FROM that delegate, i.e., two DTOs per model call, > although I suppose there are some valid arguments for that. I do not use plain DTOs aka structures. I use real business objects, which are then can be persisted. How exactly they are persisted and loaded, depends on whether I use JDBC/iBatis or EJB. I do not use Hibernate. ---- Summing all up, I can describe the approach I use: * I use real business objects on web layer. I do not care that I need to recompile web app when by business objects change, this is my app ;) * I use objects for I/O. Each field belongs to an object, fields are not scattered through form bean. * I have a reference to business object from a form bean and use html tags with nested objects * I do not differentiate between new or existing object, as well as object for view or for editing. Oh, no, actually I do in a way. I have two "current objects" sitting in the session. One is for viewing, another is for editing. But this is all differentiation I have. * Viewing or editing mode depends just on tags on a particular page. Here is a small example. Say, you making a bill payment. You create a new object, "Bill payment", it status is "new". App opens edit page, where you set all properties, amout, payee. Then you submit the form. "Bill payment" is processed and marked as "payed". Now if you click Back, browser would go to the action that shows "Bill payment" object. This time, because its status has changed to "payed", it is a R/O object, so instead of reloading an edit page, action loads a view page and shows object as R/O with "payed" status. All my pages are non-cachable for that reason. If you have a caching browser, it would display stale "Bill payment" form and object. But object with this ID is already marked as "payed" by application, so when you try to resubmit it, it won't be accepted. No tokens ;-) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
