[
https://issues.apache.org/jira/browse/TRINIDAD-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591435#action_12591435
]
Gerhard Petracek commented on TRINIDAD-1053:
--------------------------------------------
wouldn't it be better to change the whole mechanism?
is there a reason why the page isn't locked directly at the beginning of
submitForm and _autoSubmit?
what's about the possibility to display a blocking div (see lightweight
dialogs).
we could reuse some parts of the existing source code and the div is skinnable.
> page blocking during request processing
> ---------------------------------------
>
> Key: TRINIDAD-1053
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1053
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.8-core, 1.2.8-core
> Reporter: Gerhard Petracek
>
> it is possible to trigger multiple requests.
> there are more affected versions, but different behaviours -> i just describe
> the details of 1.x.8-SNAPSHOT:
> with 1.x.8-SNAPSHOT the situation is a bit better. however, there are still
> several issues.
> these issues occur at least with ie and firefox, however, they behave
> differently.
> ppr request + ppr requests:
> after a ppr request is triggered and during it's server-side execution it is
> possible to trigger (at least) another ppr request (it depends on the
> browser).
> the next ppr request can be triggered before the previous one finished, but
> it gets executed after the previous one was finished.
> ppr request + conventional/"none-ppr" requests:
> a none-ppr request gets executed even though a ppr request is still in
> progress.
> if this is the desired behaviour, there should be at least a web.xml
> parameter for a "strict" mode.
> none-ppr request + none-ppr requests:
> with ie it is possible to trigger requests "concurrently" (concurrent
> execution on the server).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
