Hi Adam, Here's some of my thoughts. They aren't gospel, I could be missing something (standard disclaimer dial set at 11...)
I've recently bumped into a way of doing things that I quite like and will do more of in the future. This is turning the xxForm into a form-specific processor for the Controller. So in addition to holding values for the HTML, I also use it for massaging output to a standardized format. For instance, I have a calculated field for something to do with the service plan that a form is collecting information for. Rather than embody that calculation directly in the Action, I put it in a new method in the Form. Forms are a part of the "C" in MVC, so this isn't really breaking anyone's idea of what the patterns should look like. It also means that I have better encapsulation of what this (little-f) form does. For instance, I have different Forms for different service plans. If I change the service plan, which has somewhat intricate calculations, I change out the Form, but the JSP and the Action talk to the Form in the same way. Taking this one step further, you can extract an interface for this (I call it CartForm), then talk to the form as if it is a Cart. One of the methods in my CartForm is to recalculate the cache of line items, another to get the cache as a Collection. Remember that you are setting the core information that the Cart works from in the Form interfaces, and you have a nice adapter between the user's information and the SKU/LineItem form that works better for processing. Where I am going with this is I've found it more work than it's worth in this case to use XDoclet to generate such a Form. I still use XDoclet for the validator fields generation (and I checked in a change the other day so that the validator page number is now accessible for multipage forms), but the combination of merge files and such necessary to do all this otherwise is more complex than it is to just write the form by hand. Especially because a decent IDE should be able to generate a bean field encapsulations (get/set) for you with a trivial amount of effort. I was very eager to use the Form generator myself some time ago, but found that it wasn't well suited for the way I work, and looking back on it, I can't see a way that it could become powerful enough given my new perspective on using Forms in the first place. hth, -b -----Original Message----- From: Adam [mailto:[EMAIL PROTECTED] Sent: Sunday, March 09, 2003 11:29 PM To: [EMAIL PROTECTED] Subject: *****SPAM***** Re: [Xdoclet-user] ValueObjects, Data Objects and Struts Forms Would this question be better suited on the developer list? (even tho I'm asking as a user). I suppose I could try and modify the templates myself (even thoough they still mostly confuse me), but I was hoping to gain an understanding as to the 'why' or 'oversight' or 'it's coming in v2' before I attempted. thanks much! ----- Original Message ----- From: "Adam" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 07, 2003 3:08 AM Subject: [Xdoclet-user] ValueObjects, Data Objects and Struts Forms Here's yet another question. This is similar to the one brought up in late January, "Re: [Xdoclet-user] Need help with Value Objects and Struts Form Beans" The problem expressed there, and the one I have, is that: -- you can get a Data or a Value object from your base class. (getXXX). -- From the Data object, you can set the fields from another Data object, and you can get() a Value object. -- From the Value object, you can set the fields from another Value object. -- A Form can be created (new Form()) from a Data object. You can set form fields from a Data object. And, you can get a Data object from the form. Because a ValueObject is bound to have more information than a data object (ie, related objects), it makes more sense to carry the Value object within a user session. When prepopulating a form, it's impossible (without going into the generated code and adding your own routines, that is) to set the form fields from a VO, and there's no way to get a Data object from a VO. This requires hand-coding lots of DO.setXXX(vo.getXXX()) calls -- the same boilerplate code already pasted out in the Base object, et al. Is there a design reason why Forms cannot be populated from a Value object? Or why Data objects can't be retrieved from a Value Object? (the latter makes more sense with the understanding that data objects are being phased out). Konstantin suggested using reflection or Jakarta's Sandbox. I think that's overkill when it's just more boilerplate code that's already being pushed out in other objects. Any light would be appreciated! thanks --adam ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
