Eclipse Community Forums: Visual Editor (VE) » Extending VE

Help

Home

Home » Archived » Visual Editor (VE) » Extending VE - modify the way the root is generated

Show: Today's Messages :: Show Polls :: Message Navigator

Extending VE - modify the way the root is generated [message #106345]

Tue, 13 September 2005 11:43

Eclipse User

Originally posted by: Karsten.Meier.gmx.org

Hi,

thats just another try to get an answer.

First what I want to achieve:

(Platform: Ecipse 3.0.*; VE 3.0.*)

I need a way to get the VE to generate/decode code for JFace/SWT in a
special extended Java Version. One key "feature" for that is to
generate a different class header. For Example a dialog to edit
Addresses has to look like that (note the special keywords):

public team class AddressEditTeam {

public class AddressEditDialog played by Address {
/* ... */
}

}

Except the "played by" part, AddressEditDialog will look mostly like
Dialogs generated for SWT (at least for a first approach)

The AST ist also extended to represent such structures. So I think the
main problem is the question in how i can write a plugin that provides
something to translate the AST to the VE Modell.

I already read the tutorial to extend the palette - very helpful, but
its "problems" start after my problem is solved. I also read through
the report about the ULC extension and found some helpful graphs
(chapter 3: "VE Architecture"; chapter 3.6: "Code Generation and
Parsing").

But I miss the "how to" to do that!

First I tried to contribute to the extension point "newStyleComponent"
and got so far, that my "Style" ist listed in the "new Visual Class"
Wizard. Also I wrote a javajet for that and it worked "almost": all
the special keywords are ignored. Debugging shows, that my contributor
does generate the correct code, but some mechanisms seems to post
modfy it. The example from above will result in:

public class AddressEditTeam {
public class AddressEditDialog {
}
}

You see: a lot of questions. Is here someone who can spend some time
to give some (hopefully more than "look at BlaBlub.generateFoo()").
I saw several questions like this one in this group but never a really
good answer.

If I succeed in doing this I offer to produce a tutorial like
extending the palette.

greetings,
Karsten

Report message to a moderator

Re: Extending VE - modify the way the root is generated [message #106374 is a reply to message #106345]

Tue, 13 September 2005 12:27

Srimanth

Messages: 225
Registered: July 2009

Senior Member

Hi Karsten,
VE currently doesnt model inner-types. Only the main IType of the
ICompilationUnit is modelled. So you will not be able to visualise the
inner-type AddressEditDialog using VE.
Regarding the new Visual Class wizard - It extends the reguglar new
Java Class wizard and adds further customizations. The .javajet provides
'additional lines' which will be added to the main .java file created by
JDT's new Java Class wizard. These 'new lines' include import additions,
new methods, new lines in existing methods etc. Please have a look at
org.eclipse.ve.internal.java.codegen.wizards.NewVisualClassC reationWizard.merge(ICompilationUnit,
ICompilationUnit, CodeFormatter, IProgressMonitor) API which merges the
..javajet's ICompilationUnit INTO JDT's ICompilationUnit. There hasnt
been a need for us to change modifiers of ITypes and all. Please have a
look at that code to see if there is another way you could achieve
desired results.
It would be excellent if you could produce a tutorial on your
extensions to VE.
Regards,
Sri.

Karsten Meier wrote:
> Hi,
>
> thats just another try to get an answer.
>
> First what I want to achieve:
>
> (Platform: Ecipse 3.0.*; VE 3.0.*)
>
> I need a way to get the VE to generate/decode code for JFace/SWT in a
> special extended Java Version. One key "feature" for that is to
> generate a different class header. For Example a dialog to edit
> Addresses has to look like that (note the special keywords):
>
> public team class AddressEditTeam {
>
> public class AddressEditDialog played by Address {
> /* ... */
> }
>
> }
>
> Except the "played by" part, AddressEditDialog will look mostly like
> Dialogs generated for SWT (at least for a first approach)
>
> The AST ist also extended to represent such structures. So I think the
> main problem is the question in how i can write a plugin that provides
> something to translate the AST to the VE Modell.
>
> I already read the tutorial to extend the palette - very helpful, but
> its "problems" start after my problem is solved. I also read through
> the report about the ULC extension and found some helpful graphs
> (chapter 3: "VE Architecture"; chapter 3.6: "Code Generation and
> Parsing").
>
> But I miss the "how to" to do that!
>
> First I tried to contribute to the extension point "newStyleComponent"
> and got so far, that my "Style" ist listed in the "new Visual Class"
> Wizard. Also I wrote a javajet for that and it worked "almost": all
> the special keywords are ignored. Debugging shows, that my contributor
> does generate the correct code, but some mechanisms seems to post
> modfy it. The example from above will result in:
>
> public class AddressEditTeam {
> public class AddressEditDialog {
> }
> }
>
> You see: a lot of questions. Is here someone who can spend some time
> to give some (hopefully more than "look at BlaBlub.generateFoo()").
> I saw several questions like this one in this group but never a really
> good answer.
>
> If I succeed in doing this I offer to produce a tutorial like
> extending the palette.
>
> greetings,
> Karsten

Report message to a moderator

Re: Extending VE - modify the way the root is generated [message #106401 is a reply to message #106374]

Tue, 13 September 2005 13:35

Eclipse User

Originally posted by: Karsten.Meier.gmx.org

Hi,

at first: thanks for the fast answer.

To your statements:
>Hi Karsten,
> VE currently doesnt model inner-types. Only the main IType of the
>ICompilationUnit is modelled. So you will not be able to visualise the
>inner-type AddressEditDialog using VE.

Ok - but isnt it possible to deliver something like a decoder to
translate a given AST or pure code to produce the needed model for VE?

There has to be a way because someone already said that it is (in
principle) possible to generate XML instead of Java. So it schould be
possible to generate something which is almost java :-)

> Regarding the new Visual Class wizard - It extends the reguglar new
>Java Class wizard and adds further customizations. The .javajet provides
>'additional lines' which will be added to the main .java file created by
>JDT's new Java Class wizard. These 'new lines' include import additions,
>new methods, new lines in existing methods etc. Please have a look at
> org.eclipse.ve.internal.java.codegen.wizards.NewVisualClassC reationWizard.merge(ICompilationUnit,
>ICompilationUnit, CodeFormatter, IProgressMonitor) API which merges the
>.javajet's ICompilationUnit INTO JDT's ICompilationUnit.

Well, i debugged down there but didnt understand what the hell he's
merging there. Ok - I think thats clear so far :-)
But it doesnt makes me happy - does that mean that it is impossible to
generate anything else except Java? Its hard to believe (see above)

> There hasnt been a need for us to change modifiers of ITypes and all. Please have a
> look at that code to see if there is another way you could achieve desired results.

ok - you gave me some valuable hint although i have the feeling that
it is not enough to get through.

>
> It would be excellent if you could produce a tutorial on your
>extensions to VE.

Yes - but it has to be at least possible. :-/

Thanks so far,
Karsten

>Regards,
>Sri.
>
>
>
>Karsten Meier wrote:
>> Hi,
>>
>> thats just another try to get an answer.
>>
>> First what I want to achieve:
>>
>> (Platform: Ecipse 3.0.*; VE 3.0.*)
>>
>> I need a way to get the VE to generate/decode code for JFace/SWT in a
>> special extended Java Version. One key "feature" for that is to
>> generate a different class header. For Example a dialog to edit
>> Addresses has to look like that (note the special keywords):
>>
>> public team class AddressEditTeam {
>>
>> public class AddressEditDialog played by Address {
>> /* ... */
>> }
>>
>> }
>>
>> Except the "played by" part, AddressEditDialog will look mostly like
>> Dialogs generated for SWT (at least for a first approach)
>>
>> The AST ist also extended to represent such structures. So I think the
>> main problem is the question in how i can write a plugin that provides
>> something to translate the AST to the VE Modell.
>>
>> I already read the tutorial to extend the palette - very helpful, but
>> its "problems" start after my problem is solved. I also read through
>> the report about the ULC extension and found some helpful graphs
>> (chapter 3: "VE Architecture"; chapter 3.6: "Code Generation and
>> Parsing").
>>
>> But I miss the "how to" to do that!
>>
>> First I tried to contribute to the extension point "newStyleComponent"
>> and got so far, that my "Style" ist listed in the "new Visual Class"
>> Wizard. Also I wrote a javajet for that and it worked "almost": all
>> the special keywords are ignored. Debugging shows, that my contributor
>> does generate the correct code, but some mechanisms seems to post
>> modfy it. The example from above will result in:
>>
>> public class AddressEditTeam {
>> public class AddressEditDialog {
>> }
>> }
>>
>> You see: a lot of questions. Is here someone who can spend some time
>> to give some (hopefully more than "look at BlaBlub.generateFoo()").
>> I saw several questions like this one in this group but never a really
>> good answer.
>>
>> If I succeed in doing this I offer to produce a tutorial like
>> extending the palette.
>>
>> greetings,
>> Karsten

Report message to a moderator

Re: Extending VE - modify the way the root is generated [message #106472 is a reply to message #106401]

Tue, 13 September 2005 14:06

Srimanth

Messages: 225
Registered: July 2009

Senior Member

Hi Karsten,

> There has to be a way because someone already said that it is (in
> principle) possible to generate XML instead of Java. So it schould be
> possible to generate something which is almost java :-)
Sure its possible but we currently dont support it.

> But it doesnt makes me happy - does that mean that it is impossible to
> generate anything else except Java? Its hard to believe (see above)
Currently VE is implemented to handle .java files which have Java syntax
in them. You could create your own wizard or extend VE's visual class
wizard to create non-Java source that you want.

Regards,
Sri.

Karsten Meier wrote:
> Hi,
>
> at first: thanks for the fast answer.
>
> To your statements:
>
>>Hi Karsten,
>> VE currently doesnt model inner-types. Only the main IType of the
>>ICompilationUnit is modelled. So you will not be able to visualise the
>>inner-type AddressEditDialog using VE.
>
>
> Ok - but isnt it possible to deliver something like a decoder to
> translate a given AST or pure code to produce the needed model for VE?
>
> There has to be a way because someone already said that it is (in
> principle) possible to generate XML instead of Java. So it schould be
> possible to generate something which is almost java :-)
>
>
>> Regarding the new Visual Class wizard - It extends the reguglar new
>>Java Class wizard and adds further customizations. The .javajet provides
>>'additional lines' which will be added to the main .java file created by
>>JDT's new Java Class wizard. These 'new lines' include import additions,
>>new methods, new lines in existing methods etc. Please have a look at
>> org.eclipse.ve.internal.java.codegen.wizards.NewVisualClassC reationWizard.merge(ICompilationUnit,
>>ICompilationUnit, CodeFormatter, IProgressMonitor) API which merges the
>>.javajet's ICompilationUnit INTO JDT's ICompilationUnit.
>
>
> Well, i debugged down there but didnt understand what the hell he's
> merging there. Ok - I think thats clear so far :-)
> But it doesnt makes me happy - does that mean that it is impossible to
> generate anything else except Java? Its hard to believe (see above)
>
>
>>There hasnt been a need for us to change modifiers of ITypes and all. Please have a
>>look at that code to see if there is another way you could achieve desired results.
>
>
> ok - you gave me some valuable hint although i have the feeling that
> it is not enough to get through.
>
>
>> It would be excellent if you could produce a tutorial on your
>>extensions to VE.
>
>
> Yes - but it has to be at least possible. :-/
>
> Thanks so far,
> Karsten
>
>
>
>
>>Regards,
>>Sri.
>>
>>
>>
>>Karsten Meier wrote:
>>
>>>Hi,
>>>
>>>thats just another try to get an answer.
>>>
>>>First what I want to achieve:
>>>
>>>(Platform: Ecipse 3.0.*; VE 3.0.*)
>>>
>>>I need a way to get the VE to generate/decode code for JFace/SWT in a
>>>special extended Java Version. One key "feature" for that is to
>>>generate a different class header. For Example a dialog to edit
>>>Addresses has to look like that (note the special keywords):
>>>
>>>public team class AddressEditTeam {
>>>
>>> public class AddressEditDialog played by Address {
>>> /* ... */
>>> }
>>>
>>>}
>>>
>>>Except the "played by" part, AddressEditDialog will look mostly like
>>>Dialogs generated for SWT (at least for a first approach)
>>>
>>>The AST ist also extended to represent such structures. So I think the
>>>main problem is the question in how i can write a plugin that provides
>>>something to translate the AST to the VE Modell.
>>>
>>>I already read the tutorial to extend the palette - very helpful, but
>>>its "problems" start after my problem is solved. I also read through
>>>the report about the ULC extension and found some helpful graphs
>>>(chapter 3: "VE Architecture"; chapter 3.6: "Code Generation and
>>>Parsing").
>>>
>>>But I miss the "how to" to do that!
>>>
>>>First I tried to contribute to the extension point "newStyleComponent"
>>>and got so far, that my "Style" ist listed in the "new Visual Class"
>>>Wizard. Also I wrote a javajet for that and it worked "almost": all
>>>the special keywords are ignored. Debugging shows, that my contributor
>>>does generate the correct code, but some mechanisms seems to post
>>>modfy it. The example from above will result in:
>>>
>>>public class AddressEditTeam {
>>> public class AddressEditDialog {
>>> }
>>>}
>>>
>>>You see: a lot of questions. Is here someone who can spend some time
>>>to give some (hopefully more than "look at BlaBlub.generateFoo()").
>>>I saw several questions like this one in this group but never a really
>>>good answer.
>>>
>>>If I succeed in doing this I offer to produce a tutorial like
>>>extending the palette.
>>>
>>>greetings,
>>>Karsten

Report message to a moderator

Re: Extending VE - modify the way the root is generated [message #106572 is a reply to message #106472]

Wed, 14 September 2005 12:38

Eclipse User

Originally posted by: Karsten.Meier.removethis.gmx.org

Hi,

wow - i got it to generate the things i want through the wizard!
Thank you very much, Sri!

But....(see comments below - they are meant to target the whole
project not you, Sri)

> > There has to be a way because someone already said that it is (in
> > principle) possible to generate XML instead of Java. So it schould be
> > possible to generate something which is almost java :-)
>Sure its possible but we currently dont support it.

What do you mean with "dont support it"? I thought the VE-Project
wants to be a framework. This Text can be found at the home page of
ve:

"The Eclipse Visual Editor project is a vendor-neutral, open
development platform supplying frameworks for creating GUI builders,
and exemplary, extensible tool implementations for Swing/JFC and
SWT/RCP. These tools are exemplary in that they verify the utility of
the Eclipse Visual Editor frameworks, illustrate the appropriate use
of those frameworks, and support the development and maintenance of
the Eclipse Visual Editor Platform itself."

So I expected it to be a framework independend of the based code model
- and the architecture seems to approve that, too.

> > But it doesnt makes me happy - does that mean that it is impossible to
> > generate anything else except Java? Its hard to believe (see above)
>Currently VE is implemented to handle .java files which have Java syntax
>in them. You could create your own wizard or extend VE's visual class
>wizard to create non-Java source that you want.

Yes - thats the way it worked: overriding the merge method. But it
feels (and in fact is) a quick and dirty hack!

My Problems with that (based on the fact of beeing a framework):

(1)
It would be easy to delegate the merge into the SourceContributor:
(I solved it this way - but need a little more work because the VE
Wizards encapsulates its features very strictly - see 2)

void merge(ICompilationUnit to, ICompilationUnit from,
CodeFormatter formatter, IProgressMonitor monitor){
ICreateVisualClassPostMerge merger = null;
if(contributor instanceof ICreateVisualClassPostMerge)
merger = (ICreateVisualClassPostMerge) _contributor;

if(merger == null)
// current merge code
else
merger.merge(to, from, formatter, monitor);
}

(2)
The features of the NewVisualClassCreationWizard should be at least
accessible from specialized classes - some protected getter would be
very nice! Now several of the code has to be copied to get access to
(for example) the contributor.

(3)
In general:
As a guy who wants to extend/use a framework I dont want to specialize
a whole wizard. I want to say: generate that if the user chooses this
style. The JJET templates are the perfect way but you destroy that way
with this suspicious merge mechanism - why dont you use the result of
the jjet?

(4)
To write a specialized wizard has another drawback: I need a new
Menuitem for it! Now I have two of them doing allmost the same.

So far for criticism.

Of course new questions arose from succeeding the first step >:-)

Question 1:
The VisualEditor has an Editor for the Code below the drawing area.
Is it possible to give VE another editor to show there?

Question 2:
As I wrote in the original post I have a nested structure of classes.
One of the nested classes is the one that should be edited with the
VE. In Fact this nested class will look (almost) like a SWT class
generated by the SWT example. As Sri already wrote VE uses the top
IType of the compilation unit to display it. Is there a way to plug in
there and doing some pre parse? The code to find the correct IType
would be quite easy.

Thanks,
Karsten

Report message to a moderator

Re: Extending VE - modify the way the root is generated [message #106632 is a reply to message #106572]

Wed, 14 September 2005 16:50

Srimanth

Messages: 225
Registered: July 2009

Senior Member

Hi Karsten,
We did open a defect sometime back to provide more flexibility for
contributors of the new visual class wizard.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=90750 . Please add
yourself on cc to track its progress.
Regards,
Sri.

Karsten Meier wrote:
> Hi,
>
> wow - i got it to generate the things i want through the wizard!
> Thank you very much, Sri!
>
> But....(see comments below - they are meant to target the whole
> project not you, Sri)
>
>
>>>There has to be a way because someone already said that it is (in
>>>principle) possible to generate XML instead of Java. So it schould be
>>>possible to generate something which is almost java :-)
>>
>>Sure its possible but we currently dont support it.
>
>
> What do you mean with "dont support it"? I thought the VE-Project
> wants to be a framework. This Text can be found at the home page of
> ve:
>
> "The Eclipse Visual Editor project is a vendor-neutral, open
> development platform supplying frameworks for creating GUI builders,
> and exemplary, extensible tool implementations for Swing/JFC and
> SWT/RCP. These tools are exemplary in that they verify the utility of
> the Eclipse Visual Editor frameworks, illustrate the appropriate use
> of those frameworks, and support the development and maintenance of
> the Eclipse Visual Editor Platform itself."
>
> So I expected it to be a framework independend of the based code model
> - and the architecture seems to approve that, too.
>
>
>>>But it doesnt makes me happy - does that mean that it is impossible to
>>>generate anything else except Java? Its hard to believe (see above)
>>
>>Currently VE is implemented to handle .java files which have Java syntax
>>in them. You could create your own wizard or extend VE's visual class
>>wizard to create non-Java source that you want.
>
>
> Yes - thats the way it worked: overriding the merge method. But it
> feels (and in fact is) a quick and dirty hack!
>
> My Problems with that (based on the fact of beeing a framework):
>
> (1)
> It would be easy to delegate the merge into the SourceContributor:
> (I solved it this way - but need a little more work because the VE
> Wizards encapsulates its features very strictly - see 2)
>
> void merge(ICompilationUnit to, ICompilationUnit from,
> CodeFormatter formatter, IProgressMonitor monitor){
> ICreateVisualClassPostMerge merger = null;
> if(contributor instanceof ICreateVisualClassPostMerge)
> merger = (ICreateVisualClassPostMerge) _contributor;
>
> if(merger == null)
> // current merge code
> else
> merger.merge(to, from, formatter, monitor);
> }
>
> (2)
> The features of the NewVisualClassCreationWizard should be at least
> accessible from specialized classes - some protected getter would be
> very nice! Now several of the code has to be copied to get access to
> (for example) the contributor.
>
> (3)
> In general:
> As a guy who wants to extend/use a framework I dont want to specialize
> a whole wizard. I want to say: generate that if the user chooses this
> style. The JJET templates are the perfect way but you destroy that way
> with this suspicious merge mechanism - why dont you use the result of
> the jjet?
>
> (4)
> To write a specialized wizard has another drawback: I need a new
> Menuitem for it! Now I have two of them doing allmost the same.
>
> So far for criticism.
>
> Of course new questions arose from succeeding the first step >:-)
>
> Question 1:
> The VisualEditor has an Editor for the Code below the drawing area.
> Is it possible to give VE another editor to show there?
>
> Question 2:
> As I wrote in the original post I have a nested structure of classes.
> One of the nested classes is the one that should be edited with the
> VE. In Fact this nested class will look (almost) like a SWT class
> generated by the SWT example. As Sri already wrote VE uses the top
> IType of the compilation unit to display it. Is there a way to plug in
> there and doing some pre parse? The code to find the correct IType
> would be quite easy.
>
> Thanks,
> Karsten

Report message to a moderator