Home » Archived » Visual Editor (VE) » Extending the palette
| Extending the palette [message #53440] |
Mon, 02 August 2004 11:55  |
Eclipse User |
|
|
|
Is this article still applicable for VE 1.0? --> "Extending the palette in
the WebSphere Studio Visual Editor for Java" ? The article was written in
Feb '03 and is available from the VE documents page.
I am interested in adding some "different" components to the VE palette.
(I've mentioned these in some previous items on this newsgroup.)
Our components are high level data bound controls that USE Swing
components at run time. There is not an IS-A relationship to the Swing
component, it's really HAS-A.
The users of our tool do not know anything about Swing or Java, rather we
present them with a much higher level abstraction.
For example, they don't work with a JTextField. Instead we present a
control called an EDITBOX that is a composite of a JLabel (for the label
like "Employee ID") a JTextField (where the data is entered) and a JButton
(press it to look up valid values). By setting properties on the control,
they can control the Text and position of the Label, the DB table/column
the JTextField is bound to, and whether the Lookup button appears.
I'm interested in Extending VE to handle these high level components by
adding them as a new category on the Palette. Hence my interest in the
above article. It concerns me that the article states:
"IBM does not guarantee that the technique described in this article is
supported in future releases. All of the classes that make up the palette
extension mechanism are in internal packages and IBM reserves the right to
withdraw or alter the API allowing access to these classes."
But if the article is still current, it is certainly a good place to start.
Aside from this article, is there any other documentation that would help?
I'm assuming that in extending VE to handle our high-level data bound
components, I'll need to write some Proxy Java Beans and BeanInfo that
encapsulate all the run-time behaviors. (Right now none of our controls
are implemented as a Bean).
But I wonder if what I'm looking at doing is beyond a reasonable extension
to VE? But am hoping to prototype adding just one of our components to the
VE palette - this would tell us a lot.
|
|
|
| Re: Extending the palette [message #53548 is a reply to message #53440] |
Mon, 02 August 2004 13:57  |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
No, it is very reasonable, however, if you want these to be visuals on
the VE (i.e. when drop an EDITBOX you see a picture of the JLabel and
JTextField), it is more difficult. You will need to supply EditParts,
BeanProxyAdapters, ContainerPolicys, and so on. We can help you with
that, but you need to be aware things will change as we go to the next
version and start making some of the internal classes API classes instead.
I'm assuming you are producing Java code to run in application. That
makes it even more applicable. But your best bet is to converge on the
Bean protocol. Our code generation style works best with that protocol.
When we gave the warning about changes in the future, we probably won't
be dropping anything, but we will be refactoring (moving it around,
splitting it up, renaming) and making things API. Once API those will be
stable and shouldn't be changing without a lot of pre-notification from
us and with minimal breakage.
--
Thanks, Rich Kulp
|
|
| | |
| Re: Extending the palette [message #53652 is a reply to message #53548] |
Mon, 02 August 2004 15:23 |
| Eclipse User |
|
|
|
Sorry to keep bugging you guys with these questions, but we like a lot of
what we see in VE and find the idea of extending it to handle our
components a path to a good solution. Some specific questions about your
last reply...
> No, it is very reasonable, however, if you want these to be visuals on
> the VE (i.e. when drop an EDITBOX you see a picture of the JLabel and
> JTextField), it is more difficult. You will need to supply EditParts,
> BeanProxyAdapters, ContainerPolicys, and so on. We can help you with
> that, but you need to be aware things will change as we go to the next
> version and start making some of the internal classes API classes instead.
...
> When we gave the warning about changes in the future, we probably won't
> be dropping anything, but we will be refactoring (moving it around,
> splitting it up, renaming) and making things API. Once API those will be
> stable and shouldn't be changing without a lot of pre-notification from
> us and with minimal breakage.
Would we need to write a plugin that would mirror
org.eclipse.ve.internal.jfc.core? I was hoping to somehow reuse
ComponentGraphicalEditPart, ComponentProxyAdapter, etc. Could clever
Beans/BeanInfo make our components look like just a new Swing component
that could use the existing internal.jfc.core classes? I really like the
way VE gets the Figures for the EditParts from the live Java Objects in
the Target VM. If we reuse that it solves a huge WYSIWYG problem.
But these are in an internal package, so it doesn't seem like a good idea
to use them, or to even write our own versions of them if we're just going
to have to change as VE changes (assuming the changes would be
non-trivial). Would the coming API classes be much better suited to the
"data bound composite" components we want to add? Any timeframe for the
new API's?
> I'm assuming you are producing Java code to run in application. That
> makes it even more applicable. But your best bet is to converge on the
> Bean protocol. Our code generation style works best with that protocol.
Our application does NOT generate Java code. All it does is store Meta
Data to a Data Base. Currently the meta data is rendered at run-time with
a Java JVM and Swing components. It didn't used to be that way (in the
past we used C and the Win32 API at run time) and it could change in the
future (maybe RCP? hopefully not .net, but who knows). But all we generate
from the tool is platform independant meta data.
So we would need to greatly simplify the CodeGen portion of the VE
architecture. The user can only change the DataBase via the Editor, so we
don't need the 2-way model<-->source update. Also we only want to actually
write to the DB when the user invokes "Save". So we are updating much less
frequently.
Keep in mind that the user of our tool is NOT a Java programmer. We don't
want the user able to create or compile Java. Also we only want our
components on the palette (no SWT, Swing, or AWT components should be
available). So I guess we would need to write our own new Visual "Class"
Wizard given our end users. There's also the problem of integrating VE in
an Eclipse environment where we hopefully wouldn't have jdt.
Does eveything I want to do begin to sound like it's way beyond an
extension of VE?
|
|
|
| Re: Extending the palette [message #53702 is a reply to message #53652] |
Mon, 02 August 2004 16:14 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
Oh, this is completely different from where I thought you were heading.
Since you are not generating java code, then I don't recommend the
java.core and higher portions. Someone in the past has done this. They
have almost the same requirements but had a different runtime file
architecture. The problems they ran into was that they required to have
their project be a java project even though they weren't really a java
application, and they used the graphical editparts as given, and then
were constantly playing follow the leader as we made changes. Also they
had introduce some java peculiarities into their model just so that it
matched up with our java implementation, and so on.
The CDE portion of VE may be more suitable.
Since this is a closed model on your end, do you need extendability? In
other words do you need others to be able to contribute to your model
and provide their own parts that users can drop and configure? Do you
need portions (distributed in separate plugins like we distribute a jfc
for awt/swing and swt for SWT) to be there or not there depending on the
configuration? If you need that, then the CDE way would be the way to
go. If you don't, it may be better to just go the straight GEF approach.
GEF alone is great when you have a static model because you can fine
tune it just for you what you need. The CDE approach is for the
heterogeneous approach where there may be contributions from other
plugins and users that you didn't do yourselves. We add a lot of generic
constructs that at first glance look confusing, but they are there to
allow us to extend and add plugins without having to rewrite everything
else around it.
--
Thanks, Rich Kulp
|
|
|
| Re: Extending the palette [message #53837 is a reply to message #53702] |
Tue, 03 August 2004 03:04 |
| Eclipse User |
|
|
|
Hi Rich,
Extending the palette is not the subject of articles in NetBeans,
JBuilder nor VisualAge. Maximum a help entry. IMHO, something is wrong in
the palette
architecture design. The palete extension is a normal operation, so must
be easy.
Francesc Rosés
Rich Kulp wrote:
> Oh, this is completely different from where I thought you were heading.
> Since you are not generating java code, then I don't recommend the
> java.core and higher portions. Someone in the past has done this. They
> have almost the same requirements but had a different runtime file
> architecture. The problems they ran into was that they required to have
> their project be a java project even though they weren't really a java
> application, and they used the graphical editparts as given, and then
> were constantly playing follow the leader as we made changes. Also they
> had introduce some java peculiarities into their model just so that it
> matched up with our java implementation, and so on.
> The CDE portion of VE may be more suitable.
> Since this is a closed model on your end, do you need extendability? In
> other words do you need others to be able to contribute to your model
> and provide their own parts that users can drop and configure? Do you
> need portions (distributed in separate plugins like we distribute a jfc
> for awt/swing and swt for SWT) to be there or not there depending on the
> configuration? If you need that, then the CDE way would be the way to
> go. If you don't, it may be better to just go the straight GEF approach.
> GEF alone is great when you have a static model because you can fine
> tune it just for you what you need. The CDE approach is for the
> heterogeneous approach where there may be contributions from other
> plugins and users that you didn't do yourselves. We add a lot of generic
> constructs that at first glance look confusing, but they are there to
> allow us to extend and add plugins without having to rewrite everything
> else around it.
|
|
|
| Re: Extending the palette [message #53863 is a reply to message #53702] |
Tue, 03 August 2004 09:56 |
| Eclipse User |
|
|
|
VE is starting to look like less of an option for our requirements. I've
added comments/questions to your reply below. Want to make sure I
understand all this...
> Oh, this is completely different from where I thought you were heading.
> Since you are not generating java code, then I don't recommend the
> java.core and higher portions. Someone in the past has done this. They
> have almost the same requirements but had a different runtime file
> architecture. The problems they ran into was that they required to have
> their project be a java project even though they weren't really a java
> application, and they used the graphical editparts as given, and then
> were constantly playing follow the leader as we made changes. Also they
> had introduce some java peculiarities into their model just so that it
> matched up with our java implementation, and so on.
java.core looks like it's the package that handles the BeanProxy and
communicates with the Target VM. This is the one piece of VE that I really
wanted to reuse since it looks like such a cool solution to our WYSIWG
problem. (BTW, we only support x,y positioning (ie. null layout) so exact
geometry is crucial to us.)
But if using java.core means we have to make changes for every new VE
release then it's definitely not the way to go.
Plus, it would be totally unacceptable to make our user's create a Java
Project and do things like use classpath variables.
> The CDE portion of VE may be more suitable.
> Since this is a closed model on your end, do you need extendability? In
> other words do you need others to be able to contribute to your model
> and provide their own parts that users can drop and configure? Do you
> need portions (distributed in separate plugins like we distribute a jfc
> for awt/swing and swt for SWT) to be there or not there depending on the
> configuration? If you need that, then the CDE way would be the way to
> go. If you don't, it may be better to just go the straight GEF approach.
> GEF alone is great when you have a static model because you can fine
> tune it just for you what you need. The CDE approach is for the
> heterogeneous approach where there may be contributions from other
> plugins and users that you didn't do yourselves. We add a lot of generic
> constructs that at first glance look confusing, but they are there to
> allow us to extend and add plugins without having to rewrite everything
> else around it.
We would never need extendability. We store platform independant Meta Data
that is rendered at run time by our "Meta Data Player". We have to have
code in the run time to handle the Meta Data, so we can't have new Meta
Data appearing unless we've already written the run time support for it.
Given all this, could we still consider using CDE? After all we do want to
add a plugin for our "data bound composite controls" we just aren't going
to let anybody else do it.
Looking at CDE it appears to handle the EMF interface, commands, palette,
borders, and lots of the graphics in the editor. It would be nice not to
"reinvent" all this. But can the CDE portion run without java.core which
we established above is probably not a good choice.
I have been working on a prototype that uses GEF. I'm able to read the
Meta Data from the DB and instatiate EditParts and their associated
Figures. Am finding that these figures are not WYSIWG. It's tough to use
draw2d Figures (Label, Checkbox, FlowText, ScrollBar etc.) and have the
exact same dimensions as the Swing components that would be instantiated
at run-time. Seems if we go this way will need to create our own Figures
that do their own drawing rather than trying to reuse the draw2d higher
level figures. That drawing code will sadly be coupled to Swing geometry.
If Swing component rendering is tweaked, then we have to tweak.
WYSIWYG problems aside, GEF does supply a lot of functionality that we
need. But was hoping to reuse the higher level constructs in VE, but for
all the reasons above it appears our app is not a good fit with VE.
Bottom line of all this, is that it appears we should focus on GEF for
this project. Would you agree?
|
|
|
| Re: Extending the palette [message #54095 is a reply to message #53863] |
Tue, 03 August 2004 10:53 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
CDE itself doesn't require the project to be a java project. But to use
anything from java.core does require it to be a java project. That is
because it uses the JEM (Java EMF Model) and that finds the java classes
thru the current project's classpath.
The CDE is the base for the java VE and works with an EMF model. It
provides some base functions as you noted. If you have an EMF model, it
could be useful. If your model is not EMF, then it is not as useful.
Also whether you use CDE or not you can still use the proxy stuff out of
JEM. It starts a remote vm and lets us talk to it thru proxies (sort of
like RPC but lighter and more dynamic). We use the implementation that
requires a java project because we need to set up classpaths that
depends on the project. However, there is a way to call it (actually I
haven't tested it because I don't use it, but it is supposed to work)
without a project at all. In that case it would use the default Java JRE
in your workspace. If all you want is Swing, and assuming the default
Java JRE has Swing, then it will work fine. (The reason I add the caveat
is because some embedded Java's don't have Swing by default and if that
was the default JRE for your workspace that could be a problem).
This will allow you to start Swing objects on the remote vm. You would
use the proxy's directly instead of through the BeanProxyAdapters. You
can't use the BeanProxyAdapters because they expect to be attached to an
EMF instance (called a IJavaObjectInstance) that represents an instance
of a Java Class in your model. But that requires the full JEM and a java
project. However, the proxies don't care. They don't use the JEM EMF model.
But for your stuff, I don't even actually recommend using the JEM proxy
stuff because you really don't need to run your Swing classes in another
VM. Since you have absolute control, you can just create the Swing
classes in the IDE directly. This has the advantage of no remote vm
being created and maintained. The reason you can do it is because you
won't be creating classes that will be changing or user code that could
cause the IDE to crash. You will just be creating instances of Swing
classes. Then you can use something similar to our ComponentManager to
listen for size changes, and something similar to our ImageDataCollector
to grab the image and put it into a GEF ImageFigure.
--
Thanks, Rich Kulp
|
|
| |
| Re: Extending the palette [message #596458 is a reply to message #53440] |
Mon, 02 August 2004 13:57 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
No, it is very reasonable, however, if you want these to be visuals on
the VE (i.e. when drop an EDITBOX you see a picture of the JLabel and
JTextField), it is more difficult. You will need to supply EditParts,
BeanProxyAdapters, ContainerPolicys, and so on. We can help you with
that, but you need to be aware things will change as we go to the next
version and start making some of the internal classes API classes instead.
I'm assuming you are producing Java code to run in application. That
makes it even more applicable. But your best bet is to converge on the
Bean protocol. Our code generation style works best with that protocol.
When we gave the warning about changes in the future, we probably won't
be dropping anything, but we will be refactoring (moving it around,
splitting it up, renaming) and making things API. Once API those will be
stable and shouldn't be changing without a lot of pre-notification from
us and with minimal breakage.
--
Thanks, Rich Kulp
|
|
| |
| Re: Extending the palette [message #596472 is a reply to message #53574] |
Mon, 02 August 2004 14:29 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
For some reason that link doesn't work, so here's a copy of the reply:
We don't have an updated article, but the basic principles still apply.
The best way to try to extend the palette is to look at an example
of where the VE already does it, so the ideas in the article still
largely apply and the syntax is just different. To see the correct
syntax/method look at the org.eclipse.ve.jfc plugin (that adds AWT/Swing
to the palette) and also org.eclipse.ve.swt (that adds SWT support).
There is a detailed document about the VE extension points for
contributors that covers the palette at:
http://dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/vep -home/WebContent/docs/contributors/contributors.html
Best regards,
Joe Winchester
--
Thanks, Rich Kulp
|
|
|
| Re: Extending the palette [message #596481 is a reply to message #53548] |
Mon, 02 August 2004 15:23 |
| Eclipse User |
|
|
|
Sorry to keep bugging you guys with these questions, but we like a lot of
what we see in VE and find the idea of extending it to handle our
components a path to a good solution. Some specific questions about your
last reply...
> No, it is very reasonable, however, if you want these to be visuals on
> the VE (i.e. when drop an EDITBOX you see a picture of the JLabel and
> JTextField), it is more difficult. You will need to supply EditParts,
> BeanProxyAdapters, ContainerPolicys, and so on. We can help you with
> that, but you need to be aware things will change as we go to the next
> version and start making some of the internal classes API classes instead.
...
> When we gave the warning about changes in the future, we probably won't
> be dropping anything, but we will be refactoring (moving it around,
> splitting it up, renaming) and making things API. Once API those will be
> stable and shouldn't be changing without a lot of pre-notification from
> us and with minimal breakage.
Would we need to write a plugin that would mirror
org.eclipse.ve.internal.jfc.core? I was hoping to somehow reuse
ComponentGraphicalEditPart, ComponentProxyAdapter, etc. Could clever
Beans/BeanInfo make our components look like just a new Swing component
that could use the existing internal.jfc.core classes? I really like the
way VE gets the Figures for the EditParts from the live Java Objects in
the Target VM. If we reuse that it solves a huge WYSIWYG problem.
But these are in an internal package, so it doesn't seem like a good idea
to use them, or to even write our own versions of them if we're just going
to have to change as VE changes (assuming the changes would be
non-trivial). Would the coming API classes be much better suited to the
"data bound composite" components we want to add? Any timeframe for the
new API's?
> I'm assuming you are producing Java code to run in application. That
> makes it even more applicable. But your best bet is to converge on the
> Bean protocol. Our code generation style works best with that protocol.
Our application does NOT generate Java code. All it does is store Meta
Data to a Data Base. Currently the meta data is rendered at run-time with
a Java JVM and Swing components. It didn't used to be that way (in the
past we used C and the Win32 API at run time) and it could change in the
future (maybe RCP? hopefully not .net, but who knows). But all we generate
from the tool is platform independant meta data.
So we would need to greatly simplify the CodeGen portion of the VE
architecture. The user can only change the DataBase via the Editor, so we
don't need the 2-way model<-->source update. Also we only want to actually
write to the DB when the user invokes "Save". So we are updating much less
frequently.
Keep in mind that the user of our tool is NOT a Java programmer. We don't
want the user able to create or compile Java. Also we only want our
components on the palette (no SWT, Swing, or AWT components should be
available). So I guess we would need to write our own new Visual "Class"
Wizard given our end users. There's also the problem of integrating VE in
an Eclipse environment where we hopefully wouldn't have jdt.
Does eveything I want to do begin to sound like it's way beyond an
extension of VE?
|
|
|
| Re: Extending the palette [message #596498 is a reply to message #53652] |
Mon, 02 August 2004 16:14 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
Oh, this is completely different from where I thought you were heading.
Since you are not generating java code, then I don't recommend the
java.core and higher portions. Someone in the past has done this. They
have almost the same requirements but had a different runtime file
architecture. The problems they ran into was that they required to have
their project be a java project even though they weren't really a java
application, and they used the graphical editparts as given, and then
were constantly playing follow the leader as we made changes. Also they
had introduce some java peculiarities into their model just so that it
matched up with our java implementation, and so on.
The CDE portion of VE may be more suitable.
Since this is a closed model on your end, do you need extendability? In
other words do you need others to be able to contribute to your model
and provide their own parts that users can drop and configure? Do you
need portions (distributed in separate plugins like we distribute a jfc
for awt/swing and swt for SWT) to be there or not there depending on the
configuration? If you need that, then the CDE way would be the way to
go. If you don't, it may be better to just go the straight GEF approach.
GEF alone is great when you have a static model because you can fine
tune it just for you what you need. The CDE approach is for the
heterogeneous approach where there may be contributions from other
plugins and users that you didn't do yourselves. We add a lot of generic
constructs that at first glance look confusing, but they are there to
allow us to extend and add plugins without having to rewrite everything
else around it.
--
Thanks, Rich Kulp
|
|
|
| Re: Extending the palette [message #596545 is a reply to message #53702] |
Tue, 03 August 2004 03:04 |
| Eclipse User |
|
|
|
Hi Rich,
Extending the palette is not the subject of articles in NetBeans,
JBuilder nor VisualAge. Maximum a help entry. IMHO, something is wrong in
the palette
architecture design. The palete extension is a normal operation, so must
be easy.
Francesc Rosés
Rich Kulp wrote:
> Oh, this is completely different from where I thought you were heading.
> Since you are not generating java code, then I don't recommend the
> java.core and higher portions. Someone in the past has done this. They
> have almost the same requirements but had a different runtime file
> architecture. The problems they ran into was that they required to have
> their project be a java project even though they weren't really a java
> application, and they used the graphical editparts as given, and then
> were constantly playing follow the leader as we made changes. Also they
> had introduce some java peculiarities into their model just so that it
> matched up with our java implementation, and so on.
> The CDE portion of VE may be more suitable.
> Since this is a closed model on your end, do you need extendability? In
> other words do you need others to be able to contribute to your model
> and provide their own parts that users can drop and configure? Do you
> need portions (distributed in separate plugins like we distribute a jfc
> for awt/swing and swt for SWT) to be there or not there depending on the
> configuration? If you need that, then the CDE way would be the way to
> go. If you don't, it may be better to just go the straight GEF approach.
> GEF alone is great when you have a static model because you can fine
> tune it just for you what you need. The CDE approach is for the
> heterogeneous approach where there may be contributions from other
> plugins and users that you didn't do yourselves. We add a lot of generic
> constructs that at first glance look confusing, but they are there to
> allow us to extend and add plugins without having to rewrite everything
> else around it.
|
|
|
| Re: Extending the palette [message #596552 is a reply to message #53702] |
Tue, 03 August 2004 09:56 |
| Eclipse User |
|
|
|
VE is starting to look like less of an option for our requirements. I've
added comments/questions to your reply below. Want to make sure I
understand all this...
> Oh, this is completely different from where I thought you were heading.
> Since you are not generating java code, then I don't recommend the
> java.core and higher portions. Someone in the past has done this. They
> have almost the same requirements but had a different runtime file
> architecture. The problems they ran into was that they required to have
> their project be a java project even though they weren't really a java
> application, and they used the graphical editparts as given, and then
> were constantly playing follow the leader as we made changes. Also they
> had introduce some java peculiarities into their model just so that it
> matched up with our java implementation, and so on.
java.core looks like it's the package that handles the BeanProxy and
communicates with the Target VM. This is the one piece of VE that I really
wanted to reuse since it looks like such a cool solution to our WYSIWG
problem. (BTW, we only support x,y positioning (ie. null layout) so exact
geometry is crucial to us.)
But if using java.core means we have to make changes for every new VE
release then it's definitely not the way to go.
Plus, it would be totally unacceptable to make our user's create a Java
Project and do things like use classpath variables.
> The CDE portion of VE may be more suitable.
> Since this is a closed model on your end, do you need extendability? In
> other words do you need others to be able to contribute to your model
> and provide their own parts that users can drop and configure? Do you
> need portions (distributed in separate plugins like we distribute a jfc
> for awt/swing and swt for SWT) to be there or not there depending on the
> configuration? If you need that, then the CDE way would be the way to
> go. If you don't, it may be better to just go the straight GEF approach.
> GEF alone is great when you have a static model because you can fine
> tune it just for you what you need. The CDE approach is for the
> heterogeneous approach where there may be contributions from other
> plugins and users that you didn't do yourselves. We add a lot of generic
> constructs that at first glance look confusing, but they are there to
> allow us to extend and add plugins without having to rewrite everything
> else around it.
We would never need extendability. We store platform independant Meta Data
that is rendered at run time by our "Meta Data Player". We have to have
code in the run time to handle the Meta Data, so we can't have new Meta
Data appearing unless we've already written the run time support for it.
Given all this, could we still consider using CDE? After all we do want to
add a plugin for our "data bound composite controls" we just aren't going
to let anybody else do it.
Looking at CDE it appears to handle the EMF interface, commands, palette,
borders, and lots of the graphics in the editor. It would be nice not to
"reinvent" all this. But can the CDE portion run without java.core which
we established above is probably not a good choice.
I have been working on a prototype that uses GEF. I'm able to read the
Meta Data from the DB and instatiate EditParts and their associated
Figures. Am finding that these figures are not WYSIWG. It's tough to use
draw2d Figures (Label, Checkbox, FlowText, ScrollBar etc.) and have the
exact same dimensions as the Swing components that would be instantiated
at run-time. Seems if we go this way will need to create our own Figures
that do their own drawing rather than trying to reuse the draw2d higher
level figures. That drawing code will sadly be coupled to Swing geometry.
If Swing component rendering is tweaked, then we have to tweak.
WYSIWYG problems aside, GEF does supply a lot of functionality that we
need. But was hoping to reuse the higher level constructs in VE, but for
all the reasons above it appears our app is not a good fit with VE.
Bottom line of all this, is that it appears we should focus on GEF for
this project. Would you agree?
|
|
|
| Re: Extending the palette [message #596570 is a reply to message #53863] |
Tue, 03 August 2004 10:53 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
CDE itself doesn't require the project to be a java project. But to use
anything from java.core does require it to be a java project. That is
because it uses the JEM (Java EMF Model) and that finds the java classes
thru the current project's classpath.
The CDE is the base for the java VE and works with an EMF model. It
provides some base functions as you noted. If you have an EMF model, it
could be useful. If your model is not EMF, then it is not as useful.
Also whether you use CDE or not you can still use the proxy stuff out of
JEM. It starts a remote vm and lets us talk to it thru proxies (sort of
like RPC but lighter and more dynamic). We use the implementation that
requires a java project because we need to set up classpaths that
depends on the project. However, there is a way to call it (actually I
haven't tested it because I don't use it, but it is supposed to work)
without a project at all. In that case it would use the default Java JRE
in your workspace. If all you want is Swing, and assuming the default
Java JRE has Swing, then it will work fine. (The reason I add the caveat
is because some embedded Java's don't have Swing by default and if that
was the default JRE for your workspace that could be a problem).
This will allow you to start Swing objects on the remote vm. You would
use the proxy's directly instead of through the BeanProxyAdapters. You
can't use the BeanProxyAdapters because they expect to be attached to an
EMF instance (called a IJavaObjectInstance) that represents an instance
of a Java Class in your model. But that requires the full JEM and a java
project. However, the proxies don't care. They don't use the JEM EMF model.
But for your stuff, I don't even actually recommend using the JEM proxy
stuff because you really don't need to run your Swing classes in another
VM. Since you have absolute control, you can just create the Swing
classes in the IDE directly. This has the advantage of no remote vm
being created and maintained. The reason you can do it is because you
won't be creating classes that will be changing or user code that could
cause the IDE to crash. You will just be creating instances of Swing
classes. Then you can use something similar to our ComponentManager to
listen for size changes, and something similar to our ImageDataCollector
to grab the image and put it into a GEF ImageFigure.
--
Thanks, Rich Kulp
|
|
| |
Goto Forum:
Current Time: Fri May 09 20:24:59 EDT 2025
Powered by FUDForum. Page generated in 0.10776 seconds |
Home