i see what you mean Christian. In this design if you have to show a Date, how do you convert it? I mean, if you let Tapestry do date.toString() this will probably show a lot of things you don't want. Do you use a property in the java file where you put something like dateToString(yourDate) that does the parsing? Same question for Double's or things that don't have a "nice" toString.
Thanks for your opinion! On 6/24/07, Christian Dutaret <[EMAIL PROTECTED]> wrote:
Marcos, The concept of a presentation object model has a strong smell of bad design: double hierarchy maintenance and transformation methods from/to both models which are very error-prone. If you forget to assign a field in those transformation methods, you can spend hours searching for the descrepancy between your model data. Reminds me of that bloated DTO concept with the first generation of EJB, or the transformations between business model and ActionForms in Struts 1. Very time-consuming and error-prone, without any added value. How often does your business model changes without affecting the presentation layer? Is it worth all that pain? The business model I work on is a relatively complex model which is designed after the web application requirements. What I do is simply use persistent objects in the presentation layer, and traverse objects through ognl expressions to keep the code as simple as possible. If the model evolves, I have some web non-regression tests that check for the correctness of the ognl expressions. That has worked fine for me so far. In some other situations (say a legacy datawarehouse that is used beyond your application and holds some fancy data), an additional intermiedary model could make more sense. Still, I would try to keep it at the service level, and use the data returned by the service layer in the presentation layer. My 2 cents... Ch.