[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] RE: [Ejbbuilder-developers] Re: [eclipse-dev] TypePage
|
I think this is a great idea (to expose the selection related dialogs from
JDT-UI - and make them extendable).
I'm trying to create a method selection dialog (with workspace scope) and I
found that the IMethod.getParametersTypes (getExceptionTypes and
getReturnType) returns the simple type's name for a SourceMethod and the
fully qualified type's name for a BinaryMethod, is there a simple way to
get the fully qualified type's names in both cases ?
Thanks !
Marius Slavescu
Martin_Aeschlimann
@oti.com To: jdt-ui-dev@xxxxxxxxxxx
Sent by: cc:
jdt-ui-dev-admin@e Subject: Re: [jdt-ui-dev] RE: [Ejbbuilder-developers] Re:
clipse.org [eclipse-dev] TypePage
03/06/2002 09:36
AM
Please respond to
jdt-ui-dev
Hi Joe,
I just removed MGridData and MGridLayout. They were there for a missing
feature of the regular GridData/Layout, which is now not needed anymore.
You can now use the standard GridData/Layout. (In case you are interested
in the details; in a GridData that grabs and spans for more than one
column, you can't specify which column in grabbing). (should be in the
build after 20020305)
TypePage is in fact merging the functionalities UI, validation and element
creation. The reason is simplicity with regard to the plan to make this
API. Implementers are free to override the appropriate methods and for
example separate the type creation. In the current effort to make more
classes API, we will make sure that all 'magic' of the creation code
(formatting, imports organization) can be done by using public API.
The selection dialogs are an interesting point. The dialogs we have
(TreeSelection, ListSelection, TwoPaneSelection) are JDT-UI independent.
They do not belong to the JDT-UI API, but to the desktop. I opened a bug
report: http://dev.eclipse.org/bugs/show_bug.cgi?id=10852.
Martin
|---------+------------------------------->
| | Joseph Fifield |
| | <jfifield@programmer|
| | planet.org> |
| | Sent by: |
| | jdt-ui-dev-admin@ecl|
| | ipse.org |
| | |
| | |
| | 05.03.2002 14:01 |
| | Please respond to |
| | jdt-ui-dev |
| | |
|---------+------------------------------->
>
-----------------------------------------------------------------------------------------------------------------------|
|
|
| To: jdt-ui-dev@xxxxxxxxxxx
|
| cc:
|
| Subject: Re: [jdt-ui-dev] RE: [Ejbbuilder-developers] Re:
[eclipse-dev] TypePage |
>
-----------------------------------------------------------------------------------------------------------------------|
On Mon, 2002-03-04 at 09:47, Martin_Aeschlimann@xxxxxxx wrote:
>
> Hi Mariano,
> note that it's the superclass of TypePage that picks & chooses which UI
> components are visible. So If the modifier section does not make sense in
> your wizard, don't call createModifierControls from createContents. The
> TypePage still contains the model of it, so you can set the modifiers to
> 'public', and this value will be used when creating code.
I currently have this implemented, although I seem to be having some
trouble with the internal layout classes used (MGridLayout?), or
something. After adding some of my own controls, I get an exception when
calling the createSeparator function. Not sure why yet, I haven't looked
into it much.
> If you want to create more than one type (and a one type page wizard
still
> makes sense), can't you just extend the 'createType' method and create
the
> other files in your code? Similar thing have been done in the JUnit test
> case wizard.
This seems a little awkward to me. It doesn't really seem like it's the
wizard page's reponsibility to create the type. Currently we have a
seperate Builder class that is responsible for creating the types, and a
seperate Model, which is passed to the Builder. It seems the current
implementation of TypePage includes everything - the wizard page, the
model, and the builder. I know it would be quite a change from the
current implementation, but I think it would be nicer to pull the pieces
part, which seems like it would lend itself to greater reusability.
Likewise, it would be nice if there were exposed (public) APIs for
creating types that followed the user's preferences (formatting,
comments, etc). Maybe there isn't and I haven't found it yet...?
...rambling on...just tell me when to stop...
I would also love to see things like the "select source folder", "select
package", and "select class" dialogs exposed for reuse (they seem to be
internal now). Are currently any plans for this?
Thanks!
Joe
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
