Thanks for all the suggestions! I've posted an updated version of the code. New features: - If editable properties specified explicitly, keep them in the specified order. - If the component is not in a form, emit an internal form (like before); otherwise, just use the external form. - Added a "delete" button/listener parameter. - Allow users to override the input field used on a property-by-property basis.
See the wiki doc for more info on any of these. The code went from about 300 lines to about 400 lines (almost 100 of this is javadoc though). Anyways, let me know what you think. The only suggestions I've seen so far that I have not been in complete agreement with have been those that would be hard to implement without coming up with an entire rendering hierarchy a la contrib:Table (ie, giving users the flexibility of rendering the BeanForm using something other than an HTML table). Maybe I'm approaching it from the wrong angle, but I just don't see the payoff in allowing people to do that, given the complexity it will add to the code (and the fact that I've never had to use anything but tables for my edit forms ;-). On 5/1/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] wrote: >>From Jesse Kuhnert <[EMAIL PROTECTED]>: > >> I think it sounds like a very cool component, but there are a few things >> that worry me about it; >> >> -) The css styling is a nice touch, but probably isn't going to be enough to >> suit all needs. It would be better if this were more like the table >> component - which allows you to have a suitable default for many instances - >> but is also really a composite of other components underneath so that people >> can override the default styling. > > Agreed. People might not even like to have this rendered as a table. Definitely. If the styling can't be overridden, we'll have problems. > >> -) The fact that it contains a form is probably a big no no. I would specify >> that you "require" people to wrap it with a form, but actually containing >> the form seems very inflexible. (maybe this is along the same lines as the >> point above ?) > > On the other hand, this component is a Form, a BeanForm, so I don't see this > as a problem. What I expect people to ask however is for ways to > override the components that edit each property - perhaps an Autocompleter > or a TextArea instead of a TextField, e.t.c. ... This component is a BeanForm, yes. So - to accomodate the users that want ease of use with form included, have a component that contains a form. For those that need more flexibility, have that lower level component (that's actually used in the component that contains a form) that can be used directly - and if that component is used without any form at all, spit out a message telling the user it needs to be in a form. [that make sense?] <snip> >> On 4/30/06, D&J Gredler <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> I'd appreciate it if some of you guys read over this page and offered up >>> some constructive criticism. The component in question allows you to edit >>> pojo's by writing one line of code and is fairly simple. I'm also >>> interested >>> in getting something like this into the Contrib package. Thoughts? >>> >>> Regards, >>> >>> Daniel Gredler </snip> Can I make a 'joking' vote on inclusion of this in Contrib (on the heels of resolving issue 486)? -1 without that ever important 4th file - the documentation for it. :-D You do know what'll be next, tho'... "I want to embed a BeanForm inside a BeanForm so I can edit my user's address information (which I get with a call to getAddress())". [doable along the same lines, I believe, without embedding, but it's not there now] My .02 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEVav0aCoPKRow/gARAg4fAJ92GfgHl+3bmScyC8WIaFE+mHrYvQCfROih 7vXo1GQdhTyL6YjeICmzW3s= =bsB7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
