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.

Reply via email to