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
Chris Lewis schrieb:
If you can find one person who claims that the names of the components
had anything to do with their troubles in picking up T4, I will be
extremely surprised. Whenever a person engages in _any_ activity, a
certain vocabulary is used that isn't normally used elsewhere. The whole
idea of a component driven framework is a departure from conventional
thought that goes in to developing web applications, even if the method
has been around for a few years now. On top of that, some of the
requirements for building T4 apps are inarguably weird at first glance
(abstract methods for properties, etc). No matter what a component is
named, the pains of picking up a new toolkit are not going to go away.
It's still required to understand ioc, how T5 ioc backs the framework,
pages, templates, components, mixins, and how they all fit together.
Component naming won't change any of that. What I am saying is that this:
<t:form>
...
...
<t:conditionalformfragment>
...
...
</t:conditionalformfragment>
</t:form>
Is not even the slightest bit more clear to me than:
<t:form>
...
...
<t:fragment>
...
...
</t:fragment>
</t:form>
It's a fragment in a form - I know what it does.
Ulrich Stärk wrote:
According to Howard's presentations and statements, overcoming the
steep learning curve of T4 and other frameworks is one of the goals of
T5. Using component names that can only be understood if you know the
specific vocabulary and context in which those components are used
don't really contribute to that goal...
Uli
Chris Lewis schrieb:
Adding my 2 cents, I'd take a bolder stand in the name of terseness
and just call it Fragment. The java community has a historical
obsession with stuffing as much as possible into everything. Package
names, class names, variable names, you name it.
I agree with Ulrich that it's important to know off hand what
something is, or at least have a moderately-less-than-vague idea
about it. However I don't believe that this necessitates painful
names. If "Fragment" is used in only one context - a Form - then
simply seeing a <t:fragment>... or a <div t:type="fragment">... will
be sufficient to know that it is a container for a partial form, and
we can intuit its workings accordingly. The "Zone" component, while
sounding a tad weird at first, is a good example of this. We know
what a zone is because it has one context: a visual piece of a page
that is (re)rendered via Ajax. It could have been more descriptively
named AjaxPageZone or AjaxPageFragment, but we easily added "Zone" to
our vocabulary because of its specific contextual use. I propose the
same astuteness be applied for this component as well.
sincerely,
chris
Howard Lewis Ship wrote:
I like FormFragment.
On Feb 18, 2008 2:07 PM, Ulrich Stärk <[EMAIL PROTECTED]> wrote:
Chris Poulsen schrieb:
Hi,
Howard Lewis Ship wrote:
I've been continuing to work on Ajax/Form functionality.
Last couple of days has been on a component I'm calling a SubForm.
A SubForm is part of a Form that is conditionally visible.
It is always rendered, but a trigger (typically a checkbox) makes it
visible or hidden.
Form controls on the client side are only validated if visible.
Actually, "deep visible", meaning that they are visible and that
their
containers are recursively visible.
On submission, a hidden field for each SubForm tracks its deep
visibility.
On the server side, the form submission for components enclosed
by the
SubForm only occurs when the SubForm is visible on the client side.
If the SubForm is invisible, then no form processing for those
components occur.
It's all working pretty nicely, but I'm not sure "SubForm" is the
right name.
Other idea:
- Section
- FormSection
- FormConditional
- ???
I'll be committing changes later this afternoon so nows a great time
to get the naming right.
FormFragment ?
I'm looking forward to playing with the changes regardless of what
you
decide to call it ;)
I'd give it a meaningful and still natural sounding name. It's a bit
longer but I think "ConditionalForm(Section|Part|Fragment)" would
be ideal.
Uli
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
