Re: New Tapestry feature suggestion: EditForm generation
Are there still plans to modularize Trails a bit more so that developers who don't have a Trails application can still use some of the components it provides? I remember reading somewhere that this sort of component library approach was being considered, but never saw it come to fruition. On 1/14/07, Kalle Korhonen [EMAIL PROTECTED] wrote: And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy ( e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tapestry feature suggestion: EditForm generation
That was my idea and I haven't really seen any development going on with Trails. I haven't spoken to Chris Nelson in a while (we live in the same city), so he may be really busy with work or something. On 1/15/07, DJ Gredler [EMAIL PROTECTED] wrote: Are there still plans to modularize Trails a bit more so that developers who don't have a Trails application can still use some of the components it provides? I remember reading somewhere that this sort of component library approach was being considered, but never saw it come to fruition. On 1/14/07, Kalle Korhonen [EMAIL PROTECTED] wrote: And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy ( e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tapestry feature suggestion: EditForm generation
My mantra is open source is selfish - so plan yes, but somebody needs to to scratch that itch himself before anything happens. For several months, I've been just a happy user of Trails myself and BeanForm has some answers for a component approach, so I guess the need for changes hasn't become strong enough yet. Kalle On 1/15/07, James Carman [EMAIL PROTECTED] wrote: That was my idea and I haven't really seen any development going on with Trails. I haven't spoken to Chris Nelson in a while (we live in the same city), so he may be really busy with work or something. On 1/15/07, DJ Gredler [EMAIL PROTECTED] wrote: Are there still plans to modularize Trails a bit more so that developers who don't have a Trails application can still use some of the components it provides? I remember reading somewhere that this sort of component library approach was being considered, but never saw it come to fruition. On 1/14/07, Kalle Korhonen [EMAIL PROTECTED] wrote: And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy ( e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Tapestry feature suggestion: EditForm generation
What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy (e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tapestry feature suggestion: EditForm generation
And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy (e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tapestry feature suggestion: EditForm generation
Did you say you were waiting for a 4.1 release? Both 4.1 and 4.1.1 have officially been released already: http://tapestry.apache.org/download.html On 1/14/07, Kalle Korhonen [EMAIL PROTECTED] wrote: And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy (e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Tapestry feature suggestion: EditForm generation
I know.. .and sorry, should have been more clear. I've played with 4.1.1, but decided to wait for 4.1.2 release before I'd even try to do any integration with Trails. Also I was hoping for a Tacos-like async tree implementation that would work with 4.1.2. Kalle On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Did you say you were waiting for a 4.1 release? Both 4.1 and 4.1.1 have officially been released already: http://tapestry.apache.org/download.html On 1/14/07, Kalle Korhonen [EMAIL PROTECTED] wrote: And hopefully nobody's re-inventing the wheel here because Trails has a pretty extensive support even for the not-so-simple cases. I know Howard that you and Chris Nelson have talked a bit, so I hope you take a look at the existing Trails code and steal/borrow from it or ask for changes before you go and write the same for Tap5. I'm also (im)patiently waiting for Tapestry 4.1 release to upgrade Trails to use it and I'd be more than happy to assist in changes to make it easier to support Tap5. Kalle On 1/14/07, Howard Lewis Ship [EMAIL PROTECTED] wrote: BeanForm exists for Tapestry 4, and Tapestry 5 will have some kind of similar support. I've been laying the groundwork for quite a while. On 1/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: Do you mean like http://beanform.sourceforge.net/ ? On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What about adding native Tapestry support for editing (complex) objects? For objects thats don't depend on other objects it would be easy ( e.g. simply generating text fields). For objects that depend on other objects, it could maybe be solved using Annotations? E.g. One object is Car and one is Engine. If you want to edit a car, a dropdown box with Engines would need to be displayed. As Tapestry needs to know which field is the one to display, this could either be done by using the getName() method, getDisplayName() method or by using Annotations e.h. @DisplayEditField. This would massively speed up Tapestry projects, you would then only need a single line in your page files and the rest is done by Tapestry - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
