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. -- Kevin -----Original Message----- From: Ulrich Stärk [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 4:51 AM To: Tapestry development Subject: Re: Question on naming ... Imagine a new user to T5. He (or she) is learning a complete different approach to developing web applications to what he is used to. He already can do many things like writing pages and forms and also knows some of the basic components already. But not all of them because he is still learning. Now he has this requirement that part of the form - say a different billing address for some order - should only be displayed if the user checks a checkbox. He scans through the list of components and sees: - Form: ah yes, I'll need that one... - Fragment: hmm, dunno what this does, doesn't seem to solve my problem - If: exactly what I need, things should only be displayed IF some condition is met - Checkbox: right, user should check that one in order for the fields for the billing address to display And now he goes on developing his form, has to make sure it gets redisplayed whith the correct fields when the checkbox state changes and has a real hard time implementing this requirement - remember he is still new to all this stuff and learning. On the other hand if he had seen ConditionalFormFragment right below Form he might have thought: "Wait. FormFragment might be some part of a form. And that conditional thing might mean it only gets displayed when some kind of condition occurs. I'm gonna check this out." And believe me, the approach I pointed out above is exactly the approach new users will take. I gave a workshop on T4 to 10 postgraduate students - no beginners but they had never been in touch with Tapestry before. They all tried to implement the requirements with the little set of components they knew and if they found no matching one, they scanned the list of components for one that seemed promising. And I bet they will skip Fragment because the name has nothing to do with their requirement. Uli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
