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]
