You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by andyhot <an...@di.uoa.gr> on 2006/11/14 14:02:56 UTC
clientId and FormSupport
Recent updates on clientId generation look quite good so far!
http://issues.apache.org/jira/browse/TAPESTRY-1131
"Hidden Component (maybe all FormComonents?) don't get ids assigned on a
page basis"
still occurs.
It's the case where a page has many forms, and since every form item gets
a name and id that is unique inside each form, we don't yet guarantee that
it is also unique per page (we don't use the page idAllocator)
So, apart from prefixing ids with the form clientId (as i had suggested),
is there any other solution?
Also, i find it odd that each Form creates its own FormSupport
in protected FormSupport newFormSupport(IMarkupWriter writer,
IRequestCycle cycle)
This doesn't allow me to 'inject' a custom FormSupportImpl. I'd prefer
having the
Form delegating the process to a FormSupportFactory service that i can
easily override.
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: clientId and FormSupport
Posted by andyhot <an...@di.uoa.gr>.
i'll go ahead with allowing customization and overriding of FormSupport
it'll be easier to try and test several probable solutions then
Jesse Kuhnert wrote:
> I started implementing a solution for this but reverted it as I felt
> like I
> was attacking too much at once.
>
> If you did something like this it would probably solve the problem:
>
> -) Don't change Form's method of generating unique id. (it already
> uses the
> global IRequestCycle IdAllocator + special logic for portlets.
>
> -) Initialize the FormSupportImpl IdAllocator instance with a namespace
> value of the Form's clientId/name .
>
> -) Create a new reserved hidden input field parameter to store the unique
> form id in so that you can properly initialize the IdAllocator in
> FormSupport during rewind.
>
> -) Your factory idea for FormSupport sounds good to me.
>
> On 11/14/06, andyhot <an...@di.uoa.gr> wrote:
>>
>> Recent updates on clientId generation look quite good so far!
>>
>> http://issues.apache.org/jira/browse/TAPESTRY-1131
>> "Hidden Component (maybe all FormComonents?) don't get ids assigned on a
>> page basis"
>> still occurs.
>>
>> It's the case where a page has many forms, and since every form item
>> gets
>> a name and id that is unique inside each form, we don't yet guarantee
>> that
>> it is also unique per page (we don't use the page idAllocator)
>>
>> So, apart from prefixing ids with the form clientId (as i had
>> suggested),
>> is there any other solution?
>>
>> Also, i find it odd that each Form creates its own FormSupport
>> in protected FormSupport newFormSupport(IMarkupWriter writer,
>> IRequestCycle cycle)
>>
>> This doesn't allow me to 'inject' a custom FormSupportImpl. I'd prefer
>> having the
>> Form delegating the process to a FormSupportFactory service that i can
>> easily override.
>>
>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
>> Tapestry / Tacos developer
>> Open Source / J2EE Consulting
>>
>>
>> ---------------------------------------------------------------------
>> 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://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: clientId and FormSupport
Posted by Jesse Kuhnert <jk...@gmail.com>.
I started implementing a solution for this but reverted it as I felt like I
was attacking too much at once.
If you did something like this it would probably solve the problem:
-) Don't change Form's method of generating unique id. (it already uses the
global IRequestCycle IdAllocator + special logic for portlets.
-) Initialize the FormSupportImpl IdAllocator instance with a namespace
value of the Form's clientId/name .
-) Create a new reserved hidden input field parameter to store the unique
form id in so that you can properly initialize the IdAllocator in
FormSupport during rewind.
-) Your factory idea for FormSupport sounds good to me.
On 11/14/06, andyhot <an...@di.uoa.gr> wrote:
>
> Recent updates on clientId generation look quite good so far!
>
> http://issues.apache.org/jira/browse/TAPESTRY-1131
> "Hidden Component (maybe all FormComonents?) don't get ids assigned on a
> page basis"
> still occurs.
>
> It's the case where a page has many forms, and since every form item gets
> a name and id that is unique inside each form, we don't yet guarantee that
> it is also unique per page (we don't use the page idAllocator)
>
> So, apart from prefixing ids with the form clientId (as i had suggested),
> is there any other solution?
>
> Also, i find it odd that each Form creates its own FormSupport
> in protected FormSupport newFormSupport(IMarkupWriter writer,
> IRequestCycle cycle)
>
> This doesn't allow me to 'inject' a custom FormSupportImpl. I'd prefer
> having the
> Form delegating the process to a FormSupportFactory service that i can
> easily override.
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / J2EE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com