Home » Archived » Visual Editor (VE) » Browsing the VE Source
| Browsing the VE Source [message #51273] |
Thu, 22 July 2004 09:13  |
Eclipse User |
|
|
|
After getting the VE SDK I imported the plugins and created projects from
them.
Wanted to look at the EditParts and associated Figures that VE uses for
Swing components.
I assumed that these would be in org.eclipse.ve.internal.jfc.core. But
don't see any thing that looks like EditParts or Figures in there.
Is there any documentation that explains how the VE SDK is put together?
Seems to have a bewildering array of different PlugIns that are way beyond
anything I've seen in my brief experience.
I'm investigating using GEF for a Visual Builder for our own non-Java 4GL
environment which uses Swing at run time. We store all the meta-data that
we generate the Swing components from in a DataBase. So I'm not sure how
useful EMF would be to us (we don't ever generate Java Source, we just
read the meta data and create Swing components at run time). But really
would like to see how VE renders components at design time.
|
|
| | |
| Re: Browsing the VE Source [message #51439 is a reply to message #51273] |
Thu, 22 July 2004 12:16  |
| Eclipse User |
|
|
|
Steve Harper wrote:
> I'm investigating using GEF for a Visual Builder for our own non-Java 4GL
> environment which uses Swing at run time. We store all the meta-data that
> we generate the Swing components from in a DataBase. So I'm not sure how
> useful EMF would be to us (we don't ever generate Java Source, we just
> read the meta data and create Swing components at run time). But really
> would like to see how VE renders components at design time.
In addition to the other posts, I'll add a brief architectural description:
VE uses the model-view-controller pattern, so the model is king and
everything else is just a view of that model.
Since VE needs to be able to model any kind of UI for any platform or
language, a platform and widget-set independent model was needed. EMF
fits this pretty well because it has methods that are analogous to what
you find in java.lang.reflect, but is not Java specific. These methods
can be used to discover the property names and read/write the contents
of your GUI objects dynamically at runtime, just like you would do using
java.lang.reflect or java.beans, but without directly relying on either.
So if you wanted to hook into VE, your persistence model (in your case,
your database) would be hooked up as a "view" listening to the EMF model
in order to support your back-end.
I hope this helps provide some conceptual understanding of how VE works.
As the others said, please ask more specific questions as you need to
and we'll try to help.
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com
|
|
|
| Re: Browsing the VE Source [message #52569 is a reply to message #51300] |
Fri, 30 July 2004 09:47 |
| Eclipse User |
|
|
|
I don't think it would make sense for the editor I'm working on to extend
VE. We have platform independant meta data stored in a database. At run
time we have a "Swing Player" that reads the meta data and instatiates
Swing components on the fly. There are currently over 1000 such panels
stored in the database together with 4GL code that handles the business
logic on the panels. We have never generated Java code that represents
these panels. Instead we render them at run time using Java. So the whole
approach of VE using EMF to generate Java code from the beans doesn't seem
to apply to this editor.
I am very interested in how VE renders the Swing components at design time.
Looked at ComponentGraphicalEditPart and started looking at ImageFigure,
ImageFigureController, IVisualComponent, et al. Have to admit I quickly
became lost. Was trying to see if you used draw2d to actually render the
components. Assume that when I run VE that I'm not actually manipulating
real Swing components but rather the proxies that are somehow rendered
with draw2d.
I've got a prototype of my editor where the various Swing Components are
rendered via draw2d components (ie. been using Label, TextFlow, Checkbox
from draw2d to simulate Swing components). Having a lot of problem
(obviously) doing WYSIWYG with the approach.
When someone drops a Swing JCheckBox on the editor in VE where does the
ImageFigure come from? I did a search on all calls to
ImageFigure.setImage() and was even more confused about what was going on.
Can you point at the classes I should look at to understand all this?
Thanks, it looks like there are some really powerful patterns in VE that
are generally applicable, but it's hard to get the big picture diving into
the source. Think a big part of my difficulty is that I've never written a
Visual Editor of any kind.
Jeff Myers wrote:
> Steve,
> Glad to have you looking at the VE source. Someone else will talk about
> the documentation (or lack thereof) and what would be necessary to
> achieve what you're looking to do, but I can quickly point out which
> EditParts you might want to start looking at. On the JFC side, check
> out ComponentGraphicalEditPart and ContainerGraphicalEditPart in
> org.eclipse.ve.internal.jfc.core. ....
|
|
|
| Re: Browsing the VE Source [message #52596 is a reply to message #52569] |
Fri, 30 July 2004 10:42 |
| Eclipse User |
|
|
|
Originally posted by: myersj.nospam.us.ibm.com
Steve,
Please check out the overview of the Visual Editor's architecture here:
http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /vep-home/WebContent/docs/architecture/architecture.html
To render the Swing, AWT and SWT components, the Visual Editor launches
a target VM off screen that instantiates and renders a live version of
the file you're editing. The image is captured from this live window,
and sent via the proxy classes you found back to the editor. The editor
takes these screen capture images and creates GEF figures out of them.
This is the way we ensure an accurate WYSIWYG representation of the
Visual Class.
The VE project is designed to be able to extend or replace any of the
main architecture components (the blue ovals in the diagram) with
alternate implementations. This means you could rip out the Java code
generation aspect of the VE completely and replace it with something
that generates whatever representation you are storing in your database.
You can provide an adaptor from your model to the VE's Java component
EMF model, or replace the core model with another EMF model that will
work with the other parts of the system.
The point is, you can replace codegen and the rest of the framework will
do the rest for you (all the GEF edit parts, the rendering on the target
vm, etc)
Hope this helps,
- Jeff
Steve Harper wrote:
> I don't think it would make sense for the editor I'm working on to extend
> VE. We have platform independant meta data stored in a database. At run
> time we have a "Swing Player" that reads the meta data and instatiates
> Swing components on the fly. There are currently over 1000 such panels
> stored in the database together with 4GL code that handles the business
> logic on the panels. We have never generated Java code that represents
> these panels. Instead we render them at run time using Java. So the whole
> approach of VE using EMF to generate Java code from the beans doesn't seem
> to apply to this editor.
>
> I am very interested in how VE renders the Swing components at design time.
> Looked at ComponentGraphicalEditPart and started looking at ImageFigure,
> ImageFigureController, IVisualComponent, et al. Have to admit I quickly
> became lost. Was trying to see if you used draw2d to actually render the
> components. Assume that when I run VE that I'm not actually manipulating
> real Swing components but rather the proxies that are somehow rendered
> with draw2d.
>
> I've got a prototype of my editor where the various Swing Components are
> rendered via draw2d components (ie. been using Label, TextFlow, Checkbox
> from draw2d to simulate Swing components). Having a lot of problem
> (obviously) doing WYSIWYG with the approach.
>
> When someone drops a Swing JCheckBox on the editor in VE where does the
> ImageFigure come from? I did a search on all calls to
> ImageFigure.setImage() and was even more confused about what was going on.
> Can you point at the classes I should look at to understand all this?
>
> Thanks, it looks like there are some really powerful patterns in VE that
> are generally applicable, but it's hard to get the big picture diving into
> the source. Think a big part of my difficulty is that I've never written a
> Visual Editor of any kind.
|
|
|
| Re: Browsing the VE Source [message #595618 is a reply to message #51273] |
Thu, 22 July 2004 09:37 |
| Eclipse User |
|
|
|
Steve,
Glad to have you looking at the VE source. Someone else will talk about
the documentation (or lack thereof) and what would be necessary to
achieve what you're looking to do, but I can quickly point out which
EditParts you might want to start looking at. On the JFC side, check
out ComponentGraphicalEditPart and ContainerGraphicalEditPart in
org.eclipse.ve.internal.jfc.core.
I'll see about getting you a more indepth response to your other
questions. I'd also encourage you to join the VE development mailing
list at http://dev.eclipse.org/mailman/listinfo/ve-dev
- Jeff
Steve Harper wrote:
> After getting the VE SDK I imported the plugins and created projects from
> them.
> Wanted to look at the EditParts and associated Figures that VE uses for
> Swing components.
>
> I assumed that these would be in org.eclipse.ve.internal.jfc.core. But
> don't see any thing that looks like EditParts or Figures in there.
> Is there any documentation that explains how the VE SDK is put together?
> Seems to have a bewildering array of different PlugIns that are way beyond
> anything I've seen in my brief experience.
>
> I'm investigating using GEF for a Visual Builder for our own non-Java 4GL
> environment which uses Swing at run time. We store all the meta-data that
> we generate the Swing components from in a DataBase. So I'm not sure how
> useful EMF would be to us (we don't ever generate Java Source, we just
> read the meta data and create Swing components at run time). But really
> would like to see how VE renders components at design time.
>
|
|
|
| Re: Browsing the VE Source [message #595628 is a reply to message #51273] |
Thu, 22 July 2004 09:59 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.NO.SPAM.us.ibm.com
If you have a fixed, small, non-extensible model, using GEF is probably
the best way to go. VE adds a fair amount of extras, but those extras
are for allowing anybody through plugins to extend your editor. We have
that condition with the VE for Java because anyone can add their own
editparts and code generators.
As for documentation, we are in the development phase and I really don't
expect things to settle down and become true documented API until the
next release.
We can answer questions until then.
--
Thanks, Rich Kulp
|
|
|
| Re: Browsing the VE Source [message #595656 is a reply to message #51273] |
Thu, 22 July 2004 12:16 |
| Eclipse User |
|
|
|
Steve Harper wrote:
> I'm investigating using GEF for a Visual Builder for our own non-Java 4GL
> environment which uses Swing at run time. We store all the meta-data that
> we generate the Swing components from in a DataBase. So I'm not sure how
> useful EMF would be to us (we don't ever generate Java Source, we just
> read the meta data and create Swing components at run time). But really
> would like to see how VE renders components at design time.
In addition to the other posts, I'll add a brief architectural description:
VE uses the model-view-controller pattern, so the model is king and
everything else is just a view of that model.
Since VE needs to be able to model any kind of UI for any platform or
language, a platform and widget-set independent model was needed. EMF
fits this pretty well because it has methods that are analogous to what
you find in java.lang.reflect, but is not Java specific. These methods
can be used to discover the property names and read/write the contents
of your GUI objects dynamically at runtime, just like you would do using
java.lang.reflect or java.beans, but without directly relying on either.
So if you wanted to hook into VE, your persistence model (in your case,
your database) would be hooked up as a "view" listening to the EMF model
in order to support your back-end.
I hope this helps provide some conceptual understanding of how VE works.
As the others said, please ask more specific questions as you need to
and we'll try to help.
Regards,
Dave
--
Dave Orme
Eclipse Visual Editor Project Lead
Advanced Systems Concepts' Chief Architect
http://www.swtworkbench.com
|
|
|
| Re: Browsing the VE Source [message #596054 is a reply to message #51300] |
Fri, 30 July 2004 09:47 |
| Eclipse User |
|
|
|
I don't think it would make sense for the editor I'm working on to extend
VE. We have platform independant meta data stored in a database. At run
time we have a "Swing Player" that reads the meta data and instatiates
Swing components on the fly. There are currently over 1000 such panels
stored in the database together with 4GL code that handles the business
logic on the panels. We have never generated Java code that represents
these panels. Instead we render them at run time using Java. So the whole
approach of VE using EMF to generate Java code from the beans doesn't seem
to apply to this editor.
I am very interested in how VE renders the Swing components at design time.
Looked at ComponentGraphicalEditPart and started looking at ImageFigure,
ImageFigureController, IVisualComponent, et al. Have to admit I quickly
became lost. Was trying to see if you used draw2d to actually render the
components. Assume that when I run VE that I'm not actually manipulating
real Swing components but rather the proxies that are somehow rendered
with draw2d.
I've got a prototype of my editor where the various Swing Components are
rendered via draw2d components (ie. been using Label, TextFlow, Checkbox
from draw2d to simulate Swing components). Having a lot of problem
(obviously) doing WYSIWYG with the approach.
When someone drops a Swing JCheckBox on the editor in VE where does the
ImageFigure come from? I did a search on all calls to
ImageFigure.setImage() and was even more confused about what was going on.
Can you point at the classes I should look at to understand all this?
Thanks, it looks like there are some really powerful patterns in VE that
are generally applicable, but it's hard to get the big picture diving into
the source. Think a big part of my difficulty is that I've never written a
Visual Editor of any kind.
Jeff Myers wrote:
> Steve,
> Glad to have you looking at the VE source. Someone else will talk about
> the documentation (or lack thereof) and what would be necessary to
> achieve what you're looking to do, but I can quickly point out which
> EditParts you might want to start looking at. On the JFC side, check
> out ComponentGraphicalEditPart and ContainerGraphicalEditPart in
> org.eclipse.ve.internal.jfc.core. ....
|
|
|
| Re: Browsing the VE Source [message #596065 is a reply to message #52569] |
Fri, 30 July 2004 10:42 |
| Eclipse User |
|
|
|
Steve,
Please check out the overview of the Visual Editor's architecture here:
http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /vep-home/WebContent/docs/architecture/architecture.html
To render the Swing, AWT and SWT components, the Visual Editor launches
a target VM off screen that instantiates and renders a live version of
the file you're editing. The image is captured from this live window,
and sent via the proxy classes you found back to the editor. The editor
takes these screen capture images and creates GEF figures out of them.
This is the way we ensure an accurate WYSIWYG representation of the
Visual Class.
The VE project is designed to be able to extend or replace any of the
main architecture components (the blue ovals in the diagram) with
alternate implementations. This means you could rip out the Java code
generation aspect of the VE completely and replace it with something
that generates whatever representation you are storing in your database.
You can provide an adaptor from your model to the VE's Java component
EMF model, or replace the core model with another EMF model that will
work with the other parts of the system.
The point is, you can replace codegen and the rest of the framework will
do the rest for you (all the GEF edit parts, the rendering on the target
vm, etc)
Hope this helps,
- Jeff
Steve Harper wrote:
> I don't think it would make sense for the editor I'm working on to extend
> VE. We have platform independant meta data stored in a database. At run
> time we have a "Swing Player" that reads the meta data and instatiates
> Swing components on the fly. There are currently over 1000 such panels
> stored in the database together with 4GL code that handles the business
> logic on the panels. We have never generated Java code that represents
> these panels. Instead we render them at run time using Java. So the whole
> approach of VE using EMF to generate Java code from the beans doesn't seem
> to apply to this editor.
>
> I am very interested in how VE renders the Swing components at design time.
> Looked at ComponentGraphicalEditPart and started looking at ImageFigure,
> ImageFigureController, IVisualComponent, et al. Have to admit I quickly
> became lost. Was trying to see if you used draw2d to actually render the
> components. Assume that when I run VE that I'm not actually manipulating
> real Swing components but rather the proxies that are somehow rendered
> with draw2d.
>
> I've got a prototype of my editor where the various Swing Components are
> rendered via draw2d components (ie. been using Label, TextFlow, Checkbox
> from draw2d to simulate Swing components). Having a lot of problem
> (obviously) doing WYSIWYG with the approach.
>
> When someone drops a Swing JCheckBox on the editor in VE where does the
> ImageFigure come from? I did a search on all calls to
> ImageFigure.setImage() and was even more confused about what was going on.
> Can you point at the classes I should look at to understand all this?
>
> Thanks, it looks like there are some really powerful patterns in VE that
> are generally applicable, but it's hard to get the big picture diving into
> the source. Think a big part of my difficulty is that I've never written a
> Visual Editor of any kind.
|
|
|
Goto Forum:
Current Time: Mon Nov 03 22:49:03 EST 2025
Powered by FUDForum. Page generated in 0.76113 seconds |
Home