Comments inline. On 5/1/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
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.
I like the way the Table component allows you to specify a Block component that will override a column based on a naming convention (ie, XyzColumnValue). I think we might be able to do the same thing at the BeanForm row (or cell) level. It would be a little harder though, since the Table blocks are only used to render HTML, while the BeanForm blocks would have to render HTML and also pull input values out of the submitted HTML. However, I'm not sure where there is room for additional components. Can you list a couple of examples so that I can get a better idea? -) 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 ?)
I can see this both ways. In the simplest case, it's nice to just have the one line of code. On the other hand, as you mention, you're giving up flexibility. Also, you have to duplicate Form parameters and pass them on into the internal Form. I guess the most complex case internally, but easiest to use externally, would be to make the external Form component optional, use it if it's there, and revert to an internal Form component if the BeanForm component is not inside an external Form component (is that even possible?). It would still be nice to see things like tapernate eventually plug into
hibernate's meta data to provide auto-validation setup for some of these things as well.
Yep, I was just trying to stay one level of abstraction lower and create something that might be useful to people that use Tapestry without Trails/Tapernate, and that might be useful to the people behind Trails/Tapernate so that they can do their magic with less code. Overall it sounds like the start of something good, but could also quickly
become very unruly if not treated very delicately. (From the component writers perspective.) It just suffers from a popularity problem perhaps. It's something that's likely to sound immediately appealing to a lot of people, so if it's not entirely well thought out and able to be inuitively used by the majority of people it's going to be an eyesore and source of frustration.
Good point.