The FormFragment has to take control over the portion of the form it encloses, because if the content is not visible on the client side when the form is submitted, no processing (and especially, no validation) should occur on the server-side.
On Feb 19, 2008 7:56 AM, Andreas Andreou <[EMAIL PROTECTED]> wrote: > might be weird, but... > why is this component needed? > > Looks like it is (or could be generalized to be) a special case of > Zone when inside a form > > > On 2/19/08, Chris Lewis <[EMAIL PROTECTED]> wrote: > > I agree with you, I simply disagree on the conclusion that functional > > clarity necessitates such a name. As such, I maintain my personal > > preference of "fragment." Long live discussion and dissension! > > > > Ulrich Stärk wrote: > > > 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] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr > Tapestry / Tacos developer > Open Source / JEE Consulting > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
