IFormComponent questions

[Martino Piccinato <ma...@gmail.com>]

Is IFormComponent interface intended to be used also for form "chunks"
meaning for components representing certain input fields aggregation?
Imagine we have a ContactForm component used in different pages to gather
phone numbers, emails etc (just simple a simple TextField components
aggregate) using a simple xml component definition and an html template. I
thought the advantage of having it implement IFormComponent would be to
possibly have at the end common validation and access to including form (the
ValidationDelegate etc. etc.) am I right or is IFormComponent just thought

Another thing I don't understand is which method one MUST implement by
extending AbstractFormComponent (which might not be a good idea in my case
because we actually "render" the component with a template): e.g. there are
many abstract methods that are not implemented by TExtField (getForm()) but
still used. I guess AbstractFormComponent are then enhanced at runtime (by
whom?) but sometime is quite difficult to understand what MUST be enhanced
and what not.

All in all: would you consider a general good idea to implement the
IFormComponent interface for all components that are in fact part of a Form?

Re: IFormComponent questions

[Jesse Kuhnert <jk...@gmail.com>]

No ...IFormComponent is only meant to be implemented (generally
speaking) by components that have some sort of direct form input
counterpart in the browser. Ie things that need to get at submitted
form data and do things with it.

On 3/27/07, Martino Piccinato <ma...@gmail.com> wrote:
> Is IFormComponent interface intended to be used also for form "chunks"
> meaning for components representing certain input fields aggregation?
> Imagine we have a ContactForm component used in different pages to gather
> phone numbers, emails etc (just simple a simple TextField components
> aggregate) using a simple xml component definition and an html template. I
> thought the advantage of having it implement IFormComponent would be to
> possibly have at the end common validation and access to including form (the
> ValidationDelegate etc. etc.) am I right or is IFormComponent just thought
>
> Another thing I don't understand is which method one MUST implement by
> extending AbstractFormComponent (which might not be a good idea in my case
> because we actually "render" the component with a template): e.g. there are
> many abstract methods that are not implemented by TExtField (getForm()) but
> still used. I guess AbstractFormComponent are then enhanced at runtime (by
> whom?) but sometime is quite difficult to understand what MUST be enhanced
> and what not.
>
> All in all: would you consider a general good idea to implement the
> IFormComponent interface for all components that are in fact part of a Form?
>


-- 
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org