Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Proposal - code path consistency throughout UI parts

Actually, I was proposing that the inconsistencies be made consistent
through changes in code.  Programmers aren't going to read every document,
just the ones that they think that they need to read.




|---------+--------------------------------->
|         |           Nick_Edgar@xxxxxxx    |
|         |           Sent by:              |
|         |           platform-ui-dev-admin@|
|         |           eclipse.org           |
|         |                                 |
|         |                                 |
|         |           01/07/2002 12:29 PM   |
|         |           Please respond to     |
|         |           platform-ui-dev       |
|         |                                 |
|---------+--------------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                     |
  |       To:       platform-ui-dev@xxxxxxxxxxx                                                                                         |
  |       cc:                                                                                                                           |
  |       Subject:  Re: [platform-ui-dev] Proposal  - code path consistency throughout UI parts                                         |
  |                                                                                                                                     |
  |                                                                                                                                     |
  >-------------------------------------------------------------------------------------------------------------------------------------|



Randy,

I've filed bug 7312 for this, since it's more of a problem with the
existing documentation rather than a new proposal.

Nick





"Randy Hudson" <hudsonr@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/22/01 11:00 AM
Please respond to platform-ui-dev


        To:     platform-ui-dev@xxxxxxxxxxx
        cc:
        Subject:        [platform-ui-dev] Proposal  - code path consistency
throughout UI parts

I'm not comitter, but I'm proprosing the following anyway because I think
it should be proposed.

Throughout many of the UI parts, (EditorParts, ViewParts, and Pages such
as
the OutlinePage), there is an assumed (by me, although sometimes even by
the JavaDOC) sequence of events.  What's worse, is that these assumption
hold true 95% of the time, and developers may not stumble accross the 5%.
For example, I didn't know about most of them until after the WSAD Tech
Preview.

For example, I had assumed the following:

1) When dispose is called on my OutlinePage, the control is still valid.
2) dispose() gets called on my EditorPart some time in the future after
createControl(Composite) is called.
3) setInput() and createControl() are called in succession (meaning
syncronously, such that the two would complete before any asyncronous
things have a chance to run) on my EditorPart when opening a resource.
4) my ViewPart is created and createControl() is eventually called.


For a long time, these assumptions held.  In fact, developers may get
through an entire development cycle without encountering the events that
cause them to fail.  They are:
A) Closing the OutlineView while your Editor is open.
     1) doing this will cause your page's control to get disposed before
the page is disposed.
B) Shutting down eclipse with an open editor in a non-foreground
perspective, and then restarting Eclipse.
     2) createControl will never get called on your EditorPart unless you
bring that background perspective to the front
     3) setInput will get caled on your EditorPart, but its control will
not get created unless you switch to that perspective.
     4) ViewParts behave similar to EditorParts, if they are in the
background, no controls are created.

These inconsistencies caused me problems.  There could be more out there
that others know about.  I think an effort should be made to make the
"chain-of-events" as consistent as possible, especially when the
exceptions
to the rule are difficult to discover.

If my EditorPart is loaded as part of a background perspective, then my
plugin was initialized.  The optimization gains of not creating my
editor's
control are negligible when compared to the average plugin startup time
abd
the hydration of the editor's input.

-Randy

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev





Back to the top