I think you're going to have a lot more trouble with migration from a web application to a desktop application than just formatting....
I'd focus on making your core functionality separate enough as standalone services and use that as the basis for migrate-able code and not focus in on making your presentation code multi purposed. The two technologies are completely different and have completely different UI design/interaction strategies to contend with. Use each technology to its fullest potential and you'll have a better application in the long run. (assuming making the best experience for your application users that you possibly can is your end goal) On 6/24/07, Marcos Chicote <[EMAIL PROTECTED]> wrote:
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] > >
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
