But doesn't that reduce code resusability? I mean if tomorrow I have to migrate the app to Swing, i have to reformat everything.
On 6/24/07, Ulrich Stärk <[EMAIL PROTECTED]> wrote:
Use the format parameter of the insert component. You can supply an insert component that displays a Date object with a custom java.text.DateFormat to display the date the way you want. Uli Marcos Chicote schrieb: > 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. >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
