Without addressing the specifics of the design issue, whether or not to use POs, our experience here of Tap 4 is that it is highly maintainable. One of the issue affecting maintanability is where things are found. My understanding is that the design choice is between implicit and declared components and that, in larger apps, declared components have greater flexibility and easier maintainability. I am uncertain whether this applies to the paradign usage quoted of an insert of a date. Once again, my understanding is that if there are configurations that may change, for instance parameters and ognl expressions which, after all, can change as they refelct the underlying implementation, it is better to declare in the specification. Adam
On 24/06/07, Marcos Chicote <[EMAIL PROTECTED]> wrote:
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 >
