Thanks Jesse. I know that I would have more trouble than formatting if I migrate from a web app to a desktop app, but I would like to minimize that effort. However there's a 0.001 probability this app will ever be migrated, I was just asking theoretically. (I could have said Struts instead of Swing for a more real example)
I agree with you that the I should put most of my effort in making core functionality the most separate posible. Something that will probably happen is that after the main development part of the project there will be a long term maintainance stage that I most definetily will not be doing, so I would like that the person that comes after me find the cleanest design posible and that modifications or bug corrections can be done with the minimal effort possible. Thanks again. Marcos On 6/24/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
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
