You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Byrne, Steven" <SB...@dorado.com> on 2003/11/15 19:44:43 UTC
Dealing with dynamic *client-side-created* content
I'm wondering how Tapestry can deal with content that's dynamically
created on the client side vs. the rewind mechanism.
Details: In our application, in order to have an extremely responsive
user interface, we avoid round trips as elements on the UI change, and
use JavaScript to dynamically manipulate the browser's DOM model and to
create and delete nodes within it. The concern I have is that when
control returns to the server side, Tapestry will have no idea what
kinds of form elements will be submitted, and so the rewind mechanism
will be totally lost trying to interpret the incoming request.
Is my assessment correct? Are my concerns justified?
Is there a way I can interpose early in the incoming request processing,
look for some hidden parameter that succinctly describes the final
configuration of the UI, poke some server side to set things up as if
the final UI configuration at submit time was what Tapestry would have
sent, and then run the rewind mechanism as normal? Is there a better
way to handle this situation?
Steve
Re: Dealing with dynamic *client-side-created* content
Posted by Harish Krishnaswamy <hk...@comcast.net>.
A slight correction in your understanding - Tapestry does not care about widgets not rendered by it.
So the dynamically generated widgets will simply be ignored by Tapestry.
-Harish
Harish Krishnaswamy wrote:
> Your assessment is correct.
>
> This is what I have done.
>
> Have Tapestry render a Hidden component and build the data on the client
> slide from the dynamically generated widgets into this Hidden component.
> When the form is submitted, in the setter of the Hidden component, parse
> the data and build the appropriate objects, simple. Now the form
> listener can simply act upon the objects the way it should.
>
> To make it more clean, you can wrap the Hidden component in a custom
> component that can encode the values into the hidden field from the
> objects and decode the values back from the hidden field into the objects.
>
> -Harish
>
>
> Byrne, Steven wrote:
>
>> I'm wondering how Tapestry can deal with content that's dynamically
>> created on the client side vs. the rewind mechanism.
>>
>> Details: In our application, in order to have an extremely responsive
>> user interface, we avoid round trips as elements on the UI change, and
>> use JavaScript to dynamically manipulate the browser's DOM model and
>> to create and delete nodes within it. The concern I have is that when
>> control returns to the server side, Tapestry will have no idea what
>> kinds of form elements will be submitted, and so the rewind mechanism
>> will be totally lost trying to interpret the incoming request.
>>
>> Is my assessment correct? Are my concerns justified?
>>
>> Is there a way I can interpose early in the incoming request
>> processing, look for some hidden parameter that succinctly describes
>> the final configuration of the UI, poke some server side to set things
>> up as if the final UI configuration at submit time was what Tapestry
>> would have sent, and then run the rewind mechanism as normal? Is
>> there a better way to handle this situation?
>>
>> Steve
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dealing with dynamic *client-side-created* content
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Your assessment is correct.
This is what I have done.
Have Tapestry render a Hidden component and build the data on the client slide from the dynamically
generated widgets into this Hidden component. When the form is submitted, in the setter of the
Hidden component, parse the data and build the appropriate objects, simple. Now the form listener
can simply act upon the objects the way it should.
To make it more clean, you can wrap the Hidden component in a custom component that can encode the
values into the hidden field from the objects and decode the values back from the hidden field into
the objects.
-Harish
Byrne, Steven wrote:
> I'm wondering how Tapestry can deal with content that's dynamically
> created on the client side vs. the rewind mechanism.
>
> Details: In our application, in order to have an extremely responsive
> user interface, we avoid round trips as elements on the UI change,
> and use JavaScript to dynamically manipulate the browser's DOM model and
> to create and delete nodes within it. The concern I have is that when
> control returns to the server side, Tapestry will have no idea what
> kinds of form elements will be submitted, and so the rewind mechanism
> will be totally lost trying to interpret the incoming request.
>
> Is my assessment correct? Are my concerns justified?
>
> Is there a way I can interpose early in the incoming request processing,
> look for some hidden parameter that succinctly describes the final
> configuration of the UI, poke some server side to set things up as if
> the final UI configuration at submit time was what Tapestry would have
> sent, and then run the rewind mechanism as normal? Is there a better
> way to handle this situation?
>
> Steve
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org