I'm OK with omitting the context in the component's name if the context
is well-established. This could be achieved by grouping the component
documentation as in T4 - as you suggested.
But I still think that the primary use of a component should be
reflected in its name. We already have BeanEditForm - a form to edit
beans -, RenderObject - a component to render objects - and others where
the main usage is reflected in the component name.
So let us call it ConditionalFragment and somehow make clear that it
belongs to a form.
Uli
Kevin Menard schrieb:
I have to admit, at first I was a fan of Robert's name suggestion. I
tend to prefer clarity to terseness, but Chris has raised some good
points. If the context is well-established, there's no need to
include "form" in the name. This is consistent with other form
components (e.g., we don't have FormTextField).
I think the larger issue is establishing that context. I think T4
has already addressed this by categorizing its components in the
documentation. When I look for a T4 form component, there's no
question where to look because the component reference has a whole
form section. Additionally, there's a whole Ajax section that
explains how to use the Ajax portions of these form components.
Somewhat contradictory, I don't care for the name "Zone", but that's
not relevant to the discussion at hand.
Having said all this, if there's like to be an ontology of different
fragments for different contexts, Tapestry is either going to have to
do the right thing based on context or the name should be more
descriptive.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
