sounds great
ekke
Christian Campo schrieb:
I think having only one class to deal with would be a good
think. I think breaking the API in the timeframe for Riena 1.2. is
something we should either not do or be very cautious.
I agree that everyone would a dialog to have look an feel and V/C
support. So I would rather go down a path where we create a new class
say RienaDialogView and we deprecate existing classes to make clear
which path people should follow.
So I agree with 2., 3. sounds good to me and 4. as well. Still under
that precondition that we dont break API. So I rather not "move" or
"rename" a method but create a new one (that we think has to more
appropriate name) and deprecate the old one.
5. ok
6. I am not sure sure that every Dialog has an OK and Cancel button.
Furthermore I am not sure that you could predict where they are located
on the View. So I would rather step away from that. Its always easy for
people to create a subclass for the View part that creates an OK and
Cancel button.
7. agreed Constructor and setTitle
christian
Am 21.08.2009 um 01:10 schrieb Elias Volanakis:
Here are a couple of ideas and suggestions
that would make RienaDialog
/ DialogView easier to use from my POV (with API changes):
1. RienaDialog should not be API. -- I suggest making it package
public. it only adds look-n-feel support
2. Rename RienaDialog (adds LnF support) to AbstractThemableDialog and
DialogView (adds View/Controller) to RienaDialog -- I can't think why
anybody would not want LnF support and V/C support. That means that
most people would extends DialogView. I thnk renaming it to
RienaDialog would be more intuitive.
3. Deprecate dialogView.build() in favor of dialogView.open() -- this
is the standard call to open a dialog in Eclipse
4. Rename DialogView.buildView() to DialogView.basicCreatePartControl
- this is the method where we create the UI in regular views; more
similar naming
5. buildView() could be abstract, so that there is an obvious hint
that somebody extending DialogView needs to implement this method
(might cause problems with WindowBuilder though...)
6. Create OK and Cancel buttons by default -- currently everybody
extending DialogView has to create his own buttons and buttonRidgets.
This does not make sense to me. We should make the common case easy by
creating Ok, Cancel buttons and invoking addUIControl(...) for them.
This could happen in a protected method so it can be overwritten by
people needing other buttons
7. I could not find an easy way to set the dialog title. If there is
one please let me know -- ideally it should be something like
dialogView.setTitle(...) or maybe even a constructor parameter
Looking forward to your feedback.
Kind regards,
Elias.
--
Elias Volanakis | Technical Lead | EclipseSource Portland
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | http://eclipsesource.com
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf |
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490
|
