Thanks for the response, and your insight. I think my question is a lot more basic, however.
Simply put: Shouldn't the new objects be able to "speak" with the old objects? And shouldn't the generated forms be able to use the new objects, too? The purpose i see xdoclet having been designed for is for reduction of manual code that's all boilerplate text. And, being able to keep all pertinent information centrally located. It doesn't make sense to go back through and refactor a generated class (ie, the form objects) only to have that code risking being overwritten the next time a generation is done. and, i could subclass the generated form. but, that's still getting away from the basic issue:: one should be able to get a VO from a DO, and a DO from a VO. and the form object should be updated to use a VO. it would be a very simple patch of the templates. but, if there was a strong design reason why this wasn't (or hasn't been) done (or it's already been/being done for v2), then I'd be interested in knowing about it. If it'd be worth my time to patch the template and submit it, I'd be happy to do that, too. -- adam, trying to not step on any toes, just trying to understand ----- Original Message ----- From: "Brian Topping" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 10, 2003 4:09 PM Subject: Re: [Xdoclet-user] ValueObjects, Data Objects and Struts Forms 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 ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
