>From: Vic C <[EMAIL PROTECTED]> === >>From: Toby Steel <[EMAIL PROTECTED]> >> The form bean holds a data value object(DVO) >> <html:text name="myBean" property="dvo.myTextField"/>
>The point of MVC is to "hide" the implementation of the model. The >presentation view should know nothing about how the form bean is >implemented. So maybe a simpler getter. What was the purpose in hiding the implementation of the model from the JSP? If one desired, one can still duplicate all dvo methods in the form bean and just have them access the wrapped dvo. I wanted to avoid this, so I have to allow the JSP to access the dvo directly. >> Any field that does require validating input has a data holder object. >> These holder objects all take string input and have a validate method called >> within the form bean validate method. >Do you do client side validation using the Struts validator frame work >and regular expersions? Or Server side still using struts-validator.xml? >With the simpler getter, Struts could do validation for you. We tried this for a while but the amount of maintenance of the validation xml was too much we felt. Also, we do not need browser validation, so having traditional form bean validation was easiest to deal with. Struts validation might be a refactoring task in the future. It's on the table.... >> The form bean's getDvo() method populates the DVO from the holder objects >> while setDvo() sets the holder objects from the DVO. >Again very similar at this higher level. I have a populate method that >asks DAO to retrieve. You hava a getDVO that : >-(OK here we differ:) >holder beans that get data from EJBs, and deal with multi rows master >detail CRUD and multi row validation? We only use the holder beans as intermediary between form input and DVO. They delay from the time populate() is called on the form bean to when validate() is. Only then may the DVO throw its exceptions and only there may typecasting fail. Multirows and other data access issues are dealt with as the object model dictates. >> we can add to our data model without doing >> anything other than adding to the CMP mapping >CMP is yet another bean that maybe could be eliminated. >Would you do CMP again? If I had a robust and efficient persistence layer, I would use that. Maybe Castor? TopLink? Cocobase? >I like SQL better than EQL. Sure, but EJB-QL is sufficient to load/store DVOs. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
