I've been thinking a bit more about the bean panel, and I'm kind of
stuck. That is, there's too many possibilities!
A simple bean is no problem. I have code in CVS for that now and it
works (with a special case, FieldPanel, which lets you select a subset
of the properties of the bean). The problem starts when you think about
the more complex properties. E.g. a Person object that has an Address as
a property. Usually, you'd want to give the Address its own edit form.
But probably not in the same page as the Person form is (things would
get messy pretty quickly). So, say you'd want to navigate to address
edit from person edit. The current implementation I had was just a bunch
of fields, no form, which has the advantage that you can decide to nest
it in any form you like. Also it had no buttons (cancel, save), just the
fields. Thing is, that we need the form and the buttons if we'd want to
support the object browsing. And if we build that, we are allready
halfway a Trails application.
So, what do you guys think? What direction should the bean panel
experiment head? Who is interested in cooperating, and where should we
put it (in wicket-stuff, so that it can be a seperate full-fledged
project with more people working on it, or in extensions in case we keep
it really simple)?
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
