Re: Design question
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. -
Re: Design question
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. 2007/6/23, Marcos Chicote [EMAIL PROTECTED]: Thanks Ulrich! I was also considering that. Whath do you think about BO in the presentation layer? I think the correct solution would be to use Presentation Object and do the getDepartamentChief().getName() there. I believe POs should not know about the presentation layer, so my solution would be to use departament.chiefin the Insert componente, but Departamente property in Tapestry's java would actually be something of class DepartamentePO and when I create the PO I do the getDepartamentChief().getName(). What do you think about that? Thanks! On 6/23/07, Ulrich Stärk [EMAIL PROTECTED] wrote: Marcos, You should also consider that when traversing the object tree with ognl you might run into runtime exceptions when you change for example the name of a getter and forgot to adjust your ognl expression. If you did that navigation in the page class the compiler would warn you of a non-existing getter at compile time. On the other hand doing it with an ognl expression right in your html template or page specification will save you some writing. Uli Marcos Chicote schrieb: Thanks Marcus! I know Tapestry will implement the method for me, and that both ways work. The question is which of those would you use? Is anyone better from a design point of view than the otherone? Are they the same? The problem is that if, for example, some day Users BO is no longer of use, and the class is deleted, compilation problems would show in the .java (if we are using alternative 2) and it would be simpler to correct, but nothing would show the problem if alternative 1 is used. On 6/23/07, Marcus [EMAIL PROTECTED] wrote: http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html or http://tapestry.apache.org/tapestry4 in menu Fremawork - Components - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question
Hello, Christian Dutaret a écrit : ... I have some web non-regression tests that check for the correctness of the ognl expressions. That has worked fine for me so far. Please, can you tell us how do you implement web non-regression tests ? Which tools ? Which methods ? Thanks a lot cyrille - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question
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.
Re: Design question
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]
Re: Design question
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]
Re: Design question
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
Re: Design question
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
Re: Design question
Thanks Marcus! I know Tapestry will implement the method for me, and that both ways work. The question is which of those would you use? Is anyone better from a design point of view than the otherone? Are they the same? The problem is that if, for example, some day Users BO is no longer of use, and the class is deleted, compilation problems would show in the .java (if we are using alternative 2) and it would be simpler to correct, but nothing would show the problem if alternative 1 is used. On 6/23/07, Marcus [EMAIL PROTECTED] wrote: http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html or http://tapestry.apache.org/tapestry4 in menu Fremawork - Components
Re: Design question
http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html or http://tapestry.apache.org/tapestry4 in menu Fremawork - Components
Re: Design question
Hi Marcos, In template Html: span jwcid=@Insert value=ognl:departamente.chief.name/ in Java class: public abstract Department getDepartment(); Tapestry will implement this method for you. Marcus
Re: Design question
Marcos, You should also consider that when traversing the object tree with ognl you might run into runtime exceptions when you change for example the name of a getter and forgot to adjust your ognl expression. If you did that navigation in the page class the compiler would warn you of a non-existing getter at compile time. On the other hand doing it with an ognl expression right in your html template or page specification will save you some writing. Uli Marcos Chicote schrieb: Thanks Marcus! I know Tapestry will implement the method for me, and that both ways work. The question is which of those would you use? Is anyone better from a design point of view than the otherone? Are they the same? The problem is that if, for example, some day Users BO is no longer of use, and the class is deleted, compilation problems would show in the .java (if we are using alternative 2) and it would be simpler to correct, but nothing would show the problem if alternative 1 is used. On 6/23/07, Marcus [EMAIL PROTECTED] wrote: http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html or http://tapestry.apache.org/tapestry4 in menu Fremawork - Components - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question
Thanks Ulrich! I was also considering that. Whath do you think about BO in the presentation layer? I think the correct solution would be to use Presentation Object and do the getDepartamentChief().getName() there. I believe POs should not know about the presentation layer, so my solution would be to use departament.chief in the Insert componente, but Departamente property in Tapestry's java would actually be something of class DepartamentePO and when I create the PO I do the getDepartamentChief().getName(). What do you think about that? Thanks! On 6/23/07, Ulrich Stärk [EMAIL PROTECTED] wrote: Marcos, You should also consider that when traversing the object tree with ognl you might run into runtime exceptions when you change for example the name of a getter and forgot to adjust your ognl expression. If you did that navigation in the page class the compiler would warn you of a non-existing getter at compile time. On the other hand doing it with an ognl expression right in your html template or page specification will save you some writing. Uli Marcos Chicote schrieb: Thanks Marcus! I know Tapestry will implement the method for me, and that both ways work. The question is which of those would you use? Is anyone better from a design point of view than the otherone? Are they the same? The problem is that if, for example, some day Users BO is no longer of use, and the class is deleted, compilation problems would show in the .java (if we are using alternative 2) and it would be simpler to correct, but nothing would show the problem if alternative 1 is used. On 6/23/07, Marcus [EMAIL PROTECTED] wrote: http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html or http://tapestry.apache.org/tapestry4 in menu Fremawork - Components - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
