Bug 205194 - [ErrorHandling] [StatusHandling] StatusAdapter needs Action and Explanation constants
Summary: [ErrorHandling] [StatusHandling] StatusAdapter needs Action and Explanation c...
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.3   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Szymon Brandys CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks: 179373 204106
  Show dependency tree
 
Reported: 2007-10-02 11:07 EDT by Krzysztof Daniel CLA
Modified: 2008-02-07 05:41 EST (History)
1 user (show)

See Also:
Szymon.Brandys: review+


Attachments
Patch adding described elements (2.29 KB, patch)
2007-10-02 11:07 EDT, Krzysztof Daniel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Krzysztof Daniel CLA 2007-10-02 11:07:18 EDT
Created attachment 79551 [details]
Patch adding described elements

Build ID: I20070621-1340

Steps To Reproduce:
Due to current direction of StatusHandling additional predefined properties are required in StatusAdapter:
suggestedAction and explanation. 
Also timeStamp should be added by default when the StatusAdapter is created.


More information:
Comment 1 Szymon Brandys CLA 2007-10-15 07:52:45 EDT
The patch released to HEAD with small modifications. 

I'm not sure if it is necessary to set the timestamp in the constructor. If it is really necessary, we can consider to raise a bug against that.
Comment 2 Krzysztof Daniel CLA 2007-10-15 08:04:58 EDT
I think we should add timestamp, although it may be other location.

Someone may want to display statues in chronological order and we cannot rely on developers.
Comment 3 Szymon Brandys CLA 2007-10-15 08:47:26 EDT
(In reply to comment #2)
> I think we should add timestamp, although it may be other location.
> 
> Someone may want to display statues in chronological order and we cannot rely
> on developers.
> 

Of course. I've just denied doing that in the constructor. I think that the status  handler and its handle(...) method is a better place.