I'm still leaning towards FormFragment rather than just Fragment.
The beauty of Tapestry is that you can "alias" Components by creating
subclasses. So:
package com.myapp.components;
public class Frag extends TapestryConditionalFormFragmentBlockAjaxEnabled
{
}
And now you can say <t:frag> instead of
<t:tapestryconditionalformfragmentblockajaxenabled>.
I see FormFragment as a good compromise.
On Feb 19, 2008 6:09 AM, 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]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
