Eclipse Community Forums: Visual Editor (VE)

Help

Home

Home » Archived » Visual Editor (VE) » xswt persistence

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

xswt persistence [message #107173]

Mon, 19 September 2005 14:24

Dylan Bruzenak

Messages: 48
Registered: July 2009

Member

I'm going to take a look at implementing another persistence format, just
to familiarize myself with the process and possibly for a tutorial if everything
goes well. Since XSWT seems to be in much demand and pretty well formed
from my perspective I thought it would be the ideal target format. I'm looking
for some pointers on where to start.

Do I start by registering my own custom decoders for each component for the
BDM model ? Is there a whole layer I can replace to do this or do I need
to do it on a component by component basis ? Is there a set of packages
I can look at for swt, and a set for swing decoding where the code is centralized
? I'm assuming the codegen packages are what I'm looking for, but I don't
know if that is all the code I should be looking at. There is also the issue
of integration - I'm a little wary of extending JavaVisualEditorPart directly
to shoehorn my own xml editor part into the mix.

thanks for any pointers,

Dylan

Report message to a moderator

Re: xswt persistence [message #107538 is a reply to message #107173]

Tue, 20 September 2005 14:03

Gili Mendel

Messages: 338
Registered: July 2009

Senior Member

Dylan Bruzenak wrote:
> I'm going to take a look at implementing another persistence format,
> just to familiarize myself with the process and possibly for a tutorial
> if everything goes well. Since XSWT seems to be in much demand and
> pretty well formed from my perspective I thought it would be the ideal
> target format. I'm looking for some pointers on where to start.
> Do I start by registering my own custom decoders for each component for
> the BDM model ? Is there a whole layer I can replace to do this or do I
> need to do it on a component by component basis ? Is there a set of
> packages I can look at for swt, and a set for swing decoding where the
> code is centralized ? I'm assuming the codegen packages are what I'm
> looking for, but I don't know if that is all the code I should be
> looking at. There is also the issue of integration - I'm a little wary
> of extending JavaVisualEditorPart directly to shoehorn my own xml editor
> part into the mix.
>
> thanks for any pointers,
>
> Dylan
>
>

The easiest starting point would be to just get at the VE model, traverse it, and persist it in XSWT (e.g., save as XSWT
action). This will get you started with dealing with the VE model, and EMF.

The next step is read in and build the model from XSWT.

3rd step is to create a .xswt based editor that replaces CodeGen altogether.

Some more info in http://dev.eclipse.org/newslists/news.eclipse.tools.ve/msg04 615.html

Report message to a moderator

Re: xswt persistence [message #107747 is a reply to message #107173]

Thu, 22 September 2005 09:37

Joe Winchester

Messages: 496
Registered: July 2009

Senior Member

Hi Dylan,

Extending the JavaVisualEditorPart would be the wrong approach, as it
already has to subclass CompilationUnitEditor (for reasons we hope to
avoid soon), and it also plays some tricks with multiple threads to help
start up time.

As Gili said, the key is the JEM model. This is the model that is made
up of IJavaInstance elemenets. It'd be best to have a new editor that
read a file and then created a JEM model. The best approach would be to
begin with not by actually trying to parse any kind of file, but just to
hard code it so that a "Hello World" JEM model was created and the VE
subsystems such as GEF and the BeanProxy mechanism able to fire up over
this. Then get into issues such as how to parse XSWT and save into it.

If you check out org.eclipse.ve.examples there is an editor part called
EMFGraphicalEditorPart and some subclasses of this. It was supposed to
form the basis for the kind of thing you are doing and at one point we
had a subclass of it that could work just with JEM and no code gen,
however that hasn't been maintained. The other thing is to debug into
JavaVisualEditorPart and look at the model builder.

Best regards,

Joe Winchester

Report message to a moderator

Re: xswt persistence [message #107774 is a reply to message #107747]

Thu, 22 September 2005 13:57

Dylan Bruzenak

Messages: 48
Registered: July 2009

Member

I thought that would be the wrong way to go. Thanks for the tips, that should
be enough to get me started.

Dylan

> Hi Dylan,
>
> Extending the JavaVisualEditorPart would be the wrong approach, as it
> already has to subclass CompilationUnitEditor (for reasons we hope to
> avoid soon), and it also plays some tricks with multiple threads to
> help start up time.
>
> As Gili said, the key is the JEM model. This is the model that is
> made
> up of IJavaInstance elemenets. It'd be best to have a new editor that
> read a file and then created a JEM model. The best approach would be
> to
> begin with not by actually trying to parse any kind of file, but just
> to
> hard code it so that a "Hello World" JEM model was created and the
> VE
> subsystems such as GEF and the BeanProxy mechanism able to fire up
> over
> this. Then get into issues such as how to parse XSWT and save into
> it.
>
> If you check out org.eclipse.ve.examples there is an editor part
> called EMFGraphicalEditorPart and some subclasses of this. It was
> supposed to form the basis for the kind of thing you are doing and at
> one point we had a subclass of it that could work just with JEM and no
> code gen, however that hasn't been maintained. The other thing is to
> debug into JavaVisualEditorPart and look at the model builder.
>
> Best regards,
>
> Joe Winchester
>

Report message to a moderator

Re: xswt persistence [message #108222 is a reply to message #107538]

Tue, 27 September 2005 03:26

Dave Orme

Messages: 424
Registered: July 2009

Senior Member

Gili Mendel wrote:
> Dylan Bruzenak wrote:
> The easiest starting point would be to just get at the VE model,
> traverse it, and persist it in XSWT (e.g., save as XSWT action). This
> will get you started with dealing with the VE model, and EMF.
>
> The next step is read in and build the model from XSWT.

To do this, you just create and register an ILayoutBuilder
implementation. This is XSWT's swappable control creation / property
setting layer.

Look at XSWTCC for a simple example of how to do this.

I made it swappable specifically to make it possible to support VE in
the future.

Email me if you need more help.

Best,

Dave Orme
--
Visual Editor Project lead
http://www.db4o.com -- The Open-source Java Object Database
http://xswt.sf.net -- XML-based SWT page description language

Report message to a moderator