Yeah, I think it's a good idea to keep the BeanForm as simple as possible and let people with specific needs (me) subclass it to add new features.
I also think you should remove the Form parameters and leave it to the user to enclose the component with a Form. Or at least break out the editor part into a "BeanEditor" component. The BeanForm would then include a BeanEditor and a few buttons and people who want to use it in an existing form would just use the BeanEditor directly instead. Martin On Thu, 14 Sep 2006 04:16:05 +0200, D&J Gredler <[EMAIL PROTECTED]> wrote: > I think the "exclude" parameter sounds like a good idea, it would probably > be very useful for prototyping or admin screens where you're more worried > about your time than property display order. > > The edit vs view toggle I'm not so sure about, mainly because I want to make > sure the component stays relatively lean and the API doesn't get too > cluttered. For example, a user recently requested a way to make all > read-only properties use an Insert component, rather than the current > behavior of disabling the input component they receive. In the end, rather > than add a new parameter to BeanForm, I decided to make it easier to > override the input component used for specific properties, and to make the > Insert component one of the options. It's a little harder for his specific > needs, as he has to list his bean properties and assign Insert components to > the read-only properties, but it's a generic solution that's "easy enough" > for him and doesn't force other people to learn another corner case when > they're first grokking the BeanForm API. Of course, I may be underestimating > the usefulness of this feature, in which case it's not a "corner case" at > all :-) > > My gut reaction is that the generic solution described above is also "good > enough" for edit vs view toggling. You would have to list the properties to > display, but you could say: > > <span jwcid="@bf:BeanForm" ... > properties="literal:name=Insert,description=Insert,comment=Insert,dateCreated=Insert" > ... /> > > In the same vein I can see the title feature being useful, but I would want > to make it optional, which means Yet Another Parameter (YAP?). Of course, a > more generic solution would be to allow the user to dynamically contribute > bindings to some or all of the property input components. Now *that* would > float my boat. But how? > > Anyway, those are my [longish] thoughts. Feel free to disagree. > > Daniel > > > PS - Martin, would you have time to send me a patch implementing the > "exclude" parameter? ;-) If not, I'll probably look at it eventually. > > > On 9/14/06, andyhot <[EMAIL PROTECTED]> wrote: >> >> Martin Strand wrote: >> > Thanks. >> > I just added a few minor things, nothing big: >> > - "exclude" parameter to exclude properties rather than specifying >> > which ones should be included >> > - toggle between "edit" mode and "view" mode (view mode = no form >> > components) >> Both look useful. Perhaps they could get included? >> >> >> --------------------------------------------------------------------- >> 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]
