You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2008/02/18 21:35:32 UTC
Question on naming ...
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.
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Chris Lewis <bu...@gmail.com>.
I couldn't agree more :-).
Francois Armand wrote:
> Hugo Palma wrote:
>> ConditionalFragment maybe ? or a longer ConditionalFormFragment ?
>>
> Add my to cents...
>
> I think there is no use to set "Form" in the name, this component will
> be used _only_ on the context of a form, it would be a kind of
> redondancy, something like the CSS class name for headers / cells in
> grid.
> I'm not sur for "conditional", it's quite long and add almost nothing
> after the first time you would have read the documentation about this
> component. After that, you will know that Fragment is for conditional
> validation/visibility.
> So I would choose "Fragment".
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Francois Armand <fa...@linagora.com>.
Hugo Palma wrote:
> ConditionalFragment maybe ? or a longer ConditionalFormFragment ?
>
Add my to cents...
I think there is no use to set "Form" in the name, this component will
be used _only_ on the context of a form, it would be a kind of
redondancy, something like the CSS class name for headers / cells in grid.
I'm not sur for "conditional", it's quite long and add almost nothing
after the first time you would have read the documentation about this
component. After that, you will know that Fragment is for conditional
validation/visibility.
So I would choose "Fragment".
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Hugo Palma <hu...@gmail.com>.
ConditionalFragment maybe ? or a longer ConditionalFormFragment ?
Robert Zeigler wrote:
> Hm... I would shy away from that one, due to the nuance that "block"
> has in tapestry.
> At least for me, saying "FormBlock" would suggest some piece of a form
> that can be randomly plugged into various other forms... like a bean
> block contribution.
> FormFragment is ok, but I'm with Ulrich that the name ought to suggest
> the conditional nature of the component.
>
> Robert
>
> On Feb 18, 2008, at 2/184:52 PM , Igor Drobiazko wrote:
>
>> FormBlock would be another possibility
>>
>> On Feb 18, 2008 9:35 PM, Howard Lewis Ship <hl...@gmail.com> 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.
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator Apache Tapestry and Apache HiveMind
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Robert Zeigler <ro...@scazdl.org>.
Hm... I would shy away from that one, due to the nuance that "block"
has in tapestry.
At least for me, saying "FormBlock" would suggest some piece of a form
that can be randomly plugged into various other forms... like a bean
block contribution.
FormFragment is ok, but I'm with Ulrich that the name ought to suggest
the conditional nature of the component.
Robert
On Feb 18, 2008, at 2/184:52 PM , Igor Drobiazko wrote:
> FormBlock would be another possibility
>
> On Feb 18, 2008 9:35 PM, Howard Lewis Ship <hl...@gmail.com> 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.
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> Best regards,
>
> Igor Drobiazko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Igor Drobiazko <ig...@gmail.com>.
FormBlock would be another possibility
On Feb 18, 2008 9:35 PM, Howard Lewis Ship <hl...@gmail.com> 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.
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
Re: Question on naming ...
Posted by Howard Lewis Ship <hl...@gmail.com>.
Wait? Tapestry has a steep learning curve? It always seems pretty
natural to me!
:-)
On Feb 18, 2008 3:25 PM, Ulrich Stärk <ul...@spielviel.de> 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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
Zone is different because it's just a content container and is not
connected to any other component. But to emphasize its usage for dynamic
updating I would have called it DynamicZone.
Chris Lewis schrieb:
> I have made my points and have nothing new to add. I am curious however
> to know what you would propose the zone component be renamed to.
>
> Ulrich Stärk wrote:
>> 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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Chris Lewis <bu...@gmail.com>.
I have made my points and have nothing new to add. I am curious however
to know what you would propose the zone component be renamed to.
Ulrich Stärk wrote:
> 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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Howard Lewis Ship <hl...@gmail.com>.
The FormFragment has to take control over the portion of the form it
encloses, because if the content is not visible on the client side
when the form is submitted, no processing (and especially, no
validation) should occur on the server-side.
On Feb 19, 2008 7:56 AM, Andreas Andreou <an...@gmail.com> wrote:
> might be weird, but...
> why is this component needed?
>
> Looks like it is (or could be generalized to be) a special case of
> Zone when inside a form
>
>
> On 2/19/08, Chris Lewis <bu...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
> Tapestry / Tacos developer
> Open Source / JEE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Andreas Andreou <an...@gmail.com>.
might be weird, but...
why is this component needed?
Looks like it is (or could be generalized to be) a special case of
Zone when inside a form
On 2/19/08, Chris Lewis <bu...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <bu...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Chris Lewis <bu...@gmail.com>.
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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
RE: Question on naming ...
Posted by Kevin Menard <km...@servprise.com>.
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:uli@spielviel.de]
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Chris Lewis <bu...@gmail.com>.
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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Chris Lewis <bu...@gmail.com>.
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 <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>>
>
>
>
>
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
I emphasize the usage of Conditional in the component name. In the end
it's the main function of this component to display parts of the form
conditionally, right? FormFragment on the other hand sounds just like
some kind of container for form components to me and without reading the
documentation for it at least I would not be able to deduce its real
purpose.
Uli
Howard Lewis Ship schrieb:
> I like FormFragment.
>
> On Feb 18, 2008 2:07 PM, Ulrich Stärk <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Howard Lewis Ship <hl...@gmail.com>.
I like FormFragment.
On Feb 18, 2008 2:07 PM, Ulrich Stärk <ul...@spielviel.de> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by Ulrich Stärk <ul...@spielviel.de>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Question on naming ...
Posted by D&J Gredler <dj...@gmail.com>.
+1 for FormFragment... more concise than some of the other options, more
descriptive than still other options, and we get a little alliteration to
boot ;-)
On Feb 18, 2008 3:46 PM, Chris Poulsen <ma...@nesluop.dk> wrote:
> 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 ;)
>
> --
> Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Daniel Gredler
http://daniel.gredler.net/
Re: Question on naming ...
Posted by Chris Poulsen <ma...@nesluop.dk>.
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 ;)
--
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org