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]
