I think the basic pieces of BeanEditForm could be reused to build a component such as the one you describe. The BeanEditForm is not intended as the be-all and end-all of user input; it's supposed to supply useful scaffolding at the beginning of a project and, for critical forms with complex layouts, be replaced by a custom set of components. What I wouldn't want to do is make it address edge cases, such as this specific ordering issue, at the expense of making it useful for beginners, or as a quick placeholder in a rapidly developed application. For instance, I wouldn't want there to be some kind of BeanEditLayoutModel that would have to be supplied to the BeanEditor (inside the BeanEditForm), unless that could be created easily and have a good default.
What could be changed would be to have the PropertyEditor component fire an event before and after each property it renders; this would give your code the ability to hook in and decorate before and after the property editor markup is generated. On Mon, Jul 21, 2008 at 7:28 AM, Michael Capper <[EMAIL PROTECTED]> wrote: > > Thanks Howard, > pity though. > > > *some rambling:* > I didn't have enough time to dig into the > BeanEditForm/BeanEditor/PropertyEditor thing far enough to unearth the > workings of the <parameter ..> thing, otherwise i'd like to have tried > overriding the usual parameter with my own parameter so it could take > another attribute besides 'name', maybe something like a voluntary boolean > 'startgroup' or 'endgroup', and if one of these is set, the PropertyEditor > would not be passed the overrides any further but would render normally > instead and add a <t:body> before or after its rendering. > > Anyway, i wanted to group a few fields in the form. > Well, i würgedaround the issue by adding some null-fields to the BeanModel, > reorder them to fit (startgroup1, field1_1, field1_2, endgroup1, > startgroup2,...) and supply those with some appropriate rendering to at > least make it look as if the fields were thematically grouped. Unfortunately > this produced a lot of boilerplate-code to define all these parameters > again, which could not be lessend by a t:loop around the parameters ;) > > Till next time, > Michael > > > Howard Lewis Ship wrote: >> >> You might be able to accomplish this using a local property override >> and a PropertyEditor component to "drag in" the default property >> editor block >> >> On Wed, Jul 16, 2008 at 4:02 AM, Michael Capper <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> i want like >>> >>> <t:BeanEditForm....> >>> <t:parameter name="firstgroupitem"> >>> <hr/> >>> <t:body/> >>> </t:parameter> >>> ... >>> </t:BeanEditForm> >>> >>> Consider the <t:body/> as a placeholder >> >> > > -- > View this message in context: > http://www.nabble.com/-T5--BeanEditForm-how-to-add-to-%28decorate%29-the-default-renderer-of-a-field--tp18485061p18569801.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
