| Unable to decide wether to show exit confirmation [message #546866] |
Wed, 14 July 2010 13:17  |
Eclipse User |
|
|
|
Originally posted by: Jens.Borrmann.gillardon.de
Hi,
I have a use case in which I want to change the behavior of the exit
confirmation during the lifetime of a session. For this purpuse I have
written my own IExitConfirmation class:
public class ExitConfirmation implements IExitConfirmation {
public String getExitConfirmationText() {
return "MyConfirmationText";
}
public boolean showExitConfirmation() {
return resultOfSomeBooleanExpression();
}
}
Normally the value of showExitConfirmation() is true. In this case (as
one would expect) "MyConfirmationText" is displayed. During the
PROCESS_ACTION phase the return value can change to false, which leads
to a null confirmation text. In DisplayLCA.preserveValues(), which is
called after ANY phase, null is read and preserved. But this new value
of null never finds its way to the front end.
The writing of this value should take place in
DisplayLCA.writeExitConfirmation(). I have copied the interesting part
of this method to ease the discussion.
String exitConfirmation = getExitConfirmation();
IWidgetAdapter adapter = DisplayUtil.getAdapter( display );
Object oldExitConfirmation = adapter.getPreserved(
PROP_EXIT_CONFIRMATION );
boolean hasChanged = exitConfirmation == null
? oldExitConfirmation != null
: !exitConfirmation.equals( oldExitConfirmation );
if( hasChanged ) {
... // handle null value and non-null values
}
Here again the String for the exit confirmation is read. Again null is
returned. Then this value is compared to the last value that was
preserved. Only if these two values differ, the exit confirmation
behavior is altered. Therefore the initial change from null to a
different value can have any effect. Other changes during runtime are
not processed here, unless they take place between
afterPhase(PROCESS_ACTION) and rendering.
A hacker's way for fixing this might include a PhaseListener that does
some magic beforePhase(RENDER). But I am not sure that this is the best
way to go.
Am I doing something wrong or terribly stupid here or is this a bug?
Any ideas?
Regards, Jens
|
|
|
| Re: Unable to decide wether to show exit confirmation [message #546951 is a reply to message #546866] |
Wed, 14 July 2010 17:18  |
 Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Jens,
DisplayLCA.preserveValues() is only called after the READ_DATA phase.
If the condition in showExitConfirmation changes in the PROCESS_ACTION
phase (this is where application code is executed) it should be noticed
and rendered to the client side.
If that is your use case and it doesn't work, you should file a bug,
ideally with some standalone code to reproduce.
HTH
Rüdiger
On 14.07.2010 15:17, Jens Borrmann wrote:
> Hi,
>
> I have a use case in which I want to change the behavior of the exit
> confirmation during the lifetime of a session. For this purpuse I have
> written my own IExitConfirmation class:
>
> public class ExitConfirmation implements IExitConfirmation {
>
> public String getExitConfirmationText() {
> return "MyConfirmationText";
> }
>
> public boolean showExitConfirmation() {
> return resultOfSomeBooleanExpression();
> }
> }
>
> Normally the value of showExitConfirmation() is true. In this case (as
> one would expect) "MyConfirmationText" is displayed. During the
> PROCESS_ACTION phase the return value can change to false, which leads
> to a null confirmation text. In DisplayLCA.preserveValues(), which is
> called after ANY phase, null is read and preserved. But this new value
> of null never finds its way to the front end.
>
> The writing of this value should take place in
> DisplayLCA.writeExitConfirmation(). I have copied the interesting part
> of this method to ease the discussion.
>
> String exitConfirmation = getExitConfirmation();
> IWidgetAdapter adapter = DisplayUtil.getAdapter( display );
> Object oldExitConfirmation = adapter.getPreserved(
> PROP_EXIT_CONFIRMATION );
> boolean hasChanged = exitConfirmation == null
> ? oldExitConfirmation != null
> : !exitConfirmation.equals( oldExitConfirmation );
> if( hasChanged ) {
> ... // handle null value and non-null values
> }
>
>
> Here again the String for the exit confirmation is read. Again null is
> returned. Then this value is compared to the last value that was
> preserved. Only if these two values differ, the exit confirmation
> behavior is altered. Therefore the initial change from null to a
> different value can have any effect. Other changes during runtime are
> not processed here, unless they take place between
> afterPhase(PROCESS_ACTION) and rendering.
>
> A hacker's way for fixing this might include a PhaseListener that does
> some magic beforePhase(RENDER). But I am not sure that this is the best
> way to go.
>
> Am I doing something wrong or terribly stupid here or is this a bug?
>
> Any ideas?
>
> Regards, Jens
--
Rüdiger Herrmann
http://eclipsesource.com
|
|
|
| Re: Unable to decide wether to show exit confirmation [message #547028 is a reply to message #546951] |
Thu, 15 July 2010 05:19 |
| Eclipse User |
|
|
|
Originally posted by: Jens.Borrmann.gillardon.de
Thanks for your help, Rüdiger!
I misinterpreted some of the things I found during debugging. The value
of my condition can change independent from client interaction.
Therefore the value can already be null in the READ_DATA phase when - as
you corrected my perception - preserveValues() is called.
This explains the behaviour I observed. Do you have any spontaneous idea
how to tackle my situation? Or should I consider restructuring my logic
completely.
Regards, Jens
Rüdiger Herrmann schrieb:
> Jens,
>
> DisplayLCA.preserveValues() is only called after the READ_DATA phase.
> If the condition in showExitConfirmation changes in the PROCESS_ACTION
> phase (this is where application code is executed) it should be noticed
> and rendered to the client side.
> If that is your use case and it doesn't work, you should file a bug,
> ideally with some standalone code to reproduce.
>
> HTH
> Rüdiger
>
> On 14.07.2010 15:17, Jens Borrmann wrote:
>> Hi,
>>
>> I have a use case in which I want to change the behavior of the exit
>> confirmation during the lifetime of a session. For this purpuse I have
>> written my own IExitConfirmation class:
>>
>> public class ExitConfirmation implements IExitConfirmation {
>>
>> public String getExitConfirmationText() {
>> return "MyConfirmationText";
>> }
>>
>> public boolean showExitConfirmation() {
>> return resultOfSomeBooleanExpression();
>> }
>> }
>>
>> Normally the value of showExitConfirmation() is true. In this case (as
>> one would expect) "MyConfirmationText" is displayed. During the
>> PROCESS_ACTION phase the return value can change to false, which leads
>> to a null confirmation text. In DisplayLCA.preserveValues(), which is
>> called after ANY phase, null is read and preserved. But this new value
>> of null never finds its way to the front end.
>>
>> The writing of this value should take place in
>> DisplayLCA.writeExitConfirmation(). I have copied the interesting part
>> of this method to ease the discussion.
>>
>> String exitConfirmation = getExitConfirmation();
>> IWidgetAdapter adapter = DisplayUtil.getAdapter( display );
>> Object oldExitConfirmation = adapter.getPreserved(
>> PROP_EXIT_CONFIRMATION );
>> boolean hasChanged = exitConfirmation == null
>> ? oldExitConfirmation != null
>> : !exitConfirmation.equals( oldExitConfirmation );
>> if( hasChanged ) {
>> ... // handle null value and non-null values
>> }
>>
>>
>> Here again the String for the exit confirmation is read. Again null is
>> returned. Then this value is compared to the last value that was
>> preserved. Only if these two values differ, the exit confirmation
>> behavior is altered. Therefore the initial change from null to a
>> different value can have any effect. Other changes during runtime are
>> not processed here, unless they take place between
>> afterPhase(PROCESS_ACTION) and rendering.
>>
>> A hacker's way for fixing this might include a PhaseListener that does
>> some magic beforePhase(RENDER). But I am not sure that this is the best
>> way to go.
>>
>> Am I doing something wrong or terribly stupid here or is this a bug?
>>
>> Any ideas?
>>
>> Regards, Jens
>
>
|
|
|
| Re: Unable to decide wether to show exit confirmation [message #547172 is a reply to message #547028] |
Thu, 15 July 2010 19:17 |
Rüdiger Herrmann
Messages: 581
Registered: July 2009 |
Senior Member |
|
|
Jens,
though not stated explicitly, the ExitConfirmation is part of the UI and
the condition is expected to only change while the UI thread is running
(within a request).
In your case, you could wrap your login to a Runnable and pass it to
Display#asyncExec(). This way it will be executed during PROCESS_ACTION.
HTH
Rüdiger
On 15.07.2010 07:19, Jens Borrmann wrote:
>
> Thanks for your help, Rüdiger!
>
> I misinterpreted some of the things I found during debugging. The value
> of my condition can change independent from client interaction.
> Therefore the value can already be null in the READ_DATA phase when - as
> you corrected my perception - preserveValues() is called.
>
> This explains the behaviour I observed. Do you have any spontaneous idea
> how to tackle my situation? Or should I consider restructuring my logic
> completely.
>
> Regards, Jens
>
> Rüdiger Herrmann schrieb:
>> Jens,
>>
>> DisplayLCA.preserveValues() is only called after the READ_DATA phase.
>> If the condition in showExitConfirmation changes in the PROCESS_ACTION
>> phase (this is where application code is executed) it should be
>> noticed and rendered to the client side.
>> If that is your use case and it doesn't work, you should file a bug,
>> ideally with some standalone code to reproduce.
>>
>> HTH
>> Rüdiger
>>
>> On 14.07.2010 15:17, Jens Borrmann wrote:
>>> Hi,
>>>
>>> I have a use case in which I want to change the behavior of the exit
>>> confirmation during the lifetime of a session. For this purpuse I have
>>> written my own IExitConfirmation class:
>>>
>>> public class ExitConfirmation implements IExitConfirmation {
>>>
>>> public String getExitConfirmationText() {
>>> return "MyConfirmationText";
>>> }
>>>
>>> public boolean showExitConfirmation() {
>>> return resultOfSomeBooleanExpression();
>>> }
>>> }
>>>
>>> Normally the value of showExitConfirmation() is true. In this case (as
>>> one would expect) "MyConfirmationText" is displayed. During the
>>> PROCESS_ACTION phase the return value can change to false, which leads
>>> to a null confirmation text. In DisplayLCA.preserveValues(), which is
>>> called after ANY phase, null is read and preserved. But this new value
>>> of null never finds its way to the front end.
>>>
>>> The writing of this value should take place in
>>> DisplayLCA.writeExitConfirmation(). I have copied the interesting part
>>> of this method to ease the discussion.
>>>
>>> String exitConfirmation = getExitConfirmation();
>>> IWidgetAdapter adapter = DisplayUtil.getAdapter( display );
>>> Object oldExitConfirmation = adapter.getPreserved(
>>> PROP_EXIT_CONFIRMATION );
>>> boolean hasChanged = exitConfirmation == null
>>> ? oldExitConfirmation != null
>>> : !exitConfirmation.equals( oldExitConfirmation );
>>> if( hasChanged ) {
>>> ... // handle null value and non-null values
>>> }
>>>
>>>
>>> Here again the String for the exit confirmation is read. Again null is
>>> returned. Then this value is compared to the last value that was
>>> preserved. Only if these two values differ, the exit confirmation
>>> behavior is altered. Therefore the initial change from null to a
>>> different value can have any effect. Other changes during runtime are
>>> not processed here, unless they take place between
>>> afterPhase(PROCESS_ACTION) and rendering.
>>>
>>> A hacker's way for fixing this might include a PhaseListener that does
>>> some magic beforePhase(RENDER). But I am not sure that this is the best
>>> way to go.
>>>
>>> Am I doing something wrong or terribly stupid here or is this a bug?
>>>
>>> Any ideas?
>>>
>>> Regards, Jens
>>
>>
--
Rüdiger Herrmann
http://eclipsesource.com
|
|
|
Powered by
FUDForum. Page generated in 0.02803 seconds
] 
Search
Help
Register
Login
Home
