Bugzilla – Full Text Bug Listing
| Summary: | [FileDialog] Remove setAutoUpload(boolean) and isAutoUpload public methods | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Ivan Furnadjiev <ivan> |
| Component: | Incubator | Assignee: | Project Inbox <rap.incubator-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | austin.riddle, cole, rsternberg |
| Version: | 1.4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Ivan Furnadjiev
Currently we have two ideas for replacement of these methods: 1. using setData 2. using style flag Both ideas require a new public constant (in FileDialog or somewhere else - RWT for example). What do you think? +1 for using style flag (In reply to comment #1) > 1. using setData The use of setData() seems more compatible with single sourcing, except that if one were using the new flag it would not be, unless a raw string was specified. If a raw string were specified it would not conflict with the SWT version of FileDialog. > 2. using style flag This seems a little more elegant, but the same single sourcing issue here. If one used the constant, it would not be single sourced unless we used a constant already in SWT like SWT.DEFER for the non-autoupload case. If one were to use a raw number instead of the constant, it might be more single source compatible, but could potentially conflict with the consumption of the style bits in the SWT version. As we discussed auto upload to be the default mode in FileDialog, SWT.DEFER style flag for removing the default auto upload mode sounds good to me. Ralf what do you think? I would rather see the setData method because that is guaranteed to not break the SWT implementation. Using a style bit sounds elegant, but many SWT classes check the style bits and complain if they get one they don't understand. Using the setData would be much like custom variants, it would just get ignored by the SWT versions and the RWT ones would know what to do with it. The constant itself can be defined in an appropriate place, and one of the standard methods for dealing with single-sourcing can be used. I have a tendency towards setData(), simply because setData() aligns with how things can be achieved where there is no API for in SWT (e.g. CUSTOM_VARIANT). I agree that the extra style flag is an elegant idea, but I'd prefer to use one pattern consistently wherever we have to extend the SWT API. And since we already started using setData() elsewhere, I'd prefer to continue with this. After all, setData() is flexible enough to cover all future needs (the only issue I have with it is that it's not suitable for settings that must not change after construction). Moreover, some widgets have somewhat magical checkData() code that resets or adds some bits. We probably make our lifes easier if we don't mess around with these constants ;-) Please note that FileDialog is not a widget and there is not setData() method available. As there are no other alternatives, we agreed to leave it as is. I added a warning to the JavaDoc of the non-SWT methods. My preference would still be to make auto-upload the default but that would be the topic of another bug... I also renamed isAutoUpload() to getAutoUpload() in order to align the method to the SWT naming pattern. |